Big Iron I/O

[Mark Bradley]

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 at ames.arc.nasa.gov>, lamaster at 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 at 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