Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!wuarchive!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.unix.ultrix Subject: Re: Slow RA 90 disks on DECsystem 5XXX Message-ID: Date: 26 Dec 90 20:01:13 GMT References: <1990Dec12.194341.18284@bernina.ethz.ch> <28662@mimsy.umd.edu> Sender: pcg@aber-cs.UUCP Distribution: comp Organization: Coleg Prifysgol Cymru Lines: 51 Nntp-Posting-Host: teachk In-reply-to: chris@mimsy.umd.edu's message of 17 Dec 90 05:48:23 GMT On 17 Dec 90 05:48:23 GMT, chris@mimsy.umd.edu (Chris Torek) said: chris> In article <1990Dec12.194341.18284@bernina.ethz.ch> chris> karrer@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@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk