Slow RA 90 disks on DECsystem 5XXX

Piercarlo Grandi pcg at cs.aber.ac.uk
Thu Dec 27 07:01:13 AEST 1990


On 17 Dec 90 05:48:23 GMT, chris at mimsy.umd.edu (Chris Torek) said:

chris> In article <1990Dec12.194341.18284 at bernina.ethz.ch>
chris> karrer at bernina.ethz.ch (Andreas Karrer) writes:

karrer> We have 6 DEC RA 90 disks ...
karrer> We are not impressed by their performance.

Your test is to copy 10 MB file from one disk to another. In this way
you measure the filesyem-to-filesystem, and you get several hundred
KB/sec. per disk (time to move 20 meg around 30 sec.). This seems
adequate to me -- it used to be the case that you would not get more
than 100-220KB/sec. from a Unix machine.

Note that on your 5840 what you want to measure is *aggregate* transfer
rates, not peak sequential reads/writes. In a timesharing environment,
especially with a multiprocessor, peak sequential transfer rate is not
that important. Use something like MUSBUS, or (with the due procedure)
BONNIE.

chris> I will go *way* out on a limb and make the following claim:
chris> 	DEC have never produced a fast RA disk, with any setup.

chris> It would be nice to see some counter-argument.  The newer RA
chris> series drives *should* not be so slow; their physical
chris> characteristics are OK (unlike the RA81).  Perhaps the problem is
chris> MSCP.

I too don't think that the problem with DEC (microcode errors apart) is
the disk -- after all they use industry standard technology.

Other systems quoted bu Karrer seem able to do the filesystem-filesystem
copy at hardware speed, over 2MB/sec. Well, they simply have better
device drivers and filesystem implementation. The keep the controller
busier with clever command chaining, and do memory mapped files, which
thing obviates the need for CPU-intensive buffer cache management.

Ultrix is I think still a fairly 4.2BSD derivative, and its disk
performance profile is the one from the well known paper on the FFS.

If I dont' remember erroneously, either Torek or Spencer wrote once that
the Ultrix kernel is so big simply because of sloppy coding, e.g. a
given driver was rewritten to occupy a much small space. Also, the
paging and swapping algorithms of Ultrix have well known and bad
misdesigns (like the AT&T and SUN ones). I suspect this sloppiness is
not just about size, but about speed as well. After all these machines
are wonderfully fast, are they not :-).
--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber.cs at nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg at cs.aber.ac.uk



More information about the Comp.unix.ultrix mailing list