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: Unibus Disks Message-ID: <3249@ucbvax.ARPA> Date: Tue, 13-Nov-84 13:01:21 EST Article-I.D.: ucbvax.3249 Posted: Tue Nov 13 13:01:21 1984 Date-Received: Thu, 15-Nov-84 01:46:59 EST Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 32 From: lhasa!stew@harvard.ARPA The hypothetical question that you pose is impossible to answer. The Eagle and RA81/UDA50 configurations have quite different characteristics, and the answer is heavily dependant on the type of job you are running. The advantage of the UDA50 is that it does quite a lot of optimization: seek ordering, rotational latency, buffering, etc. In an environment which consisted of, say, several heavy page fault bound processes (for example, large lisp or other GC-based systems) this optimization will have a large effect. In other environments (say, database applications) which do larger bursts, the cpu-controller interface becomes the bottleneck and the Eagle/Massbus emulator configuration wins. The above is probably still a simplification. Furthermore, this neglects the single-vendor shop advantage when it comes to Field Service. And finally, does anyone know how long software updates for foreign controllers lag behind the releases from DEC? This last may only be meaningful for VMS; I don't know what AT&T's and Berkeley's policies are on this. You also don't say how much service will be done by locally trained techs and how much you will rely on DEC Field Service. How far away is the SI office? Is there really no cost difference? The monthly maintenance on the RA81's is amazingly low. Be sure to take that into account. For my setup, a number of large page-fault bound jobs at an otherwise all-DEC VMS site, the UDA50/RA81 combo was the clear choice. However, anyone who answers your query in 25 words or less is not answering it for you, they are answering it for them. Stew Rubenstein Harvard Chemistry