SYNC SCSI (summ

[Benjamin Clardy]

I thought I might post a summary of the responses I received to my query
on sync scsi.

>Our main computing bottleneck seems to be disk speed.  Specifically, we
>have SAS analyzing fairly large datasets, 5MB - 150MB, so sustained disk
>throughput is very important.  I have tried to implement sync scsi under
>4.1 changing the scsi_options in the kernel to 0x38 but I can not tell any
>noticeable effect in speed.  In addition, if I set the jumpers on my
>M2263SAs to 4.0MB/s max transfer rate (instead of 2.7MB/s) the drive fails
>to function properly.

curt at ecn.purdue.edu (Curt Freeland)  writes
  I have several of these drives at 4.0 M/s on SS2 systems running fine.

>Do I need to go to SunOS 4.1.1 to take advantage of sync scsi?  What type
>of throughput inccrease with sync scsi can I see on a SLC?

terryk at encore.com (Terence Kelleher) @ Encore Computer Corp. writes

Regarding SYNC SCSI, the sync transfer does not help unless you have 2 or
more disks on your bus and you are running both of them alot.  Basically,
even running async, SCSI outruns the media to buffer transfer time of the
disk.  On a read, a  good disk attempts to connect to the bus when enough
data has been buffered to be able to transfer all the data in one
connection.  ie: Try to have the SCSI transfer end just after the disk
transfer ended.  On a write, completion is sent ot the user only after all
data is transfered to the media.  Running SYNC transfer on the SCSI bus
gets the data transfer phase done quicker, but does not help to complete
the transfer faster.

What SYNC SCSI gives you is more free time on the bus.  If only one access
is busy, free time is of no value.  If many disks are active, the added
free time means more commands can get out to disks faster.  You can
measure this with 2 disks busy on the bus, but it is not real significant.
With 3 or 4 disks on the bus, Async gets saturated and Sync does not.

This is example results of a Sync vs Async test.  The units as IO
operations per second.  All transfers 8 Kbytes.

  Number of disks         1    2    3    4    5    6
  Sync (5 Mbyte/sec)      52   93   118  134  141  145
  Async (1.5 Mbyte/sec)   52   75   83   85   85   85

By the way, the tests I quote above were not run on a Sun.  This is from a
test of an Encore Multimax running 12 32532 Cpu's, running a disk test
with 32 seperate processes.  Its hard to get that much IO on a disk and
still have the machine do real work.  Most often, even on a busy system,
only one or two disks will get much work load at any given time.  

hanson at calvin.fnal.gov (Steve Hanson) writes

If you are running your machine with a SINGLE disk drive, Sync SCSI isn't
going to buy you much, if anything.  The real advantage of having Sync is
that if you have multiple SCSI devices contending for bus time, they all
get off the bus much faster.  Async can be very fast if you don't have
very long disk cables.

samg at midway.uchicago.edu writes 

Since an SLC is effectively the same as a SS1, and since Sun claims that
the SS1 isn't fast enough to do sync scsi, you may not have much luck no
matter which version of SunOS you run.  I'm told it can be done, but the
quality of the cables is crucial.

I'm currently running a FJ2263SA in sync mode (all jumpers closed) off a
1+ with no trouble at all, and getting about 3.6 mb as the max transmit
rate.   Try it on your IPC.

bernards%ecn.nl writes

I Have an SLC running 4.1.1 and have a WREN VI 660 MB disk attached.  I
get 4MB/sec tranfer rate.  Strangely, a IPC with an external 660 SUN Disk
runs at 3.9?? MB/sec A SS1 does not run in sync mode in 4.1.1 :-(

>What other advantages does 4.1.1 have over 4.1?

samg at midway.uchicago.edu writes 

Tons of bugs fixed.  (You'll still need patches however) I'll be creating
a 4.1.1 patch archive on midway within a week or so.

guy at auspex.com (Guy Harris) writes

Open Windows 2.0 is bundled with it.

MS-DOS file system as a VFS type is bundled in (you can mount DOS floppies
on your Sun and access them from UNIX - it does its best to make them look
as much like UNIX file systems as it can; this does not, of course,
include translating *file* formats - you still see CR/LF - but it does
handle directories, albeit with the traditional 8.3 limitation on file
names).

I/O clustering, wherein on the faster machines you can have a file system
rotational delay of 0 (or 1, or whatever - basically, put block N+1 of a
file next to block N), and the system will try doing I/O to the file in
big contiguous chunks (local I/O; NFS I/O is still done in 8K chunks or
so).

Bug fixes to the "/tmp" file system to make it much faster.

Rewhack of the low-level support code for the Sun MMU to make it handle
some page faults for pages that are in memory, but not mapped in the MMU
because there isn't enough room in the MMU, more efficiently.

Assorted bug fixes, and some miscellaneous enhancements.

<Regarding my diatribe on short Sun warranties and my bad experience with>
<Sun supplied internal drives>

curt at ecn.purdue.edu (Curt Freeland)  writes

I have been yelling at Bob Fernander (Chicago office sales manager) and
the Indy office for some time now.  I have also yelled at people up the
ladder at Sun that they should pass on the vendor warrantee with the stuff
they re-sell (Maxtor, Hitachi, ...).   This would make the customer
happier if they could get a replacement on the drives from the original
manufacturer, instead of getting screwed by Sun (again).

No sh*t.  I recently was asked what price the Sun drives would have to be
before I would buy them.  My response?  "How long is the warrantee?".
When told 90 days, I said forget it, I dont want them.  Why bother when I
can get Fujitsu, or HP drives with 5 year (48 hour replacement) warrantee,
and other brands with 3 year warrantee?

gord at cs.ualberta.ca (Gord Urquhart) writes

We had one of our sun supplied Micropolis drives fail @ about 98 days and
of course Sun would not fix it. But the other thing Sun did was NOT tell
us that Micropolis warrants their drives for a year. So take a look and
seen if there is a manufacturers warranty on the drive.

THANKS to all who responded.

Benjamin
bkc2 at midway.uchicago.edu