karrer@bernina.ethz.ch (Andreas Karrer) (12/13/90)
We have 6 DEC RA 90 disks, three on a DECsystem 5840 (BI bus, KDB50 controller) and 3 on a DECsystem 5400 (Q-Bus, KDA50 controller). We are not impressed by their performance. Some comparisons: Copy a 10 M file between two partitions on different disks (load average was 0.1 and less in all cases machine disks real sys Convex C 220 NEC D2363 VME 2.5 2.1 sec Sun 4/490 Sabre 1150 IPI 4.9 2.9 Convex C 120 NEC D2363 Multibus 8.2 4.4 * DECsystem 5840 DEC RA 90 KDB ctrlr 29.0 13.4 Sun 3/280 CDC Eagle SMD 33.4 12.9 * DECsystem 5400 DEC RA 90 KDA ctrlr 37.3 10.5 * DEC VAX 11/785 DEC RA 81 41.4 25.1 (Comparison with Convex is probably not fair, these cost a bit more) In short, disk i/o on DEC machines has hardly improved in the last 5 years. (comparison with Convex is not really fair, these cost a bit more). The RA90 are supposed to have a peak transfer rate of 2.8 Mb/sec... And, these RA90 are NOT CHEAP... questions: - Am I doing something wrong here? Yeah I tried upping the bufcache to 25 %, didn't help any. Please no benchmark flames... - does a HSC help? - are there third party disks (faster, cheaper, or both) for the DS 5xxx? +----------- Andi Karrer, Communication Systems, ETH Zuerich, Switzerland karrer@ks.id.ethz.ch
alan@shodha.enet.dec.com ( Alan's Home for Wayward Notes File.) (12/13/90)
In article <1990Dec12.194341.18284@bernina.ethz.ch>, karrer@bernina.ethz.ch (Andreas Karrer) writes: > We have 6 DEC RA 90 disks, three on a DECsystem 5840 (BI bus, KDB50 controller) I have 8 RA90s scattered between two KDB50s and an HSC70 on a VAX 8800. > and 3 on a DECsystem 5400 (Q-Bus, KDA50 controller). I don't anything with a KDA50. The controller itself is about the same speed as the KDB50. Any differences in a similar configuration are due to the bus and CPU. > > We are not impressed by their performance. Some comparisons: For the number presented neither am I. Let's find out why... > > Copy a 10 M file between two partitions on different disks > (load average was 0.1 and less in all cases Here's my table. The file sizes varied because that's what was BIG and handy on that disk. Where it was obvious the was sitting in the buffer cache, I note that. One test I ran twice and pretty close to the same result (2). File size Configuration Bandwidth 10,672 KB RA90 to RA90 on same KDB50. 381 KB/sec. 46,576 KB RA90 to RA90 on same HSC70 375 KB/sec. 77,144 KB RA90 to RA90 different KDB50s. 756 KB/sec. 10,672 KB RA90 on KDB50 to /dev/null 820 KB/sec. 46,576 KB RA90 on HSC70 to /dev/null 716 KB/sec. 10,672 KB Buffer cache to RA90 on KDB50. 711 KB/sec. 10,672 KB Buffer cache to RA90 on HSC70. 711 KB/sec (2). 46,576 KB RA90 on HSC70 to RA90 on KDB50 529 KB/sec. 46,576 KB RA90 on KDB50 to RA90 on HSC70 665 KB/sec. > > questions: > - Am I doing something wrong here? Yeah I tried upping the bufcache to 25 %, > didn't help any. Please no benchmark flames... Are the disks on the SAME controller? Yes, disk to disk on the same KDB50 is relatively slow. If you're going to be doing lots of disk to disk traffic consider splitting the disks between multiple disk controllers. Also consider a KDM70. > - does a HSC help? It depends. If the disks are on the same requestor (like mine) you have the same problem as the same KDB50 to KDB50 case. If the disks are on different requestor it might be better. For a small number of disks you're probably better off with a few KDB50s or KDM70s. After 32 or more about the only way you can get there is multiple HSCs. Please note that KDM70 also supports TA tape drives. > - are there third party disks (faster, cheaper, or both) for the DS 5xxx? I don't know. > > +----------- > Andi Karrer, Communication Systems, ETH Zuerich, Switzerland > karrer@ks.id.ethz.ch -- Alan Rollow alan@nabeth.enet.dec.com
pavlov@canisius.UUCP (Greg Pavlov) (12/15/90)
In article <1990Dec12.194341.18284@bernina.ethz.ch>, karrer@bernina.ethz.ch (Andreas Karrer) writes: > We have 6 DEC RA 90 disks, three on a DECsystem 5840 (BI bus,KDB50 controller) > and 3 on a DECsystem 5400 (Q-Bus, KDA50 controller). > > We are not impressed by their performance. Some comparisons: > > Copy a 10 M file between two partitions on different disks > * DECsystem 5840 DEC RA 90 KDB ctrlr 29.0 13.4 > The best output that I have seen from a KDB controller, driving an RA90 on a 5810, is apx. 100 "logical" i/os/sec, or apx. 800KB/sec, if logical block size is set to 8192 bytes. So the time you report, disk-to-disk on the same controller, is in sync with that (since the controller is reading from one drive and writing to another). If you execute iostat in the background while trying different combinations of reads, e.g., cp file-on-disk1 /dev/null, followed by the same, but put- ting it in background and simultaneously cp file-on-disk2 /dev/null, then do the same with 3 reads from three disks, you will see that the kdb will tend to pump the same TOTAL amount of data, irrespective of number of disks being accessed. E.g., behavior on a par with a cheap and unsophisticated SCSI interface.... > - does a HSC help? Probably. But, depending on your needs and budget, a second KDB may be enough. At $10K list you are paying monopolist's prices, but that's still a fraction of the cost of an HSC..... > - are there third party disks (faster, cheaper, or both) for the DS 5xxx? For the 5400 definitely yes, since the QBUS was invaded a long time ago. Someone else may have some up-to-date info re the BI bus in the 58nn. Note that you don't necessarily need to find something faster. Example: SCSI interfaces for the QBUS can be purchased for less than $2K, compared to the $6K for the KDA (minus discount, of course). So if the SCSI is "only" as fast as the KDA, you can buy at least two for the same price and accrue additional overall performance to boot. greg pavlov, fstrf, amherst, ny pavlov@stewart.fstrf.org
chris@mimsy.umd.edu (Chris Torek) (12/17/90)
In article <1990Dec12.194341.18284@bernina.ethz.ch> karrer@bernina.ethz.ch (Andreas Karrer) writes: >We have 6 DEC RA 90 disks ... >We are not impressed by their performance. I will go *way* out on a limb and make the following claim: DEC have never produced a fast RA disk, with any setup. It would be nice to see some counter-argument. The newer RA series drives *should* not be so slow; their physical characteristics are OK (unlike the RA81). Perhaps the problem is MSCP. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
fingerhu@ircam.fr (Michel Fingerhut) (12/18/90)
In article <28662@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes: > DEC have never produced a fast RA disk, with any setup. We have a 5820, whoops 5810, with 4 ra90. Whenever there is any higher-than-casual disk activity, the load average, from system activity, shoots up. Like, when compi- ling...
alan@shodha.enet.dec.com ( Alan's Home for Wayward Notes File.) (12/18/90)
In article <28662@mimsy.umd.edu>, chris@mimsy.umd.edu (Chris Torek) writes: > In article <1990Dec12.194341.18284@bernina.ethz.ch> > karrer@bernina.ethz.ch (Andreas Karrer) writes: > >We have 6 DEC RA 90 disks ... > >We are not impressed by their performance. > > I will go *way* out on a limb and make the following claim: > > DEC have never produced a fast RA disk, with any setup. > Define fast. All RA disks connect to disk controllers using an SDI cable. The SDI stands for Standard Disk Interconnect and is the protocol used between the disk and controller. I think the fastest you can move bits down this wire is around 2.2 MB/sec. That's as fast as it goes. I have seen the results of VMS based tests where they can read this fast from an RA90. It's actually pretty simple. Issue many asyncronous reads for a track each. As the early reads finish start another one in it's place. The problem of course is that in the real ULTRIX world the largest I/O is typically 8 KB. It's probably similar for most others that use the Fast File System. This is the ideal I/O size for an RA90, RA70 or RA82. That's if you define fast as how many bits you move in a second. How many seeks you can get is a different problem and at least partly depends on the distance you're trying to traverse. > It would be nice to see some counter-argument. The newer RA series > drives *should* not be so slow; their physical characteristics are OK > (unlike the RA81). Perhaps the problem is MSCP. I suspect it more how MSCP is (mis)used. As long as you can keep the MSCP server at the other end busy, you'll get bits about as fast as the wire will allow. If the wire is SDI that's at most about 2.2 MB/sec. If the wire is DSSI then it's around 4 MB/sec. p.s. For reference I'm not a VMS person. About the only thing I use it for is to read VAXnotes and occasionally run VAX Document. > -- > In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) > Domain: chris@cs.umd.edu Path: uunet!mimsy!chris -- Alan Rollow alan@nabeth.enet.dec.com
grr@cbmvax.commodore.com (George Robbins) (12/18/90)
In article <1990Dec17.163638.8785@ircam.fr> fingerhu@ircam.fr (Michel Fingerhut) writes: > In article <28662@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes: > > DEC have never produced a fast RA disk, with any setup. > > We have a 5820, whoops 5810, with 4 ra90. Whenever there is any higher-than-casual > disk activity, the load average, from system activity, shoots up. Like, when compi- > ling... But the MIPS compilers are real CPU/memory hogs - hard to separate this from the disk usage factors. I find that doing backups from HSC/RA90's doesn't seem to have much effect on the interactive response time. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
pcg@cs.aber.ac.uk (Piercarlo Grandi) (12/27/90)
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