Risc System/6000

[Piercarlo Grandi]

In article <51507 at sgi.sgi.com> markb at denali.sgi.com (Mark Bradley) writes:

   In article <1660 at aber-cs.UUCP>, pcg at 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 at nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg at cs.aber.ac.uk