alexis@ccnysci.UUCP (Alexis Rosen) (03/12/89)
A little while ago David Buerger wrote in InfoWorld about these hard disks,
which he claimed would "revolutionize network storage." These drives are
similar to the regular Quantum 3.5" SCSI drives in aat and capacity (19ms,
40 or 80MB) and the presence of a 64K cache. Instead of SCSI, they use an
interface called CDI (Cluster Disk Interface).
While these specs are good, I don't understand why these disks impress him.
To start with, he says that the claimed transfer rate is in excess of
4MBytes/sec. This is almost an order of magnitude faster than the transfer
speeds I've witnessed on a Mac II (true, it was using SCSI, but SCSI is
capable of greater speed, even on a Mac II - with the Wrens, for example).
More importantly (and less comprehensibly, to me) is his criticism of SCSI.
"The CDI data transfer rate is 512 bytes
per transaction vs. SCSI's 1 byte."
Is that true? It sounds utterly bogus to me (who in their right minds would
create a protocal with 1-byte transfers?) but I'm not a SCSI expert.
Buerger also says that distributing tasks over multiple spindles helps
performance. This is ancient wisdom, to say the least. The problem is that
he says that this strategy is NOT useful over SCSI because there will be
contention between the drives:
"[SCSI's] weakness is that SCSI is a device interface.
This results in slower data transfer due to
translation overhead as multiple drives contend
with each other."
This appears to be several kinds of nonsense. What is "translation
overhead?" Does he mean collision? I don't think that can happen on
SCSI, especially if there's just one master device (tha Mac, or an IBM
AT controller card).
Now I know that when you have separate controllers on, say, a VAX, you
can improve performance, but ultimately the bottleneck of one bus is
going to hit you. And this impulse drive uses only one controller, also.
So it's limited in exactly the way SCSI is. (Which is not to say that
multiple spindles won't still be a big win.)
So what's going on? Is he talking through his hat, or am I totally wrong?
I know enough about this stuff to get myself into trouble, but not quite
enough to get out...
Thanks
Alexis Rosen
alexis@ccnysci.uucpbuck@siswat.UUCP (A. Lester Buck) (03/13/89)
I didn't read the Infoworld article, but does this guy work for the company making Cluster Disk Interfaces? He sure doesn't understand SCSI... For a glimpse of the future of SCSI, check out the Winter 88 issue of Computer Technology Review (call 213-208-1335 and ask for a copy, and a (free :-) subsciption ). In an article titled "Future High Performance Systems Profit Through Use of SCSI and VMEbus", two guys from Emulex explode several common myths about SCSI. They also present a fascinating timing path for a complete typical SCSI command, showing every delay incurred at all four levels (application/OS, driver, host adapter, and SCSI target). It turns out that the Unix buffer cache search is about 30% of the total transfer overhead today, and the requirement that the target check every bit of the SCSI command data block parameters for validity is another 30% or so. Really fancy SCSI protocol chips will be able to do this check in the future. And with SCSI-2 offering up to 40 MB/sec, the future of SCSI is very bright. The design of SCSI has few inherent limitiations, but the current implementations can leave much to be desired. -- A. Lester Buck ...!texbell!moray!siswat!buck
kaufman@polya.Stanford.EDU (Marc T. Kaufman) (03/13/89)
In article <379@siswat.UUCP> buck@siswat.UUCP (A. Lester Buck) writes: >I didn't read the Infoworld article, but does this guy work for >the company making Cluster Disk Interfaces? He sure doesn't >understand SCSI... > ...It turns out that the Unix buffer cache search is >about 30% of the total transfer overhead today, and the >requirement that the target check every bit of the SCSI >command data block parameters for validity is another 30% >or so... Huh? The command data block is 6 bytes long. The only parameter of any consequence in it is the sector address. How can this take 30% of the transfer time? The Mac II SCSI interface peaks at 1.4 MB/sec transfer rate. The SE can get 600 KB/sec. Using the Device interface on a IIx, I get 330 KB/sec sustained on Apple's HD 80, and 450 KB/sec on a new SuperMac drive. As this is a continuous read through 80 MB of disk, the cache is of no consequence in these numbers. Marc Kaufman (kaufman@polya.stanford.edu)
jlohmeye@entec.Wichita.NCR.COM (John Lohmeyer) (03/14/89)
In article <1397@ccnysci.UUCP> alexis@ccnysci.UUCP (Alexis Rosen) writes: >A little while ago David Buerger wrote in InfoWorld about [..stuff deleted..] >an interface called CDI (Cluster Disk Interface). [more stuff deleted] >More importantly (and less comprehensibly, to me) is his criticism of SCSI. > "The CDI data transfer rate is 512 bytes > per transaction vs. SCSI's 1 byte." >Is that true? It sounds utterly bogus to me (who in their right minds would >create a protocal with 1-byte transfers?) but I'm not a SCSI expert. I am a SCSI expert and it is indeed bogus. SCSI places no restrictions over how much data can be transferred at one time (although there is a method for a host to limit the transfer size for performance tuning). >Buerger also says that distributing tasks over multiple spindles [...] >is NOT useful over SCSI because there will be >contention between the drives: > "[SCSI's] weakness is that SCSI is a device interface. > This results in slower data transfer due to > translation overhead as multiple drives contend > with each other." >This appears to be several kinds of nonsense. What is "translation >overhead?" Does he mean collision? I don't think that can happen on >SCSI, especially if there's just one master device (tha Mac, or an IBM >AT controller card). SCSI certainly can support multiple spindles per bus and many SCSI devices also support multiple spindles per target (SCSI buzz word for a controller). SCSI is NOT a device level interface. Most SCSI implementations are buffered so that bus contention is not as serious a problem as on a device level interface where contention means slipped latencies. And yes, contention can occur with only one host. If the host supports multi-tasking several controllers can attempt to reconnect (another SCSI buzz word for trying to obtain the bus to continue an I/O) at the same time. Buffered controllers take a lot of the sting out of contention. [more stuff deleted] >So what's going on? Is he talking through his hat, or am I totally wrong? >I know enough about this stuff to get myself into trouble, but not quite >enough to get out... >Thanks >Alexis Rosen >alexis@ccnysci.uucp My best guess is that David Buerger doesn't really understand SCSI. I did not read his original article, so I don't know much about the CDI he was promoting. Perhaps CDI has some nice features, but by incorrectly criticizing SCSI he has only convinced me that he doesn't know what he is talking about... I would like to see some specs on CDI to make my own decision. ___________________________ John Lohmeyer NCR Corporation J.Lohmeyer@Wichita.NCR.COM
buck@siswat.UUCP (A. Lester Buck) (03/17/89)
In article <7657@polya.Stanford.EDU>, kaufman@polya.Stanford.EDU (Marc T. Kaufman) writes: . In article <379@siswat.UUCP> buck@siswat.UUCP (A. Lester Buck) writes: . >I didn't read the Infoworld article, but does this guy work for . >the company making Cluster Disk Interfaces? He sure doesn't . >understand SCSI... . . > ...It turns out that the Unix buffer cache search is . >about 30% of the total transfer overhead today, and the . >requirement that the target check every bit of the SCSI . >command data block parameters for validity is another 30% . >or so... . . Huh? The command data block is 6 bytes long. The only parameter of any . consequence in it is the sector address. How can this take 30% of the transfer . time? The Mac II SCSI interface peaks at 1.4 MB/sec transfer rate. The SE can . get 600 KB/sec. Using the Device interface on a IIx, I get 330 KB/sec . sustained on Apple's HD 80, and 450 KB/sec on a new SuperMac drive. As this is . a continuous read through 80 MB of disk, the cache is of no consequence in . these numbers. The article I referenced measured SCSI *transfer overhead*, i.e., the wasted time in a transfer over and above the basic transfer rate of 1.5 MB/sec for asynchronous or 4-5 MB/sec synchronous. Checking every reserved bit in the 6 bytes can chew up a few hundred microseconds on a slow target controller. The total overhead for a single transfer is on the order of three milliseconds total today, with lots of room for improvement with improved implementations. You can figure out what your overhead timing is per SCSI read/write op on your Mac - just figure the difference between 1.4 MB/sec and your observed throughput of 600 KB/sec. (You need to know the blocksize, too.) -- A. Lester Buck ...!texbell!moray!siswat!buck