markb@denali.sgi.com (Mark Bradley) (09/28/89)
This was a posting from comp.arch that seems like it is relevant to recent postings in this group as well. Sorry if you already saw this. In article <32512@ames.arc.nasa.gov>, lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes: > > However, I think you are painting with too broad a brush to include Sun, MIPSCo, > etc. in your list. Remember that the controllers you have been using for > your comparisons to get ~1 MB/sec. through a filesystem are relatively new. > Most of these controllers have been thoroughly *debugged* and in volume > production (two prerequisites for full service companies to buy) for 6 mos. > to one year. Sun now sells faster controllers that will do almost 1 MB/sec. > on SMD disks through a Unix filesystem. I haven't had a chance to measure > any IPI or synchronous SCSI disks. But it is unfair to use today's controllers > to criticize systems shipped 1-2 years ago. I can't yet publish our IPI numbers due to signed non-disclosure, but suffice it to say that it would not make sense to go to a completely different controller and drive technology for anything less than VERY LARGE performance wins or phenomenal cost savings.... On the other hand, using a controller from the same company, SGI gets over 2 MB/sec. on SMD *through* the filesystem. See comp.sys.sgi for discussions on the Extent File System designed by our own Kipp Hickman and Donovan Fong (who is no longer with SGI). However it is also true that a decent job on drivers, caching, selection of the right technology, both in terms of con- trollers and disk drives, and actually marrying these all together will yield a more coherent disk subsystem that is capable of providing nearly theoretical maximum throughput. This is something many companies seem to miss the boat in doing. Clearly I am somewhat biased, but the numbers don't lie (see below for our mid-range ESDI numbers, which are handy in my current directory). > > The other thing that would probably help would be if more people said to > salesrep from company X: "I am buying the system from company Y. Even > though the CPU is only 10 MIPS instead of 20, it can stream data from 4 > controllers simultaneously at 2.5MB/sec. each, with negligible CPU overhead." This is reasonable. Even more so if there is negligible CPU overhead. 2.5 on 4 controllers seems low and/or expensive, however. > > Hugh LaMaster, m/s 233-9, UUCP ames!lamaster > NASA Ames Research Center ARPA lamaster@ames.arc.nasa.gov > Moffett Field, CA 94035 > Phone: (415)694-6117 IP9,nfs,bbs Sequential write test total 33554432 time 19.910 ms/IO 9 Kb/S 1685 Sequential read test total 33554432 time 22.420 ms/IO 10 Kb/S 1496 Random read test total 8388608 time 14.990 ms/IO 29 Kb/S 559 Multiple processes writing separate files simultaneously total 268435456 time 187.660 ms/IO 11 Kb/S 1430 Multiple processes reading the intermixed files total 268435456 time 216.950 ms/IO 13 Kb/S 1237 Multiple processes reading randomly from the intermixed files total 67108864 time 128.580 ms/IO 31 Kb/S 521 Write 8 files, one at a time total 33554432 time 20.140 ms/IO 9 Kb/S 1666 total 33554432 time 20.110 ms/IO 9 Kb/S 1668 total 33554432 time 20.570 ms/IO 10 Kb/S 1631 total 33554432 time 20.230 ms/IO 9 Kb/S 1658 total 33554432 time 20.870 ms/IO 10 Kb/S 1607 total 33554432 time 19.930 ms/IO 9 Kb/S 1683 total 33554432 time 20.290 ms/IO 9 Kb/S 1653 total 33554432 time 20.510 ms/IO 10 Kb/S 1636 Multiple processes reading the sequentially laid-out files total 268435456 time 202.900 ms/IO 12 Kb/S 1322 Multiple processes reading randomly from the sequentially laid-out files total 67108864 time 123.270 ms/IO 30 Kb/S 544 Disclaimer: This is my opinion. But in this case, it might just be that of my employer as well. markb -- Mark Bradley "Faster, faster, until the thrill of IO Subsystems speed overcomes the fear of death." Silicon Graphics Computer Systems Mountain View, CA ---Hunter S. Thompson