jmcgrath at qntm.com
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 wichitaks.ncr.com>
From: Stephen Finch/SSI1 <Stephen_Finch/SSI1.SSI1 at notes-gw.tus.ssi1.com>
Date: 23 May 95 7:21:04 EDT
Subject: FASTER SCSI
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
or (worse) an additional reselection to transfer the data.)
Let's total the time (assume async transfers of msg/cmd/sts are a 5
msg out 1000
cmd out 2400
msg in 1000
bus free 0
msg in 1000
sts in 1000
msg in 1000
bus free 0
----------- -------- -------
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:
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!
WHAT DO YOU THINK?
steve.finch at tus.ssi1.com
Silicon Systems Inc.
More information about the T10