Xref: utzoo comp.unix.aix:679 comp.periphs.scsi:94 Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!rupert!pcg From: pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.unix.aix,comp.periphs.scsi Subject: Re: Risc System/6000 Message-ID: Date: 2 Mar 90 18:43:00 GMT References: <1660@aber-cs.UUCP> <51507@sgi.sgi.com> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 51 In-reply-to: markb@denali.sgi.com's message of 23 Feb 90 00:25:16 GMT Posting-Front-End: GNU Emacs 18.47.1 of Wed Mar 15 1989 on rupert (berkeley-unix) In article <51507@sgi.sgi.com> markb@denali.sgi.com (Mark Bradley) writes: In article <1660@aber-cs.UUCP>, pcg@aber-cs.UUCP (Piercarlo Grandi) writes: > 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. [ ... ] Andrew Koenig in another message reports that some 88K Tek machine also gets up to 600KB second (cheers!) and some other machines get to 450KB/sec. Actually, even some SUNs get to that mark. Your average workstation will only do 150-200KB/sec. (which is horrid, considering that I get that much out of a System V filesystem structure, when clean, on my home 386 with an RLL controller), and at most around 300KB. > 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.--- Oh yeah. Thanks for supporting my contention/complaint. Now, if only other people took heed from the likes of you and reimplemented the filesystem software. The FFS paper is very clear about what are the limits of the BSD design (But I think it has others, actually). I would not go as far as the Amoeba filesystem (files as *contiguous* lumps of disc space, transferred in one IO operation from disc to memory or viceversa, damn external fragmentation, and this works because Unix files are on average minuscule). The Dartmouth flexible extent based filesystem with daemonic compaction looks good enough to me. 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. This is the notorious problem that SCSI will hide from the OS the drive geometry (down to sector remapping, wich can be really nasty), which of course pays put to many nice optimizations. On the other hand, ESDI (on PCs, where it is most popular) has the non trivial problem that controllers are on average not multithreaded. Pah again. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk