stevew at abbott.SanDiegoCA.ATTGIS.COM stevew at abbott.SanDiegoCA.ATTGIS.COM
Tue May 23 16:26:34 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.

Isn't this assuming one drive per SCSI ID?  What about something like a
disk array where we can have multiple drives per LUN and multiple
LUNs per SCSI ID?  Are the disks still the bottleneck?

What the overhead numbers tell me (someone correct me if I'm wrong),
is how much max effective throughput I can expect from my 40MB/sec bus
as a function of blocksize when the bus is saturated:
(ie. 40MB/sec - (%overhead * 40MB/sec)).

Most (non-SCSI) users here have a hard time when you explain to them
that doubling the bus link rate won't help as much as they think if they
are using small blocksizes (ie. database records, kernel paging, backups...)

Thanks for the post on this - the numbers are interesting!

Stephen Wall                       (619) 485-2700 
AT&T Global Information Solutions  stephen.wall at sandiegoCA.ATTGIS.COM
Parallel Systems Software Division
17095 Via del Campo
San Diego CA. 92127-1711

More information about the T10 mailing list