Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 8/7/84; site ucbvax.ARPA
Path: utzoo!linus!decvax!decwrl!ucbvax!info-vax
From: info-vax@ucbvax.ARPA
Newsgroups: fa.info-vax
Subject: Re: 8600 performance?
Message-ID: <3221@ucbvax.ARPA>
Date: Mon, 12-Nov-84 18:31:36 EST
Article-I.D.: ucbvax.3221
Posted: Mon Nov 12 18:31:36 1984
Date-Received: Tue, 13-Nov-84 06:35:36 EST
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 20

From: Mike O'Brien <obrien@CSNET-SH.ARPA>

	It's true that the MASSBUS stuff is not at all competitive, but
when you start to consider second vendors plus other things on the
UNIBUS, the picture becomes far less clear.  As of now, the price/performance
of second-vendor MASSBUS disk systems is very favorable when compared
to DEC UNIBUS disks (that is, they're about even).  Plus, things like
LAN's compete fiercely for UNIBUS cycles, and they have no MASSBUS
alternatives.  Consequently, for a sizeable system, about the only
thing to do is to buy a second UNIBUS adaptor: one for the disks and
one for the LAN (put the terminals wherever you want; their burst rates
are not that difficult to handle).  This definitely runs into money.
So, while arguments about intelligent controllers vs. burst rate
are kosher when taken alone, the Big Wide World is harder to figure.

	[Even on its own merits, using a buffer in the controller to preclude
the necessity of a high burst rate into main memory only holds if the
cache size is large compared with the typical transfer.  On a 4.2BSD
UNIX 8K file system, two file system block reads will fill the UDA-50 buffer
cache.  Upshot: I'm still looking at Emulex/Fuji.]