Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!purdue!haven!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.arch
Subject: Re: 88000 vs 3081.
Message-ID: <19595@mimsy.UUCP>
Date: 14 Sep 89 22:37:06 GMT
References: <21962@cup.portal.com> <1989Sep12.031453.22947@wolves.uucp> <22130@cup.portal.com>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 26

In article <22130@cup.portal.com> cliffhanger@cup.portal.com (Cliff C Heyer)
writes:
>... Try that on a VAX 11/780 and you'll get at least 800KB/s w/RP06s or 07s.

Nah.

I cannot speak for RP07s, but we have two RP06 washtubs plugged into an
11/785.  You are lucky to get much over 500 KB/s, even doing full-track
reads; put a reasonable file system on top of that and the read rate will
drop, and the write rate will drop even more.  (It is hard to find
well-placed sectors on a full disk, and a 780's cpu does not help.)

In contrast, a CDC Wren V on an async SCSI connected to a Sun 3/175
will typically move 500 KB/s through a Unix file system, even under the
pokey old SunOS code.  (The raw rate is about 1 MB/s, competitive with
Eagles on an Emulex MASSBUS controller.)  On synchronous SCSI, disks
with real servo tracks and current densities will move 3 or 4 MB/s, if
the bus at the other end of the SCSI adapter can handle it (and if the
SCSI adapter itself can handle it).  Cut that in about half for a Unix
file system, unless the controller caches tracks (or, better, cylinders).

(See the papers by Carson and Vongsathorn on adaptive disk rearrangement
and other disk performance studies for some of the reasons for this.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris