Jim McGrath jmcgrath at
Tue May 23 11:10:31 PDT 1995

        Reply to:   RE>FASTER SCSI

I did a similar analysis for the interface forum a while back and got
similar (although not identical) number.  The bottom line is that
overhead is NOT the right metric to use - bus saturation is instead.

Adding the 4 Kbyte Fast-40 wide data transfer time to the bus overhead
yields 65.6 us/4 K command.  This implies that we can process
15243 such commands/second on a SCSI bus before saturation.
Note that with 16 drives that is 942 IOs/drive before saturation, or
1.06 ms/command.  While our solid state drives can match this, our
electromechanical disk drives are lucky to do 240 IO/s on a good
day - for a random transaction type environment the drives, not
the bus, is the bottleneck.

Now sequential is different - I can easily process a 4 K command in
1.06 ms.  But in this case 4K is too low a number - a good system
will lengthen the command for sequential access if it cares about
performance.  In this case the % of time spent in overhead become
insignificant.  64K, used in many high performance sequantial
applications, has about 1% bus overhead even at Fast-40 speeds.
The solution here is simply higher data transfer rates (Fast-80?),
more parallel buses, or something new (e.g. Fibre Channel).

So in short, not only do cost sensitive applications not benefit for lower
protocol overheads, but no applications benefit except sequential with
small commands - a case that I do not feel compelled to sole at the
SCSI level when it clearly wants to be solved at teh file system/
IO driver level with larger commands.


To: scsi <scsi at>
From: Stephen Finch/SSI1 <Stephen_Finch/SSI1.SSI1 at>
Date: 23 May 95  7:21:04 EDT

As we continue to increase SCSI Parallel speeds, we must begin to look at the
overhead associated with arbitration, selection and phase changes.  Back in
the good old days when these were just a small portion of the time spent on 
a SCSI command, these timings were considered insignificant.  But today, 

A 4096 byte transfer being transferred using FAST-40 and wide bus lasts for 
or 51.2 microseconds.  The processing of the command is:  arbitrate, select, 3

of message out (identify, queue tag), command out (10 bytes), message in 
bus free, arbitrate, reselect, 3 bytes of message in, data, status in, message

in, bus free.
(This is a read, but a write is the about the same with only the data transfer

being moved,
or (worse) an additional reselection to transfer the data.)

Let's total the time (assume async transfers of msg/cmd/sts are a 5 
 Phase  ns
 -------  --------
 Arb  2400
 Selection 1600
 msg out  1000
 cmd out  2400
 msg in  1000
 bus free 0

 Arb  2400
 Reselection 1600
 msg in  1000
 data    51200
 sts in  1000
 msg in  1000
 bus free 0
 ----------- --------  -------
   15400  51200
15.4 out of 66.6 is a 23% overhead for a 4096 byte transfer!  

When SCSI first came out (5 megabytes/sec), the overhead was 1.8%.
With Fast/narrow the overhead was 3.6%.  
With Fast/wide or Fast-20 narrow:  7%.
With Fast-20/wide or Fast-40 narrow, the overhead becomes 13%.  
With Fast-40/wide would be 23%.
With Fast-40/32bits would be 38%.

The overhead is, of course, a function of the block length.  Assuming a single

transfer of the data at full bus speeds using FAST-40/wide:

 Size  Overhead
 --------  ---------
 512  71%
 1024  55%
 2048  37%
 4096  23%
 8192  13%
 16384  7%
 32768  3.6%
 65536  1.8%
 131072  .9%
 262144  .47%
 524288  .23%
 1048576  .12%

The questions are:  
 Are we only interested in large transfers?
  Or, are transfers less than 16K of interest?  
 What is the acceptable overhead level?

When looking at Fast-40, I think it is time to also look at the overhead!


steve.finch at

Silicon Systems Inc.

More information about the T10 mailing list