Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site scirtp.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!mcnc!rti-sel!scirtp!dfh
From: dfh@scirtp.UUCP (David F. Hinnant)
Newsgroups: net.arch,net.micro.att
Subject: AT&T MIPS claim
Message-ID: <577@scirtp.UUCP>
Date: Wed, 28-May-86 23:56:53 EDT
Article-I.D.: scirtp.577
Posted: Wed May 28 23:56:53 1986
Date-Received: Fri, 30-May-86 08:36:38 EDT
Distribution: net
Organization: SCI Systems, Research Triangle Park, NC
Lines: 15
Xref: watmath net.arch:3329 net.micro.att:1230
I just read some trade rag that had an ad in it from Ma Bell about
the UNIX PC. They made this interesting claim that the UNIX PC gives
you "75% of the power of a VAX 11/780" for "only 7% of the cost".
Arrgh. Come on guys. If I wanted to hear propaganda I'd plug Intel
into one ear and Motorola in the other. Is this the MIP rating for the
68010 as compared to the VAX? Looks like it. One really couldn't ask
for a better example of the Meaningless Index of Performance. I've seen
many a 780 run with more than 20 users. I'd like to see you put that
many on a UNIX PC that I found can barely support one.
--
David Hinnant
SCI Systems, Inc.
...{decvax, akgua}!mcnc!rti-sel!scirtp!dfh
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!
enmasse!comm!dave
From: dave@comm.UUCP (Dave Brownell)
Newsgroups: net.arch,net.micro.att
Subject: Re: AT&T MIPS claim
Message-ID: <266@comm.UUCP>
Date: Thu, 29-May-86 10:10:55 EDT
Article-I.D.: comm.266
Posted: Thu May 29 10:10:55 1986
Date-Received: Sat, 31-May-86 04:36:29 EDT
References: <577@scirtp.UUCP>
Reply-To: dave@comm.UUCP (Dave Brownell)
Distribution: net
Organization: EnMasse Computer Corp, Acton, MA
Lines: 18
Xref: watmath net.arch:3331 net.micro.att:1233
In article <577@scirtp.UUCP> dfh@scirtp.UUCP (David F. Hinnant) writes:
> ... They made this interesting claim that the UNIX PC gives
> you "75% of the power of a VAX 11/780" for "only 7% of the cost".
> Arrgh. ... Is this the MIP rating for the
> 68010 as compared to the VAX? Looks like it. One really couldn't ask
> for a better example of the Meaningless Index of Performance. I've seen
> many a 780 run with more than 20 users. I'd like to see you put that
> many on a UNIX PC that I found can barely support one.
This is Apples and Oranges ... a MIP, however meaningless, is a CPU benchmark,
and a "user" is a rather ill-defined I/O benchmark ... and I do believe
the I/O on the 7300 is not up to the CPU. Maybe when someone comes up
with a realistic I/O benchmark we can really start comparing UNIX hardware.
(Yes, that marketing claim is absurd.)
--
Dave Brownell
EnMasse Computer Corporation
{genrad,harvard}!enmasse!comm!dave
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site sfsup.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!mhuxm!sftig!sfsup!mjs
From: mjs@sfsup.UUCP (M.J.Shannon)
Newsgroups: net.arch,net.micro.att
Subject: Re: AT&T MIPS claim
Message-ID: <286@sfsup.UUCP>
Date: Fri, 30-May-86 02:12:49 EDT
Article-I.D.: sfsup.286
Posted: Fri May 30 02:12:49 1986
Date-Received: Sat, 31-May-86 07:27:16 EDT
References: <577@scirtp.UUCP> <266@comm.UUCP>
Reply-To: mjs@sfsup.UUCP (M.J.Shannon)
Distribution: net
Organization: AT&T Information Systems, Summit N.J.
Lines: 30
Xref: watmath net.arch:3338 net.micro.att:1235
In article <266@comm.UUCP> dave@comm.UUCP (Dave Brownell) writes:
>In article <577@scirtp.UUCP> dfh@scirtp.UUCP (David F. Hinnant) writes:
>> ... They made this interesting claim that the UNIX PC gives
>> you "75% of the power of a VAX 11/780" for "only 7% of the cost".
>> Arrgh. ... Is this the MIP rating for the
>> 68010 as compared to the VAX? Looks like it. One really couldn't ask
>> for a better example of the Meaningless Index of Performance. I've seen
>> many a 780 run with more than 20 users. I'd like to see you put that
>> many on a UNIX PC that I found can barely support one.
>
>This is Apples and Oranges ... a MIP, however meaningless, is a CPU benchmark,
>and a "user" is a rather ill-defined I/O benchmark ... and I do believe
>the I/O on the 7300 is not up to the CPU.
On the other hand, if you stuff 8 Meg into a UNIX PC, put an RP07 or an RA81
or similar sort of large, fast disk on it, you get the quoted horsepower at
a considerable, but less than 100% cost of the 780. If you don't consider
"optional" equipment when comparing 2 boxes, you aren't REALLY comparing them.
If you don't consider "equivalent configuration" you're in the wrong ballpark.
Not that I'm defending the claim in the glossy literature -- I'm not (and
can't) -- but, with similar configurations, the claim is accurate in its
description of the power of the UNIX PC. Dave Brownell's comment also applies.
--
Marty Shannon
UUCP: ihnp4!attunix!mjs
Phone: +1 (201) 522 6063
Disclaimer: I speak for no one.
"If I never loved, I never would have cried." -- Simon & Garfunkel
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!rochester!rocksanne!sunybcs!kitty!
bakerst!kathy
From: kathy@bakerst.UUCP (Kathy Vincent)
Newsgroups: net.arch,net.micro.att
Subject: Re: AT&T MIPS claim
Message-ID: <124@bakerst.UUCP>
Date: Sat, 31-May-86 08:24:36 EDT
Article-I.D.: bakerst.124
Posted: Sat May 31 08:24:36 1986
Date-Received: Tue, 3-Jun-86 22:25:01 EDT
References: <577@scirtp.UUCP>
Distribution: net
Organization: bakerst, Winston-Salem, NC
Lines: 25
Xref: linus net.arch:3047 net.micro.att:1256
Summary: users on UNIX PC
In article <577@scirtp.UUCP>, dfh@scirtp.UUCP (David F. Hinnant) writes:
>
> ... I've seen
> many a 780 run with more than 20 users. I'd like to see you put that
> many on a UNIX PC that I found can barely support one.
Be fair, now. What setup of UNIX PC were you looking at?
My UNIX PC has 2 MB RAM and a 67 MB disk.
Granted, it won't support * 20 * users, but it certainly handles
more than ONE user. I've had 3 users on at one time and everything
ran just beautifully.
--
Kathy Vincent
==========================================================
kitty
Home at ihnp4! < > !bakerst!kathy
wruxi
mcnc!ethos!bakerst!kathy
AT&T at ihnp4!wruxi!unix
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!prls!pyramid!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.arch,net.micro.att
Subject: Re: AT&T MIPS claim
Message-ID: <3847@sun.uucp>
Date: Sat, 31-May-86 19:14:43 EDT
Article-I.D.: sun.3847
Posted: Sat May 31 19:14:43 1986
Date-Received: Tue, 3-Jun-86 22:36:51 EDT
References: <577@scirtp.UUCP>
Distribution: net
Organization: Sun Microsystems, Inc.
Lines: 29
Xref: linus net.arch:3048 net.micro.att:1257
> I just read some trade rag that had an ad in it from Ma Bell about
> the UNIX PC. They made this interesting claim that the UNIX PC gives
> you "75% of the power of a VAX 11/780" for "only 7% of the cost".
What's even funnier about that ad is that it shows a bunch of superminis in
the background, which the UNIX PC can presumably replace. Several of the
cabinets in the background clearly read "3B20"....
> Is this the MIP rating for the 68010 as compared to the VAX?
That's a number I've heard for the 010. (I also know of a certain company
which claims their 12.5MhZ 68010 machine is 1.2 x an 11/780. I think they
claim this based on some real benchmarks, but I find it hard to believe. I
suspect they got this figure by figuring:
The 11/780 is a 5MhZ 32-bit machine. A 12.5 Mhz 16-bit (sort of)
machine like the 68010 must therefore be (12.5/5)*(16/32) == 1.25
11/780s.
> I've seen many a 780 run with more than 20 users. I'd like to see you
> put that many on a UNIX PC that I found can barely support one.
Not fair. The UNIX PC is not a 68010, it's a 68010 surrounded with other
chips and peripherals. The MIPS rating of a chip is even more meaningless
when you put it into a system.
--
Guy Harris
{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
g...@sun.arpa
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!caip!princeton!allegra!ulysses!
mhuxr!mhuxn!ihnp4!houxm!mtuxo!hsc
From: hsc@mtuxo.UUCP (h.cohen)
Newsgroups: net.arch,net.micro.att
Subject: Re: AT&T MIPS claim
Message-ID: <1633@mtuxo.UUCP>
Date: Mon, 2-Jun-86 17:30:29 EDT
Article-I.D.: mtuxo.1633
Posted: Mon Jun 2 17:30:29 1986
Date-Received: Wed, 4-Jun-86 07:21:14 EDT
References: <577@scirtp.UUCP>
Organization: AT&T Information Systems Labs, Holmdel NJ
Lines: 12
Xref: linus net.arch:3067 net.micro.att:1268
> I just read some trade rag that had an ad in it from Ma Bell about
>the UNIX PC. They made this interesting claim that the UNIX PC gives
>you "75% of the power of a VAX 11/780" for "only 7% of the cost".
>Arrgh. Come on guys. If I wanted to hear propaganda I'd plug Intel
>into one ear and Motorola in the other. Is this the MIP rating for the
>68010 as compared to the VAX? Looks like it. One really couldn't ask
>for a better example of the Meaningless Index of Performance. I've seen
>many a 780 run with more than 20 users. I'd like to see you put that
>many on a UNIX PC that I found can barely support one.
The comparison was made with 512K of memory and a 10MB disk in each
machine :-)
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!mcnc!rti-sel!scirtp!jimi
From: jimi@scirtp.UUCP (Jim Ingram)
Newsgroups: net.arch,net.micro.att
Subject: Re: AT&T MIPS claim
Message-ID: <583@scirtp.UUCP>
Date: Mon, 2-Jun-86 17:33:36 EDT
Article-I.D.: scirtp.583
Posted: Mon Jun 2 17:33:36 1986
Date-Received: Wed, 4-Jun-86 00:38:21 EDT
References: <577@scirtp.UUCP> <124@bakerst.UUCP>
Distribution: net
Organization: SCI Systems, Research Triangle Park, NC
Lines: 51
Xref: linus net.arch:3058 net.micro.att:1264
> In article <577@scirtp.UUCP>, dfh@scirtp.UUCP (David F. Hinnant) writes:
> >
> > ... I've seen
> > many a 780 run with more than 20 users. I'd like to see you put that
> > many on a UNIX PC that I found can barely support one.
>
> Be fair, now. What setup of UNIX PC were you looking at?
> My UNIX PC has 2 MB RAM and a 67 MB disk.
> Granted, it won't support * 20 * users, but it certainly handles
> more than ONE user. I've had 3 users on at one time and everything
> ran just beautifully.
>
>
> --
>
> Kathy Vincent
> ==========================================================
>
> kitty
> Home at ihnp4! < > !bakerst!kathy
> wruxi
>
> mcnc!ethos!bakerst!kathy
>
> AT&T at ihnp4!wruxi!unix
I don't plan to present arguments that address previous postings in detail,
because it seems the point has shifted. The ridiculous claim in the ad is
that the UNIX PC has 75% of the power of a DEC VAX 11/780.
If this is true, I should be able to replace 3 VAX 11/780 with 4 UNIX PCs
(and support the 100 - 120 users on the Vaxen).
To claim such a replacement ratio, as the ad does, is clearly dishonest.
A more realistic, but still rather absurd, replacement would be to replace
a VAX 11/780 with 13 UNIX PCs, assuming that each UNIX PC will support 3
users as Ms. Vincent states. This would cost 115% of an VAX 11/780 if
the "7% of a VAX" cost statement is correct.
AT&T should be fair and honest in its claims. They haven't been.
The AT&T ad is a good example of taking an irrelevant measure of raw
processor speed and building a lie from it.
--
The views expressed by me are my own and do not necessarily
represent the views of any other individuals or organizations.
Jim Ingram {decvax, akgua, ihnp4}!mcnc!rti-sel!scirtp!jimi
SCI Systems, Inc. P.O. Box 12557, RTP, NC 27709 919 549 8334
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!ihnp4!ihdev!pdg
From: pdg@ihdev.UUCP (P. D. Guthrie)
Newsgroups: net.arch,net.micro.att
Subject: Re: AT&T MIPS claim
Message-ID: <654@ihdev.UUCP>
Date: Wed, 4-Jun-86 16:19:16 EDT
Article-I.D.: ihdev.654
Posted: Wed Jun 4 16:19:16 1986
Date-Received: Sat, 7-Jun-86 14:25:15 EDT
References: <577@scirtp.UUCP> <124@bakerst.UUCP> <583@scirtp.UUCP>
Reply-To: pdg@ihdev.UUCP (55224-P. D. Guthrie)
Distribution: net
Organization: AT&T Bell Laboratories
Lines: 74
Xref: watmath net.arch:3384 net.micro.att:1267
In article <583@scirtp.UUCP> jimi@scirtp.UUCP (Jim Ingram) writes:
>I don't plan to present arguments that address previous postings in detail,
>because it seems the point has shifted. The ridiculous claim in the ad is
>that the UNIX PC has 75% of the power of a DEC VAX 11/780.
>
Hmm. I would say that 1111 Dhrystones (REG) vs 1562 Dhrystones (REG)
(both running SysV) is pretty close (71%). Why is this claim so
ridiculous? What better method of *processor* comparison can you come
up with?
>If this is true, I should be able to replace 3 VAX 11/780 with 4 UNIX PCs
>(and support the 100 - 120 users on the Vaxen).
>
Not at all. The way I read the `ridiculous claim', the benchmark
measurement fully justifies it. It could be construed as misleading to
those who completely justify computer purchases wholely on processor
speed, and (like the above statement to do with loading users onto both)
fail to take into account speed of peripherals, memory management
techniques and other important considerations.
>To claim such a replacement ratio, as the ad does, is clearly dishonest.
>
No, as explained above.
>A more realistic, but still rather absurd, replacement would be to replace
>a VAX 11/780 with 13 UNIX PCs, assuming that each UNIX PC will support 3
>users as Ms. Vincent states. This would cost 115% of an VAX 11/780 if
>the "7% of a VAX" cost statement is correct.
>
Well, this is quite correct, but ATT was surely not trying to tell those
prospective DEC-VAX buyers that they could buy a UNIX PC instead and just
suffer a small speed reduction and no other trade-offs. A smart buyer
in the market for a vax-sized machine is not even going to consider the
UNIX-PC, but a smart buyer in the PC market hopefully will because ATT
has *correctly* billed the power of the UNIX PC, and the PC buyer knows
the limitations of the class of computer system he is in the market for.
>AT&T should be fair and honest in its claims. They haven't been.
>The AT&T ad is a good example of taking an irrelevant measure of raw
>processor speed and building a lie from it.
>
Those are very harsh words for a machine that *can* back up the ad, in
the sense of benchmarks. As I mentioned above, although the processor
speed is important, there are many other considerations to be tken into
account. They are not building a `lie' from this. Rather if a buyer
does not take other factors into account, he deserves what he gets.
They are merely playing up one of the better and more important aspects
of their machine. Is Mercedes building a lie when they say that their
cars are the best crashed tested in the world? They can back up that
claim (I hope), but this is not the only thing to take into account when
buying a car. This is advertizing. Welcome to the real world.
Besides, I don't think that DEC is going to lose a lot of VAX
sales from this. :-)
>--
>
> The views expressed by me are my own and do not necessarily
> represent the views of any other individuals or organizations.
>
>Jim Ingram {decvax, akgua, ihnp4}!mcnc!rti-sel!scirtp!jimi
>SCI Systems, Inc. P.O. Box 12557, RTP, NC 27709 919 549 8334
I guess I need a disclaimer here - Although ATT will show up in my
organization line I don't work for them.
--
Paul Guthrie `See the happy moron, he doesn't give a damn.
ihnp4!ihdev!pdg I wish I were a moron. My God! Perhaps I am.'
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!mcnc!rti-sel!scirtp!jimi
From: jimi@scirtp.UUCP (Jim Ingram)
Newsgroups: net.arch,net.micro.att
Subject: Re: AT&T MIPS claim
Message-ID: <585@scirtp.UUCP>
Date: Mon, 9-Jun-86 19:11:10 EDT
Article-I.D.: scirtp.585
Posted: Mon Jun 9 19:11:10 1986
Date-Received: Wed, 11-Jun-86 06:24:02 EDT
References: <577@scirtp.UUCP> <124@bakerst.UUCP> <583@scirtp.UUCP> <654@ihdev.UUCP>
Distribution: net
Organization: SCI Systems, Research Triangle Park, NC
Lines: 118
Xref: linus net.arch:3103 net.micro.att:1294
> In article <583@scirtp.UUCP> jimi@scirtp.UUCP (Jim Ingram) writes:
> >I don't plan to present arguments that address previous postings in detail,
> >because it seems the point has shifted. The ridiculous claim in the ad is
> >that the UNIX PC has 75% of the power of a DEC VAX 11/780.
> >
>
> Hmm. I would say that 1111 Dhrystones (REG) vs 1562 Dhrystones (REG)
> (both running SysV) is pretty close (71%). Why is this claim so
> ridiculous? What better method of *processor* comparison can you come
> up with?
>
The ad isn't talking about "*processor*" power, it's talking about
"computing power." I still find the claim ridiculous.
If AT&T was talking explicitly about "*processor*" speed then talking
Dhrystones would make sense. Besides, where does the ad mention or refer
to Dhrystones, or any other benchmark?
Since processor speed is not the issue, system performance should be
measured at the system level, including I/O bandwidth, storage capacities,
etc. This would provide a much more valid comparison of the two systems.
> >If this is true, I should be able to replace 3 VAX 11/780 with 4 UNIX PCs
> >(and support the 100 - 120 users on the Vaxen).
> >
>
> Not at all. The way I read the `ridiculous claim', the benchmark
> measurement fully justifies it. It could be construed as misleading to
> those who completely justify computer purchases wholely on processor
> speed, and (like the above statement to do with loading users onto both)
> fail to take into account speed of peripherals, memory management
> techniques and other important considerations.
>
AT&T, in their ad copy which wrongly focuses on processor speed, states
that the UNIX PC "puts room-size computing power right on a desktop."
Their ad is particularly misleading to those who want to avoid buying
hardware based solely on CPU speed, since they do not let the reader
know that they're comparing systems with CPU-only, unnamed, unreferenced
benchmarks.
(What "benchmark measurement" are you talking about now?)
> >To claim such a replacement ratio, as the ad does, is clearly dishonest.
> >
>
> No, as explained above.
>
Since AT&T claims to provide "room-size computing power on a desktop,"
such a replacement ratio is implied.
> >A more realistic, but still rather absurd, replacement would be to replace
> >a VAX 11/780 with 13 UNIX PCs, assuming that each UNIX PC will support 3
> >users as Ms. Vincent states. This would cost 115% of an VAX 11/780 if
> >the "7% of a VAX" cost statement is correct.
> >
>
> Well, this is quite correct, but ATT was surely not trying to tell those
> prospective DEC-VAX buyers that they could buy a UNIX PC instead and just
> suffer a small speed reduction and no other trade-offs. A smart buyer
> in the market for a vax-sized machine is not even going to consider the
> UNIX-PC, but a smart buyer in the PC market hopefully will because ATT
> has *correctly* billed the power of the UNIX PC, and the PC buyer knows
> the limitations of the class of computer system he is in the market for.
>
I think AT&T wasn't thinking about "smart" computer buyers - the ad's
hooks all focus on naive and uninitiated buyers - especially those who
may be fooled by the claims in the ad.
> >AT&T should be fair and honest in its claims. They haven't been.
> >The AT&T ad is a good example of taking an irrelevant measure of raw
> >processor speed and building a lie from it.
> >
>
> Those are very harsh words for a machine that *can* back up the ad, in
> the sense of benchmarks. As I mentioned above, although the processor
> speed is important, there are many other considerations to be tken into
> account. They are not building a `lie' from this. Rather if a buyer
> does not take other factors into account, he deserves what he gets.
> They are merely playing up one of the better and more important aspects
> of their machine. Is Mercedes building a lie when they say that their
> cars are the best crashed tested in the world? They can back up that
> claim (I hope), but this is not the only thing to take into account when
> buying a car. This is advertizing. Welcome to the real world.
> Besides, I don't think that DEC is going to lose a lot of VAX
> sales from this. :-)
>
Perhaps I was a bit harsh... but I still feel AT&T was dishonest. If a
dishonest statement is not a lie, what is it? All the stuff about Mercedes
attempts to shift the point, as does the comment re the "real world."
Making a statement that someting "provides 75% of the power" for "7% of
the cost" implies that the less powerful, less expensive item is somehow
a reasonable replacement for the more expensive item.
Whether a UNIX PC is a better machine for many users now on Vaxen isn't
the point of the ad. The point of the ad is a misleading comparison of
two different systems that have few common applications (at the system-
level), with the comparison skewed falsely in favor of the advertised
product.
What is especially galling is the lack of substantiation for the advertised
claim. Dhrystones? How could we know that AT&T's claim was based on Dhry-
stones? (Not that it would really make a difference....)
>
> I guess I need a disclaimer here - Although ATT will show up in my
> organization line I don't work for them.
>
This is a good example of ambiguity.
>
> --
>
> Paul Guthrie `See the happy moron, he doesn't give a damn.
> ihnp4!ihdev!pdg I wish I were a moron. My God! Perhaps I am.'
--
The views expressed by me are my own and do not necessarily
represent the views of any other individuals or organizations.
Jim Ingram {decvax, akgua, ihnp4}!mcnc!rti-sel!scirtp!jimi
SCI Systems, Inc. P.O. Box 12557, RTP, NC 27709 919 549 8334
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!
bellcore!decvax!decwrl!glacier!mips!mash
From: mash@mips.UUCP
Newsgroups: net.arch,net.micro.att
Subject: Re: AT&T MIPS claim [please, no more; power = jillions]
Message-ID: <504@mips.UUCP>
Date: Thu, 12-Jun-86 03:34:01 EDT
Article-I.D.: mips.504
Posted: Thu Jun 12 03:34:01 1986
Date-Received: Sun, 15-Jun-86 07:33:00 EDT
References: <577@scirtp.UUCP> <124@bakerst.UUCP> <583@scirtp.UUCP>
<654@ihdev.UUCP> <585@scirtp.UUCP>
Reply-To: mash@mips.UUCP (John Mashey)
Distribution: net
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 33
Xref: watmath net.arch:3423 net.micro.att:1283
Could we summarize this, and then go on to something more useful?
SUMMARY:
1) FACT: it is well-known that a well-tuned, 10Mhz 68010 runs integer-type
UNIX user programs at about .7 (give or take .1) the rate of the
corresponding 11/780. The UNIX PC is one of the former.
2) OPINION: "power" is not even close to being a well-defined term. It's like
the movie "Used Cars", where the bad guys try to jail the heroine
for false advertising in claiming she had "jillions" of cars on the lot.
The sheriff says "No. What's a jillion?"
3) OPINION: people aren't impressed by the ad [which is OK], but claiming that
AT&T is evil because "power" really = {something else, not particularly
well defined, either} seems to have little relevance to net.arch.
Some of the arguments are "domain" arguments, i.e., "I think power =
integer performance" vs "you're wrong, power = how many users you can support",
etc.
SUGGESTIONS:
1) PLEASE: extended discussions of the relative slime-level of advertising
probably don't belong in net.arch.
2) The discussion brings to mind a more useful discussion:
a) What are product domains? How do you specify them?
[I.e., a sample domain might be single-user, office system, used mostly
for office applications...]
b) What are the relevant metrics for comparing products within the
same domain?
It's very hard to say anything useful about b) without getting some agreement,
or at least some definitions of a). A lot of useless arguments evaporate
if you preface them with domain-limiters like "in my experience, which is ..."
or "for a <specified> class of product, what's important is..."
--
-john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD: 408-720-1700, x253
USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!caip!
andromeda!njitcccc!ken
From: ken@njitcccc.UUCP (Kenneth Ng)
Newsgroups: net.arch,net.micro.att
Subject: Re: AT&T MIPS claim
Message-ID: <206@njitcccc.UUCP>
Date: Thu, 12-Jun-86 23:18:17 EDT
Article-I.D.: njitcccc.206
Posted: Thu Jun 12 23:18:17 1986
Date-Received: Tue, 17-Jun-86 07:06:54 EDT
References: <577@scirtp.UUCP> <124@bakerst.UUCP> <583@scirtp.UUCP>
<585@scirtp.UUCP>
Distribution: net
Organization: NJ Inst of Tech., Newark NJ
Lines: 42
Xref: watmath net.arch:3428 net.micro.att:1284
In article <585@scirtp.UUCP>, jimi@scirtp.UUCP (Jim Ingram) writes:
> >
> Perhaps I was a bit harsh... but I still feel AT&T was dishonest. If a
> dishonest statement is not a lie, what is it? All the stuff about Mercedes
> attempts to shift the point, as does the comment re the "real world."
> Making a statement that someting "provides 75% of the power" for "7% of
> the cost" implies that the less powerful, less expensive item is somehow
> a reasonable replacement for the more expensive item.
You know, a lot of this discussion revolves around the assumption
that if you want the power of a vax 11/780, one would buy a vax
11/780. A friend of mine who works for DEC says that if you were
solely interested in raw cpu power you would not buy a 780, you
would buy the microvax II, which costs far less than the 780,
but has 90% of its power, in cpu intensive applications. He also
mentioned a couple of other important things. First, the 780 is
an all purpose performance machine (for its day). It was designed
to handle multitasking multiprocess environments well. It has
a one instruction "switch task", which I believe the 68000 lacks.
The 780 has virtual memory, does the Unix PC? The benchmarks do
not test the i/o capabilities of the machine, which in a multitask
environment is often the bottleneck. Furthermore, the Unix PC runs
Unix (obviously), where the main bottleneck of the machine is its
i/o. All in all I do feel that the ad is somewhat misleading.
But hopefully, prospective buyers will ignore the ad and get
some real facts on what the machine is capable of doing.
P.S. Does anyone know what the price ratio between the Vax 11/780
and the Microvax II is?
--
Kenneth Ng: uucp(unreliable) ihnp4!allegra!bellcore!njitcccc!ken
soon uucp...@rigel.cccc.njit.edu
bitnet(prefered) ken@njitcccc.bitnet
soon bitnet: k...@orion.cccc.njit.edu
(Yes, we are slowly moving to RCF 920, kicking and screaming)
New Jersey Institute of Technology
Computerized Conferencing and Communications Center
Newark, New Jersey 07102
Vulcan jealousy: "I fail to see the logic in prefering Stonn over me"
Movie "Short Circuit": Number 5: "I need input"
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!prls!pyramid!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.arch,net.micro.att
Subject: Re: AT&T MIPS claim
Message-ID: <4138@sun.uucp>
Date: Sat, 14-Jun-86 01:20:57 EDT
Article-I.D.: sun.4138
Posted: Sat Jun 14 01:20:57 1986
Date-Received: Sun, 15-Jun-86 04:20:49 EDT
References: <577@scirtp.UUCP> <124@bakerst.UUCP> <583@scirtp.UUCP>
<585@scirtp.UUCP> <206@njitcccc.UUCP>
Distribution: net
Organization: Sun Microsystems, Inc.
Lines: 17
Xref: linus net.arch:3124 net.micro.att:1298
> It was designed to handle multitasking multiprocess environments well.
> It has a one instruction "switch task", which I believe the 68000 lacks.
The 68000 does, indeed, not have a single "switch task" instruction, but who
cares? The fact that operation X is performed by a single instruction in no
way implies that operation X is exceptionally fast. Furthermore, I have no
idea how much of the task-switch time on VMS or UNIX is spent doing what the
"load process context" instruction does; it has to figure out which task to
run, for instance, which adds a few more instructions.
> The 780 has virtual memory, does the Unix PC?
Yes.
--
Guy Harris
{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
g...@sun.com (or guy@sun.arpa)
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!
decvax!decwrl!glacier!mips!mash
From: mash@mips.UUCP
Newsgroups: net.arch,net.micro.att
Subject: Re: AT&T MIPS claim [really task-switching]
Message-ID: <506@mips.UUCP>
Date: Sat, 14-Jun-86 19:57:58 EDT
Article-I.D.: mips.506
Posted: Sat Jun 14 19:57:58 1986
Date-Received: Tue, 17-Jun-86 10:26:29 EDT
References: <577@scirtp.UUCP> <124@bakerst.UUCP> <583@scirtp.UUCP>
<585@scirtp.UUCP> <206@njitcccc.UUCP> <4138@sun.uucp>
Reply-To: mash@mips.UUCP (John Mashey)
Distribution: net
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 50
Xref: watmath net.arch:3449 net.micro.att:1291
In article <4138@sun.uucp> guy@sun.uucp (Guy Harris) writes:
>...
>The 68000 does, indeed, not have a single "switch task" instruction, but who
>cares? The fact that operation X is performed by a single instruction in no
>way implies that operation X is exceptionally fast. Furthermore, I have no
>idea how much of the task-switch time on VMS or UNIX is spent doing what the
>"load process context" instruction does; it has to figure out which task to
>run, for instance, which adds a few more instructions.
Guy is right on; furthermore:
1) Register save/restores speed are almsot entirely dominated by memory
system time anyway.
2) When measured by the "2 processes writing 1 byte circularly thru
pipes" benchmark, each complete UNIX context switch takes on the order of
700 microseconds on a 780. Actual register save/restore time is dominated by
write-stalls and data cache misses, which are a function of the memory
system, not of the instruction set. The only real difference is in
extra instruction-cache misses one may hit by having to do a sequence
of loads/stores instead of single micro-coded instructions.
Having looked at the code, I guarantee that most of the code is doing other
things than saving/restoring registers.
3) Let's try some back-of-the-envelope numbers:
a) At 60 cs/second (typical) and 700 usec/cs, the VAX would spend
60*700 = 42,000 usecs, or about 4.2% of the time doing conxtext
switches.
b) Supposing that that 10% of this time is actually in save/restore,
about .4% of the machine might be spent in save/restore
(SVPCTX/LDPCTX). Of course, they might be used for other things also.
4) Now, let's try published data: Clark & Levy, "Measurement and Analysis of
Instruction Use in the VAX 11/780", 9th Ann. Symp. on Comp. Arch,
April 1982.
a) LDPCTX and SVPCTX aren't on the top 25 in usage of CPU time,
even in VMS Kernel mode. The top 25 instructions use 62% of the
total kernel time, and the smallest shown is REMQUE with 1.31%.
This was for multi-user workloads.
b) MTPR (Move to Processor Register) used 5.27% of the kernel time,
and 1.15% of the total CPU time for all processor modes. From this,
I infer that the kernel was using 21% of the CPU (1.15/5.27).
Hence, the most time-consuming of LDPCTX/SVPCTX could be consuming
no more than 1.31% of the kernel, or .27% of the total CPU. Even
both together could account for no more than .54% of the total CPU.
5) All of this is consistent in bounding the problem: for time-sharing
systems like VAXen, the special context save/restore instructions contribute
at most half a percent to performance. [Reminder: this says nothing about
whether such instructions are important for real-time systems or other
environments. Also, some forms of these instructions have important
structural properties or other rationales, but NOT SPEED IN THIS DOMAIN.]
--
-john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD: 408-720-1700, x253
USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!caip!sri-spam!
mordor!lll-crg!seismo!rochester!ur-tut!tuba
From: tuba@ur-tut.UUCP (Jon Krueger)
Newsgroups: net.arch,net.micro.att
Subject: Re: AT&T MIPS claim [really task-switching]
Message-ID: <415@ur-tut.UUCP>
Date: Mon, 16-Jun-86 15:46:56 EDT
Article-I.D.: ur-tut.415
Posted: Mon Jun 16 15:46:56 1986
Date-Received: Wed, 18-Jun-86 03:26:06 EDT
References: <577@scirtp.UUCP> <124@bakerst.UUCP> <583@scirtp.UUCP>
<585@scirtp.UUCP> <206@njitcccc.UUCP> <4138@sun.uucp> <506@mips.UUCP>
Reply-To: tuba@ur-tut.UUCP (Jon Krueger)
Distribution: net
Organization: Univ. of Rochester Computing Center
Lines: 67
Xref: watmath net.arch:3469 net.micro.att:1297
In article <506@mips.UUCP> mash@mips.UUCP (John Mashey) writes:
> . . .
>3) Let's try some back-of-the-envelope numbers:
> a) At 60 cs/second (typical) and 700 usec/cs, the VAX would spend
> 60*700 = 42,000 usecs, or about 4.2% of the time doing conxtext
> switches.
> b) Supposing that that 10% of this time is actually in save/restore,
> about .4% of the machine might be spent in save/restore
> (SVPCTX/LDPCTX). Of course, they might be used for other things also.
>4) Now, let's try published data: Clark & Levy, "Measurement and Analysis of
> Instruction Use in the VAX 11/780", 9th Ann. Symp. on Comp. Arch,
> April 1982.
> a) LDPCTX and SVPCTX aren't on the top 25 in usage of CPU time,
> even in VMS Kernel mode. The top 25 instructions use 62% of the
> total kernel time, and the smallest shown is REMQUE with 1.31%.
> This was for multi-user workloads.
> b) MTPR (Move to Processor Register) used 5.27% of the kernel time,
> and 1.15% of the total CPU time for all processor modes. From this,
> I infer that the kernel was using 21% of the CPU (1.15/5.27).
> Hence, the most time-consuming of LDPCTX/SVPCTX could be consuming
> no more than 1.31% of the kernel, or .27% of the total CPU. Even
> both together could account for no more than .54% of the total CPU.
>5) All of this is consistent in bounding the problem: for time-sharing
>systems like VAXen, the special context save/restore instructions contribute
>at most half a percent to performance. . . .
Thanks for the numbers and calculations. I can't argue with your numbers,
but I arrive at different conclusions.
I agree that the VAX architecture, as implemented on the 780, including the
presence and performance of those instructions, limits overhead due to
context switching to about 5 percent of processor time. So the performance
increase attainable by decreasing this overhead is only 5 percent. The
numbers you present don't tells us how much of that 5 percent is spent
actually executing LDPCTX/SVPCTX. So we can only estimate the performance
aspects of increasing their speed. I accept your estimate of at most half a
percent processor time spent, so we can only save about half a percent.
What we can't say is how much context switching overhead would rise to if
the instructions didn't exist. For instance, if the functionality
implemented in the microcode of LDPCTX/SVPCTX were performed by a system
routine, overhead might be 90% of processor time at 60 switches per second.
In this case, we could say that the instructions contribute about 85% to
system performance. Similarly, if hardware on the 780 autosaved
and restored registers as needed by processor modes and subroutine
instructions, overhead might be 0% of processor time, but cycles
would take longer.
In other words, I think the numbers you present prove that only about half a
percent performance increase can be attained by tweaking the special
instructions. They don't prove that the special instructions contribute
only 10% to context switching or only half a percent to system performance
related to context switching. Suppose 50 percent of system time was spent
executing them. Would you conclude that they contribute 50 percent to
performance? I would conclude that they subtract 50 percent from
performance.
In other other words, you look at measurements of context switching on 780's
and since the special instructions represent so little processor time, you
conclude they don't contribute much to performance. I wonder how much more
processor time would be spent acheiving the same functionality in different
ways if the instructions didn't exist and didn't execute at their measured
speeds. I conclude that we don't know enough to assess the contribution of
the special instructions to a 780's ability to keep context switching
overhead down to about 5 percent. Therefore, we don't know how important
the special instructions are to timesharing, or how clever it is to put them
into your architecture.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: net.arch,net.micro.att
Subject: Re: AT&T MIPS claim
Message-ID: <6826@utzoo.UUCP>
Date: Tue, 17-Jun-86 18:00:30 EDT
Article-I.D.: utzoo.6826
Posted: Tue Jun 17 18:00:30 1986
Date-Received: Tue, 17-Jun-86 18:00:30 EDT
References: <577@scirtp.UUCP> <124@bakerst.UUCP> <583@scirtp.UUCP>
<585@scirtp.UUCP>, <206@njitcccc.UUCP>
Organization: U of Toronto Zoology
Lines: 26
> You know, a lot of this discussion revolves around the assumption
> that if you want the power of a vax 11/780, one would buy a vax
> 11/780. A friend of mine who works for DEC says that if you were
> solely interested in raw cpu power you would not buy a 780, you
> would buy the microvax II, which costs far less than the 780,
> but has 90% of its power, in cpu intensive applications...
Nobody in his right mind would buy a 780 nowadays. And the Microvax II
isn't that impressive either; 68020 boxes from Sun or Integrated Solutions
are priced similarly and have 3-4 times the cpu crunch.
> ... the 780 is
> an all purpose performance machine (for its day). It was designed
> to handle multitasking multiprocess environments well. It has
> a one instruction "switch task", which I believe the 68000 lacks...
The 780 is also notorious for the interesting property that many of its
complex instructions are actually *slower* than the equivalent combination
of simple 780 instructions. I'm not sure about "switch task", but it would
not surprise me if the 68000 does it faster. Let's not even mention the
comparison to a well-designed RISC; Mips's machine does a TLB refill faster
in software than the 780 does it in hardware.
--
Usenet(n): AT&T scheme to earn
revenue from otherwise-unused Henry Spencer @ U of Toronto Zoology
late-night phone capacity. {allegra,ihnp4,decvax,pyramid}!utzoo!henry
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!
decvax!decwrl!glacier!mips!mash
From: mash@mips.UUCP
Newsgroups: net.arch,net.micro.att
Subject: Task switching or LDPCTX/SVPCTX revisisted again
Message-ID: <520@mips.UUCP>
Date: Thu, 19-Jun-86 08:47:27 EDT
Article-I.D.: mips.520
Posted: Thu Jun 19 08:47:27 1986
Date-Received: Sat, 21-Jun-86 10:44:17 EDT
References: <577@scirtp.UUCP> <124@bakerst.UUCP> <583@scirtp.UUCP>
Reply-To: mash@mips.UUCP (John Mashey)
Distribution: net
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 168
Xref: watmath net.arch:3521 net.micro.att:1312
In article <415@ur-tut.UUCP> tuba@ur-tut.UUCP (Jon Krueger) writes:
>In article <506@mips.UUCP> mash@mips.UUCP (John Mashey) writes:
>> . . .
>>3) Let's try some back-of-the-envelope numbers: ....
>>4) Now, let's try published data: Clark & Levy, ....
>> a) LDPCTX and SVPCTX aren't on the top 25 in usage of CPU time,
>> even in VMS Kernel mode.....
>>5) All of this is consistent in bounding the problem: for time-sharing
>>systems like VAXen, the special context save/restore instructions contribute
>>at most half a percent to performance. . . .
>
>Thanks for the numbers and calculations. I can't argue with your numbers,
>but I arrive at different conclusions.
>
>I agree that the VAX architecture, as implemented on the 780, including the
>presence and performance of those instructions, limits overhead due to
context switching to about 5 percent of processor time. So the performance
>increase attainable by decreasing this overhead is only 5 percent. The
>numbers you present don't tells us how much of that 5 percent is spent
>actually executing LDPCTX/SVPCTX. So we can only estimate the performance
>aspects of increasing their speed. I accept your estimate of at most half a
>percent processor time spent, so we can only save about half a percent.
>
>What we can't say is how much context switching overhead would rise to if
>the instructions didn't exist. For instance, if the functionality
>implemented in the microcode of LDPCTX/SVPCTX were performed by a system
>routine, overhead might be 90% of processor time at 60 switches per second.
----------------------------^^----Unlikely, see below.-------
>In this case, we could say that the instructions contribute about 85% to
>system performance. Similarly, if hardware on the 780 autosaved
>and restored registers as needed by processor modes and subroutine
>instructions, overhead might be 0% of processor time, but cycles
>would take longer.
>
>In other words, I think the numbers you present prove that only about half a
>percent performance increase can be attained by tweaking the special
>instructions. They don't prove that the special instructions contribute
>only 10% to context switching or only half a percent to system performance
>related to context switching. Suppose 50 percent of system time was spent
>executing them. Would you conclude that they contribute 50 percent to
>performance? I would conclude that they subtract 50 percent from
>performance.
>
>In other other words, you look at measurements of context switching on 780's
>and since the special instructions represent so little processor time, you
>conclude they don't contribute much to performance. I wonder how much more
>processor time would be spent acheiving the same functionality in different
>ways if the instructions didn't exist and didn't execute at their measured
>speeds. I conclude that we don't know enough to assess the contribution of
>the special instructions to a 780's ability to keep context switching
>overhead down to about 5 percent. Therefore, we don't know how important
>the special instructions are to timesharing, or how clever it is to put them
>into your architecture.
----------------------------
1. Jon's premise is correct, in general: "Just because something isn't used
much doesn't mean that omitting it wouldn't drastically slow a system down".
2. However, I believe my original conclusion is also correct, i.e., that
the VAX LDPCTX/SVPCTX don't contribute a lot to performance.
3. The point of all the numbers was to show that the time actually spent doing
LDPCTX/SVPCTX is small, i.e. that one might well afford a less efficient
implementation without seeing much impact on system performance.
4. Unfortunately, there were a whole bunch of assumptions necessary to
get to the correct conclusion, and they were buried in the sentence in the
original posting [shortly before where Jon started quoting]:
"1) Register save/restores speed are almost entirely dominated by memory
system time anyway."
They were buried because I was treating the issue as a continuation of
familiar discussions, which I woefully neglected to describe.
Here are the hidden assumptions used to reach the conclusion:
a] I assumed people understand exactly what LDPCTX & SVPCTX do:
LDPCTX:
Invalidates the per-process half of the TLB
[sort of half-way between TBIS and TBIA]
Reloads general purpose registers from Process Control Block
Reloads mapping regs and a few others
Saves PSL & PC onto stack (so REI can use them soon)
SVPCTX:
Saves general regs into a PCB
Grabs PSL & PC from stack and saves them in PCB
Switches to interrupt stack
b] I assumed that people understood that it was clear that:
LDPCTX is essentially a TLB operation, followed by a load-multiple
SVPCTX is essentially a store-multiple
(in each case, with a few tweaks)
The timings for these things should be domininated by:
LDPCTX: cache misses doing the loads [likely if actually used
for context switch, not so likely if for system call/ clock
interrupt, etc]
SVPCTX: write-stall activity, i.e., where the CPU can write faster
than memory can take it.
c] The fundamental point is that these operations are mostly 32-bit word
data movers, with some carefully crafted tweaks to keep the machine in a
reasonable state. These are NOT like (for example) floating point instrs,
where to simulate them in the integer instruction set is always expensive.
d] Consider what it would take to simulate the effects of these things,
either with existing instructions, or with a slightly different partitioning
of function:
LDPCTX:
need to add a TLB Invalidate Per-Process instruction
Copy PSL & PC to stack
Use POPR, after tweaking the SP to point at (something like)
a PCB, to reload regs
OR
Use sequence of MOVQs to relaod the regs, 2 at a time
SVPCTX:
Save SP somewhere, set SP -> PCB (or something like it)
Use PUSHR to save regs, or MOVQs
Copy PSL & PC from stack to PCB and pop them
[as can be seen, what these things are mainly doing for you is to
be able to implicitly access the current PCB without needing a GP
register to point there, at an inconvenient place. Note that this
pair cannot be too much more expensive than a full function call/
return that saves most of the registers.]
e) Now: how much longer will the times for the above be? ANS: not much:
e1) A longer sequence of instructions may well take more
instruction-cache misses. This is especially true if there are no
load/store multiple instructions of any sort available. However,
the VAX has them already.
e2) A longer sequence of instructions may not be able to get at the
machine's parallelism (for things like auto-increments, for example).
e3) [MOST IMPORTANT]: It may be that SCPCTX/LDPCTX is the fastest
way to save/load a large block of registers. However, this is
generally unlikely, because it's probably a mistake, because it
essentially means that the subroutine call mechanism (or PUSHR/POPR)
are not as fast as possible, which is silly, because it means that
a frequently occurring operation is less well-tuned than an
infrequently-occurring one. In particular, think how odd it would be
to have loads/stores [of any reasonable size] that cannot run the
memory system full blast. If you're going to spend microcode effort
to tune memory-related operations, where would you put that effort
on a VAX? ANS: MOV* [esp MOVC3], CALLS/RET [or PUSHR/POPR].
f) Thus, the fundamental assumption is that the bulk of the time in these
operations is spent pushing memory, with a little bit of control around them.
If you have a fast, general way to save/restore registers, you'll want it
elsewhere even more, so it might as well be a separate instruction that can be
used elsewhere. What this says is that e3) is unlikely, e2) is possible,
but (typically, not a big deal), and e1) is not that bad a problem, unless
you have no multiple loads/stores of any sort. Even then, it's not a big
deal, if you consider that you'll almost certainly have substantial cache
misses inside the newly-started user process.
Thus, putting all this together, we have the two pieces:
a] LDPCTX/SVPCTX don't account for that much time.
b] They don't do very much that couldn't be simulated by existing
instructions, or minor variants thereof, and the fundamental nature
of the replacements is such that the times should be fairly comparable,
because, if they're not, then the machine has been designed to NOT
allow good memory performance from normally-usable instructions.
c] Thus, it's not clear that wrapping up the entire functionality of
these things, in VAX-time-sharing use, really contributes much to
performance, versus partitioning them differently.
I apologize for not explaining all of this more in the first place, because,
in retrospect, it's not particularly obvious. Of course, one can make all
sorts of assumptions that invalidate the conclusion, such has expecting
that process-switch instructions have to do much more work, or that
context-switch rates are high, or that conext-switch latencies must be
guaranteed low, etc, etc. However, I still think the conclusion, as
originally stated, actually holds in this case.
--
-john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD: 408-720-1700, x253
USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086