Xref: utzoo comp.unix.aix:605 comp.periphs.scsi:40 Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!brutus.cs.uiuc.edu!zaphod.mps.ohio-state.edu!wuarchive!decwrl!sgi!markb@denali.sgi.com From: markb@denali.sgi.com (Mark Bradley) Newsgroups: comp.unix.aix,comp.periphs.scsi Subject: Re: Risc System/6000 Summary: xfer rates >600 KB/sec Message-ID: <51507@sgi.sgi.com> Date: 23 Feb 90 00:25:16 GMT References: <1660@aber-cs.UUCP> Sender: markb@denali.sgi.com Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 50 In article <1660@aber-cs.UUCP>, pcg@aber-cs.UUCP (Piercarlo Grandi) writes: > In article emv@math.lsa.umich.edu (Edward Vielmetti) writes: > > [ disk options on the RS/6000 > > 23ms, 1.3MB/sec transfer is wimpy for a fast machine. > In this configuration the machine is going to be seriously > i/o bound, without a doubt. > > Pah. The bottleneck is the filesystem, unless you do asynch io via a raw > device. You cannot get more than 600KB per second out of the filesystem in > the best of circumstances, and even that is only achieved, as far I know, by > the MIPS UNIX. Others top out at around 300KB per second. > > Better seek times improve things a bit. Multiple drives, with overlapped > seek and transfer, improve things much more for a timeshared system. It is > here, and not in higher transfer rates (or even seek times) that SCSI wins > over ESDI. But the advantage is nonexistent if you have only one drive. > > If your only worry is single task fast transfer rate (signal/image > processing), be prepared to implement something like the Amoeba or Dartmouth > or Cray file systems. > > The problem is software, not hardware. Pah, indeed. I am measuring >6 MB/sec. through our filesystem today, abeit not with SCSI. Our SCSI (synchronous) is only a bit over 2 MB/sec. on a single drive. Striping and other wonderful *software* things do much more. ---Through the filesystem, mind you.--- And ESDI is much, much faster in certain applications in that one can better sort, queue and optimize the performance that is limited by the speed of the drives' mechnaisms. It must be agreed, however, that if the software does not permit full utilization of the raw speed of the hardware, then the speed of that hardware does very little for one. markb -- Mark Bradley "Faster, faster, until the thrill of I/O Subsystems speed overcomes the fear of death." Silicon Graphics Computer Systems Mountain View, CA 94039-7311 ---Hunter S. Thompson ******************************************************************************** * Disclaimer: Anything I say is my opinion. If someone else wants to use it, * * it will cost... * ********************************************************************************