Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!almsa-1.arpa!control
From: control@ALMSA-1.ARPA (William Martin)
Newsgroups: fa.info-vax
Subject: The value of a VAX 750
Message-ID: <8509201641.AA17976@UCB-VAX.ARPA>
Date: Fri, 20-Sep-85 10:12:34 EDT
Article-I.D.: UCB-VAX.8509201641.AA17976
Posted: Fri Sep 20 10:12:34 1985
Date-Received: Sun, 22-Sep-85 05:33:16 EDT
Sender: daemon@ucbvax.ARPA
Reply-To: info-vax@ucb-vax.arpa
Organization: The ARPA Internet
Lines: 73

The following showed up in a discussion on USENET's net.news, in the
context of designing a stand-alone news-system server and the economics
of such an hypothetical machine. First the quote:

|>From: root@bu-cs.UUCP (Barry Shein)
|
|[This first is a quote from earlier postings, and not by Mr. Shein.]
|> I'm afraid you're grossly underestimating the CPU and disk throughput
|> requirements to put netnews on a machine.  2 of our 5 outbound links, on
|> a 750 used solely as a communications server (Ethernets, DMR-11s, laser
|> printers, etc.), are at high speed.  Guess what -- one uuxqt running rnews
|> and there are no cycles left.  If there are two, reading news will become
|> unpleasant.  Those two plus a print job will totally kill the machine.
|
|(* This was in response to my suggestion to commit an inexpensive box as a
|usenet server at your site, possibly plus working out a faster transport
|as a way to alleviate one aspect of news problems, a small one
|admittedly, but one that comes up frequently *)
|
|I am afraid you are grossly confusing price with cpu power by posing your
|750 as an example.
|
|It is nearly impossible to buy anything these days much slower than a 750
|for more than a few thousand dollars.
|
|My ~$5,000 AT&T 7300 (UNIX/SYSV) apparently will run neck and neck on
|your favorite benchmarks with your $200,000 750* (I own a 750 also,
|without formal benchmarks I believe the benchmarks that show this just
|from using each.) And *THE POINT*: for $5,000 I can use it as an
|intelligent USENET modem without much justification (I suspect you use
|your 750 for much more than a usenet device.) Even if you believe my
|7300 is, what, 25% slower, 40% slower, my argument still is not that
|unreasonable as you seem to complain (and it ain't that much slower.)
|
|Wake up, you, like I, own a curious paper-weight of a past age. Sell it
|to a VMS user (who doesn't have much choice) at 20c or so on the dollar and
|buy something 3-5X the speed (one of the new 68020 boxes with a good winch.)
|[I will, any VMS users interested? unlike a uvax, it has real periphs...]
|
|Obsolescence hurts, ouch! Hey, it was a fine box in its time...(vax.)
|
|	-Barry Shein, Boston University
|
|*NOT floating point, but I don't think that is at issue here.

[Some specifics related to the USENET news system deleted here...]

OK, now my questions:

1) Is this true? (That is, is the 750 essentially an obsolete
paperweight nowadays?)

2) If true, can it be fixed? Are the defects in the 750 so basic that it
cannot be brought up to current standards of good performance by
replacing or upgrading certain parts? If it can be, is it known if DEC
has researched this and is planning to (or already does) provide a path
for making the 750 perform as well as the average new machine of
comparable size? (Or would this not pay well enough to be worth the
effort on DEC's part, and they would put the effort into selling new
machines? If so, how about other aftermarket vendors doing this?)
Or would so much have to be upgraded or replaced to do this that the
cost would make it uneconomic? [Note on this latter point -- to those of
us under the thumb of government procurement regulations and practices,
it is often far easier and simpler to buy "upgrades" or "add-ons" for
existing equipment than to buy a new item, even if the cost for the
former is greater. So "uneconomic" may not be the same for all of us.]

Any comments on the general issue would be welcomed.

Regards, 
Will Martin

ARPA/MILNET: wmartin@almsa-1.ARPA    UUCP/Usenet: seismo!brl-bmd!wmartin