markb@denali (10/14/88)
In article <1988Oct12.164433.17763@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > Uh, say what? SCSI transfer rate, at full bore, is 4 MB/s (note, not > Mb/s), which is 32 MHz. Sounds comparable to me. Of course, there are > a lot of cruddy SCSI controllers which can't hack that kind of speed, > but then, there are cruddy ESDI and SMDE controllers too. > Yes, bus speed is at 4 MB/s burst speed. The arbitration cycles are spec'ed in milliseconds. Read the latest SCSI 1 spec for actual numbers. The ESDI bus speeds are in microseconds. The ESDI spec provides actual figures, again. These are industry standards. Please read them. Look especially at the timing diagrams. > References, please. I've seen both SCSI and ESDI specs, and somehow I > failed to notice any such disparity. In the specs, not the current > (often lousy, for both) implementations. > > Do remember that this is, to some extent, an apples-and-oranges comparison, > since SMDE and ESDI are drive-to-controller interfaces and SCSI is a > controller-to-host interface. Since there *has* to be a controller > between a disk drive and a SCSI bus, the quality of the controller makes > a big difference. A bus is a bus. Look at the data rate of data from the media, then at the bus timings, and it becomes very clear that unless you are doing some hefty read-aheads and intelligent buffer managemant, that ESDI does blow it away, both on paper, and in practice. Better yet, run a benchmark that requires substantial paging to disk (ie. memory limited) and see which drive types do it faster... Mark Bradley "Faster, faster, until the thrill of Manager I/O Subsystems speed overcomes the fear of death." Silicon Graphics Computer Systems Mountain View, CA ---Hunter S. Thompson
terryk@pinocchio.Encore.COM (Terence Kelleher) (10/15/88)
ESDI is an easy winner, if you compare 1 disk to 1 disk. If you are
using more disks, SCSI provides the nice features of overlapped
operations. 2 disks, with seperate controllers, on the SCSI bus will
provide very near twice the throughput of 1 drive. This is not the
case with ESDI. Which is better really depends on wheter you care
more about overall throughput or single access times.
Terry Kelleher, Encore Computer
UUCP: {bu-cs,decvax,necntc,talcott}!encore!terryk
Internet: terryk%pinocchio@multimax.ARPA
Terry Kelleher, Encore Computer
UUCP: {bu-cs,decvax,necntc,talcott}!encore!terryk
Internet: terryk%pinocchio@multimax.ARPAmarkb@denali (10/15/88)
In article <3877@encore.UUCP>, terryk@pinocchio.Encore.COM (Terence Kelleher) writes: > ESDI is an easy winner, if you compare 1 disk to 1 disk. If you are > using more disks, SCSI provides the nice features of overlapped > operations. 2 disks, with seperate controllers, on the SCSI bus will > provide very near twice the throughput of 1 drive. This is not the > case with ESDI. Which is better really depends on wheter you care > more about overall throughput or single access times. > The more sophisticated ESDI and SMD controllers are actually much faster than multiple embedded SCSI's on a single bus, too. That is, they support overlapped seek operation, command sorting, command queuing, seek optimization, and they have look-ahead, buffering and very fast fifo's. They will also support scatter-gather operation which tends to help us considerably, as you might expect. Some of my comparisons on SCSI, ESDI, and SMDE are below on our product. These are on read performance through the EFS. SCSI: 450 KBS (async, single ended, 10 MHz drive) ESDI: 980 KBS (with above features, 10 MHz drive) ESDI: 1500 KBS (with above features, 15 MHz drive) SMDE: 2100 KBS (with above features, 24 MHz drive) these numbers actually look better on an AIM benchmark, but this BM tends to provide varibale results that skew upward in many cases. As one would expect, the file system tends to slow things a bit, and of course multiple drives would up the throughput considerably in all cases. Mark Bradley "Faster, faster, until the thrill of Manager I/O Subsystems speed overcomes the fear of death." Silicon Graphics Computer Systems Mountain View, CA ---Hunter S. Thompson
jfh@rpp386.Dallas.TX.US (The Beach Bum) (10/15/88)
In article <3877@encore.UUCP> terryk@pinocchio.UUCP (Terence Kelleher) writes: >ESDI is an easy winner, if you compare 1 disk to 1 disk. If you are >using more disks, SCSI provides the nice features of overlapped >operations. 2 disks, with seperate [ sic ] controllers, on the SCSI bus will >provide very near twice the throughput of 1 drive. This is not the >case with ESDI. Which is better really depends on wheter you care >more about overall throughput or single access times. Adding a slow I/O device to the SCSI bus is a sure way to slow the entire bus down. The SCSI bus supports at most one data transfer occuring at any single time. If a large streaming tape [ as one good example ] transfer is presently occuring, all disk transfers are suspended. Also, during the data phase for the presumed tape request, no other SCSI commands may be issued. You would have to provide separate SCSI buses for each device to insure that no one device hogged the bus, or put slow devices on separate buses and leave the disks on one single bus. This is all moot anyhow since multiple ESDI disk controllers can be placed on the same system bus [ ghod willing ], and this would permit multiple simultaneous seeks and data transfers [ assuming DMA ]. Further, intelligent ESDI controllers exist which support overlapped seeks, which was Terrence's original argument for the SCSI bus. -- John F. Haugh II +----Make believe quote of the week---- VoiceNet: (214) 250-3311 | Nancy Reagan on Richard Stallman: InterNet: jfh@rpp386.Dallas.TX.US | "Just say `Gno'" UucpNet : <backbone>!killer!rpp386!jfh +--------------------------------------
terryk@pinocchio.Encore.COM (Terence Kelleher) (10/17/88)
In article <20606@sgi.SGI.COM> markb@denali writes: > >Some of my comparisons on SCSI, ESDI, and SMDE are below on our product. >These are on read performance through the EFS. > >SCSI: 450 KBS (async, single ended, 10 MHz drive) >ESDI: 980 KBS (with above features, 10 MHz drive) >ESDI: 1500 KBS (with above features, 15 MHz drive) >SMDE: 2100 KBS (with above features, 24 MHz drive) > I have run tests using CDC Sabre disks (24 Mhz) with imbedded SCSI controllers and I got the following results. These are based on transfer size of 8192 bytes and synchronous transfer and all accesses via a file system. 1 disk 444 KBPS 2 disks 795 KBPS 3 disks 977 KBPS 4 disks 1.102 MBPS 5 disks 1.180 MBPS 6 disks 1.251 MBPS I ran the same tests on CDC Wren V disks and got similar results, even though the transfer rate on the Wren is slower (between 12 and 16 Mhz, depending on the cylinder zone). >these numbers actually look better on an AIM benchmark, but this BM tends >to provide varibale results that skew upward in many cases. As one would >expect, the file system tends to slow things a bit, and of course multiple >drives would up the throughput considerably in all cases. > What were the conditions of your tests, such as transfer size, types of access. I am not aware of any standard benchmarks for disk performance. Sure would be nice to have a level standard of comparison. Terry Kelleher, Encore Computer UUCP: {bu-cs,decvax,necntc,talcott}!encore!terryk Internet: terryk%pinocchio@multimax.ARPA
terryk@pinocchio.Encore.COM (Terence Kelleher) (10/17/88)
In article <7922@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (The Beach Bum) writes: > >Adding a slow I/O device to the SCSI bus is a sure way to slow the entire >bus down. The SCSI bus supports at most one data transfer occuring at any >single time. If a large streaming tape [ as one good example ] transfer >is presently occuring, all disk transfers are suspended. Also, during the >data phase for the presumed tape request, no other SCSI commands may be >issued. > >You would have to provide separate SCSI buses for each device to insure >that no one device hogged the bus, or put slow devices on separate buses >and leave the disks on one single bus. > Since the SCSI bus runs faster than the speed of data to/from media, "most" SCSI controllers will buffer data, without holding the bus. Trasfers to a streaming tape will be in bursts, assuming even with async a SCSI transfer rate of 1.5 MBPS and a buffer to tape speed of around 390 KBPS. A tape controller will select when data transfer is required, but be off the SCSI bus the majority of the time. A slow device, say a QIC drive, would take the bus less often and present less impact to the overall throughput of the bus. Real impact to performance comes from very fast devices that can consume a good deal of bandwidth, but even a good disk will have a 8 ms. typical latency per command because of physical motion delays when the bus is available. Of course if the controller is poorly designed, my opinion goes right down the tubes. A bad controller can hold the bus doing absolutly nothing. I have evaluated a large number of disk and tape devices with imbedded controllers and these poor controllers are rare. >This is all moot anyhow since multiple ESDI disk controllers can be placed >on the same system bus [ ghod willing ], and this would permit multiple >simultaneous seeks and data transfers [ assuming DMA ]. Further, intelligent >ESDI controllers exist which support overlapped seeks, which was Terrence's >original argument for the SCSI bus. Sure, the more resources you put right on the system bus, the better it runs, But DMA and system interfaces are expensive. I admit, in a Multimax you will get better performance if each SCSI bus has only one disk, but I can easily put 4 disks and a tape on that same channel and get good performance. I have no experience with intelligent ESDI controller. Are they common? Terry Kelleher, Encore Computer UUCP: {bu-cs,decvax,necntc,talcott}!encore!terryk Internet: terryk%pinocchio@multimax.ARPA
markb@denali (10/18/88)
In article <3900@encore.UUCP>, terryk@pinocchio.Encore.COM (Terence Kelleher) writes: > In article <7922@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (The Beach Bum) writes: > > Since the SCSI bus runs faster than the speed of data to/from media, > "most" SCSI controllers will buffer data, without holding the bus. > Trasfers to a streaming tape will be in bursts, assuming even with > async a SCSI transfer rate of 1.5 MBPS and a buffer to tape speed of > around 390 KBPS. A tape controller will select when data transfer is > required, but be off the SCSI bus the majority of the time. A slow > device, say a QIC drive, would take the bus less often and present > less impact to the overall throughput of the bus. Real impact to > performance comes from very fast devices that can consume a good deal > of bandwidth, but even a good disk will have a 8 ms. typical latency > per command because of physical motion delays when the bus is available. > If you are in fact running async SCSI, your xfer rate from the media can exceed the xfer rate of the SCSI bus. You should also keep in mind that connects and disconnects suck your xfer rate down. Again let's consider xfer rate-burst is substantially different from throughput. Again because of inherent comparative slowness of SCSI to other buses, throughput will be low if small buffers are on your deviec level controllers. > I have no experience with intelligent ESDI controller. Are they common? > Pretty much on VME, somewhat less sophisticated on multibus, and probably rare on PC bus, and the like. markb Mark Bradley "Faster, faster, until the thrill of Manager I/O Subsystems speed overcomes the fear of death." Silicon Graphics Computer Systems Mountain View, CA ---Hunter S. Thompson
jpdres10@usl-pc.usl.edu (Green Eric Lee) (10/20/88)
In article <3899@encore.UUCP> terryk@pinocchio.UUCP (Terence Kelleher) writes: >In article <20606@sgi.SGI.COM> markb@denali writes: >>Some of my comparisons on SCSI, ESDI, and SMDE are below on our product. >>These are on read performance through the EFS. >> >>SCSI: 450 KBS (async, single ended, 10 MHz drive) >>ESDI: 980 KBS (with above features, 10 MHz drive) >>ESDI: 1500 KBS (with above features, 15 MHz drive) >>SMDE: 2100 KBS (with above features, 24 MHz drive) Recently someone was rattling on comp.sys.amiga about how it was impossible to get 500KBS out of a particular SCSI interface. Several people replied that yes, they did -- going through the operating system, no less. One particularly interesting statistic was that for 32kbyte transfers, they averaged 850Kbytes/second. (Note that AmigaDOS lets you issue file system requests as large as available contigious memory). This was with a Commodore Amiga, AmigaDOS, Fast File System, CDC Wren drive, and, uhm, I think it was the Great Valley Products SCSI interface. >>expect, the file system tends to slow things a bit, and of course multiple Virtual memory also tends to slow things a bit, since your OS has to do a bit of trickery to make sure the disk buffer is mapped into your process address space, or else it has to do some data copying (Unix does copying, I believe, due to its caching algorithm). Not to mention that the traditional Unix inode/block organization is ridiculous (unless you were using BSD4.x), and Unix tasks are very heavy-weight (the Amiga has a real-time kernal). Unix probably is not a very good benchmark for measuring I/O performance.... -- Eric Green P.O. Box 92191, Lafayette, LA 70509 {ames mit-eddie etc.}!killer!elg, killer!usl!usl-pc!jpdres10, etc. etc. etc.