Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!
tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!usc!henry.jpl.nasa.gov!
elroy.jpl.nasa.gov!zardoz!dhw68k!stein
From: st...@dhw68k.cts.com (Rick 'Transputer' Stein)
Newsgroups: comp.arch
Subject: Evans and Sutherland quits the superbusiness
Message-ID: <27611@dhw68k.cts.com>
Date: 18 Nov 89 02:22:11 GMT
Reply-To: st...@dhw68k.cts.com (Rick 'Transputer' Stein)
Distribution: usa
Organization: Wolfskill & Dowling residence; Anaheim, CA (USA)
Lines: 10
The New York Times reported today that E&S is bowing out of the
superconfuser business. The aritcle, by John Markoff, states that
their system, believed to be a VLIW flavor, is having both hardware
and software production problems, and that the performance is not
quite as competitive as they had once thought. I guess those
Livermore Loops are worth something!
--
Richard M. Stein (aka, Rick 'Transputer' Stein)
Sole proprietor of Rick's Software Toxic Waste Dump and Kitty Litter Co.
"You build 'em, we bury 'em." uucp: ...{spsd, zardoz, felix}!dhw68k!stein
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!
samsung!rex!ames!sun-barr!lll-winken!vette!brooks
From: bro...@vette.llnl.gov (Eugene Brooks)
Newsgroups: comp.arch
Subject: Re: Evans and Sutherland quits the superbusiness
Message-ID: <38966@lll-winken.LLNL.GOV>
Date: 19 Nov 89 20:29:26 GMT
References: <27611@dhw68k.cts.com>
Sender: use...@lll-winken.LLNL.GOV
Reply-To: bro...@maddog.llnl.gov (Eugene Brooks)
Distribution: usa
Organization: Lawrence Livermore National Laboratory
Lines: 18
In article <27...@dhw68k.cts.com> st...@dhw68k.cts.com
(Rick 'Transputer' Stein) writes:
>The New York Times reported today that E&S is bowing out of the
>superconfuser business.
E&S did not see the Killer Micros coming. Any vendor who
invested time and money in a "custom" CPU implementation
over the past several years is getting eaten alive by the sudden
onslaught of the Killer Micros. You can't sell an expensive
slow computer in a competitive market.
Its going to be a terrible year for vendors of custom architectures,
new vendors will be completely flushed and old vendors will barely
survive on the hysterisis of their existing customer base.
Even the CEO of Cray Research mentioned the RISC microprocessors
in the recent Supercomputing '89 conference in his keynote address.
He referred to the performance increases of microprocessors as
"astounding."
bro...@maddog.llnl.gov, bro...@maddog.uucp
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!samsung!
gem.mps.ohio-state.edu!uwm.edu!lll-winken!maddog!brooks
From: bro...@maddog.llnl.gov (Eugene Brooks)
Newsgroups: comp.arch
Subject: Re: Evans and Sutherland quits the superbusiness
Keywords: Killer Micros
Message-ID: <38980@lll-winken.LLNL.GOV>
Date: 20 Nov 89 00:32:01 GMT
References: <27611@dhw68k.cts.com> <38966@lll-winken.LLNL.GOV>
<1989Nov19.155445.27287@hellgate.utah.edu>
Sender: use...@lll-winken.LLNL.GOV
Reply-To: bro...@maddog.llnl.gov (Eugene Brooks)
Distribution: usa
Organization: Lawrence Livermore National Laboratory
Lines: 49
If your basic processor is not as fast as a current killer micro,
someone with ONE Killer Micro will blow your pants off. This was
the case in an extreme for the ES-1 and is why Evans and Sutherland
saw no hope at all for the future and closed shop. One can quote
the offical words printed in the press, but the bottom line is that
you can't make money selling an expensive slow computer. Had there
been any money at the end of the tunnel, they would have hung in
there and solved their hardware and software problems. The Killer
Micros were moving in the on the territory and will have completely
dominated it before they could get their problems fixed.
It took the use of on the order of 10 processors (processing
elements) or more on the ES-1 to match traditional supercomputer
performance. As noted in an earlier post, the ES-1 was a nice
micro architecture, but without any of the Killer part in either
performance or cost. Judging from the Livermore Loops figures for
the latest Killer Micro from hell, the MIPS R6000, it matches
traditional supercomputer performance with ONE processor, and not
just for "scalar only" codes. The other micro vendors will soon follow
with even more terrible critters, its a competitive world after all.
Killer Micros are certainly custom architectures which cost a lot
of money to develop. The difference for them is that their development
costs are amortized over large markets and the parts end up sold at
"cookie cutter" costs. Compare this to the costs of developing the
Cray-3, mentioned by Rollwagen at SC'89 to be more than a hundred
million dollars. This development cost has to be amortized over
the sale base, and for a market which might only be few tens
of machines (after SSI, Cray Computers, Cray Research, Tera,
Convex, and the three Japanese companies divide up the total market
which the Killer Micros leave for them) puts quite a lower bound
on the machine price before you even get around to charging the cost
of the hardware. This is in sharp contrast to the situation for
the Cray-1, the sale of the first copy of which more than paid the
entire development cost for the machine. Gone are the days of
high profit margins for supercomputers.
Perhaps I am wrong and the R6000 powered box should be sold for
more than a million and MIPS is just dumping it on the market to
destroy the supercomputer vendors. I don't see any "anti dumping"
legislation in the works, however. One thing is clear, if
traditional supercomputers don't find another order of magnitude
in single CPU performance real soon, at fixed cost, they will
not survive The Attack of the Killer Micros. For scalar codes
supercomputers need even more leverage, two orders of magnitude.
I don't think it is going to happen.
bro...@maddog.llnl.gov, bro...@maddog.uucp
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!samsung!
gem.mps.ohio-state.edu!apple!mips!mash
From: m...@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: Evans and Sutherland quits the superbusiness
Keywords: Killer Micros
Message-ID: <31735@winchester.mips.COM>
Date: 20 Nov 89 01:11:41 GMT
References: <27611@dhw68k.cts.com> <38966@lll-winken.LLNL.GOV>
<1989Nov19.155445.27287@hellgate.utah.edu> <38980@lll-winken.LLNL.GOV>
Reply-To: m...@mips.COM (John Mashey)
Distribution: usa
Organization: MIPS Computer Systems, Inc.
Lines: 13
In article <38...@lll-winken.LLNL.GOV> bro...@maddog.llnl.gov
(Eugene Brooks) writes:
....
>Perhaps I am wrong and the R6000 powered box should be sold for
>more than a million and MIPS is just dumping it on the market to
>destroy the supercomputer vendors.....
Just so they're no confusion:
it shouldn't be, and nobody's dumping...
--
-john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR m...@mips.com
DDD: 408-991-0253 or 408-720-1700, x253
USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!mfci!rodman
From: rod...@mfci.UUCP (Paul Rodman)
Newsgroups: comp.arch
Subject: Re: Evans and Sutherland quits the superbusiness
Keywords: Killer Micros
Message-ID: <1128@m3.mfci.UUCP>
Date: 20 Nov 89 15:13:52 GMT
References: <27611@dhw68k.cts.com> <38966@lll-winken.LLNL.GOV>
<1989Nov19.155445.27287@hellgate.utah.edu> <38980@lll-winken.LLNL.GOV>
Sender: rod...@mfci.UUCP
Reply-To: rod...@mfci.UUCP (Paul Rodman)
Distribution: usa
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 60
In article <38...@lll-winken.LLNL.GOV> bro...@maddog.llnl.gov (Eugene
Brooks) writes: ....[ deleted soapboxing about Killer Micros]....
Ok, ok, so I'm wasting my time, but I just can't let Mr. Brooks
continue his deluge of propaganda without throwing in my opinions....
Let's ignore the fact that the Killer Micros usually don't have a
decent memory system or I/O system. [Not to mention that their
compilers and O/S are often not very robust...:-)]
There IS a grain of truth in what Mr Brooks says, in that I do belive
that there has been, and will continue to be both a factory cost and
performance compression from the lowest to the highest performance
computers.
Today's dense CMOS and ECL ASICS appear from PCs to workstations to
supercomputers, as do pretty dense packaging techniques. So it IS
getting harder to figure out how to apply current technology to build
a supercomputer, i.e. how do I use more hardware to build a faster
uniprocessor machine?
<Commercial ON.>
One technology exists that CAN use more hardware for more performance:
the VLIW machine. Furthermore, such a machine uses replicated
functional units, lots of SRAM, and minimal control, all of which
contribute to ease of the design cycle. The ease of use of the VLIW
system [compile-and-go] is important for the Non-Brookses of the
world, belive me.
I have seen the state of typical software efforts in the good 'ol USA
and I feel that it will be a long time before efforts such as that of
Mr Brooks are the norm. [100's, 1000's of micros used for
time-to-solution]. God knows enough folks are working on, and have
worked on, the problem! As such multiprocessing techiniques improve,
they WILL be used commercially, but mostly with more modest numbers of
VLIW "supercomputers".
I DO agree with Mr. Brooks that single cpus built with 100's of
different ASIC designs, dozens of boards, and mediocre performance, are
dead meat in the not-so-long run [e.g. Cyber 2000]. But Mr. Brooks
errs in thinking that single-chip cpus are the be-all, end-all of cpu
design.
<Commercial Off.>
Speaking as a engineer that does NOT work on Killer Micros, I just
don't seem to feel as depressed about the future of high-$$$ cpu
design as he thinks I should.... :-) Mr Brooks' attitude reflects his
rigid thinking, and his underestimation of change in areas other than
the one he has focused on. His refrain reminds me of all the wags 10
years ago that claimed "The Attack of the Killer CMOS" would remove
LSI ECL from use in computer design. Instead almost all high-end cpus
sold today are ECL.
Paul K. Rodman / KA1ZA / rod...@multiflow.com
Multiflow Computer, Inc. Tel. 203 488 6090 x 236
Branford, Ct. 06405
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ico!vail!rcd
From: r...@ico.isc.com (Dick Dunn)
Newsgroups: comp.arch
Subject: Re: Evans and Sutherland quits the superbusiness
Summary: yeah, let's ignore it
Message-ID: <1989Nov22.175128.24910@ico.isc.com>
Date: 22 Nov 89 17:51:28 GMT
References: <1128@m3.mfci.UUCP>
Distribution: usa
Organization: Interactive Systems Corporation
Lines: 19
In article <1...@m3.mfci.UUCP>, rod...@mfci.UUCP (Paul Rodman) writes:
>...Let's ignore the fact that the Killer Micros usually don't have a
> decent memory system or I/O system...
No, let's ignore it because it's not a fact but an incredibly biased
(and not particularly useful) opinion.
(Actually, what I've seen suggests that the memory systems are usually
pretty well balanced, and that the I/O systems are out of balance to about
the same extent they are on most machines...I/O has been in catch-up mode
for years.)
>...[Not to mention that their
> compilers and O/S are often not very robust...:-)]
Yeah, let's not mention that, since it isn't true.
--
Dick Dunn r...@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870
...`Just say no' to mindless dogma.
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!
cs.utexas.edu!samsung!uunet!sco!seanf
From: se...@sco.COM (Sean Fagan)
Newsgroups: comp.arch
Subject: Re: Evans and Sutherland quits the superbusiness
Message-ID: <3893@scolex.sco.COM>
Date: 23 Nov 89 21:25:24 GMT
References: <1128@m3.mfci.UUCP> <1989Nov22.175128.24910@ico.isc.com>
Reply-To: se...@sco.COM (Sean Fagan)
Distribution: usa
Organization: The Santa Cruz Operation, Inc.
Lines: 44
In article <1989Nov22.175128.24...@ico.isc.com> r...@ico.isc.com (Dick Dunn)
writes:
>In article <1...@m3.mfci.UUCP>, rod...@mfci.UUCP (Paul Rodman) writes:
>>...Let's ignore the fact that the Killer Micros usually don't have a
>> decent memory system or I/O system...
>
>No, let's ignore it because it's not a fact but an incredibly biased
>(and not particularly useful) opinion.
What?! Uhm, I hate to tell you this, but the reason mini's provide much
better throughput than micros was because of the I/O subsystem. A '286 is
faster than a VAX (785, let's say), but, go multi-user, and there is no
comparison: the VAX will get *much* better throughput (meaning: it may
take three times as long to do your sieve of Erasthoneses, but swapping
processes in and out, and doing any disk I/O, is going to go more than three
times faster). This is because the '286 (a killer-micro, compared to a VAX
8-)) doesn't have the memory or I/O subsystems that the VAX does. Now,
compare just about *any* system on the market today with, say, a CDC Cyber
running NOS (or, deity forgive me, even NOS/VE). (Bet you were all waiting
for me to mention those, weren't you? 8-).) As has been pointed out before,
lots of people don't *need* 250 MFLOPS / MIPS on their desktop; they just
need to shuffle data back and forth (that's why there's a TPS [Transactions
Per Second] measurement; any commentary on that, John? Michael?). Without
a decent I/O subsystem, you won't be able to do this. And the memory in
most "killer micros" is defficient because I can't do *real* DMA (it tends
to steal cycles from the CPU). (N.B.: some K.M.'s *do* have *real* DMA.
I'm waiting for them to come out with *real* I/O subsystems [using, say, a
68000 as a PP]. Then they will scream, even compared to a Cyber.)
>>...[Not to mention that their
>> compilers and O/S are often not very robust...:-)]
>Yeah, let's not mention that, since it isn't true.
Some of the compilers available today are pretty amazing, especially
compared to what was available just a decade ago. The OS's running on most
K.M.'s, however, tend to be unix varients (or, deity help us all, DOS).
This is not a terribly robust OS, nor a terribly quick one (asynchronous I/O
would be really nice; there are some other things that could be useful).
So, yeah, it is true.
--
Sean Eric Fagan | "Time has little to do with infinity and jelly donuts."
se...@sco.COM | -- Thomas Magnum (Tom Selleck), _Magnum, P.I._
(408) 458-1422 | Any opinions expressed are my own, not my employers'.
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!snorkelwacker!
spdcc!merk!xylogics!world!bzs
From: b...@world.std.com (Barry Shein)
Newsgroups: comp.arch
Subject: Re: I/O, I/O, and off to work I go...
Message-ID: <1989Nov24.033516.16214@world.std.com>
Date: 24 Nov 89 03:35:16 GMT
References: <1128@m3.mfci.UUCP> <1989Nov22.175128.24910@ico.isc.com>
<3893@scolex.sco.COM>
Distribution: usa
Organization: The World @ Software Tool & Die
Lines: 52
In-Reply-To: seanf@sco.COM's message of 23 Nov 89 21:25:24 GMT
I've heard these I/O arguments for years. I think the first
centralized computing czar who ever saw a micro harumpphed "Oh yeah,
but how is it on I/O?"
It's true that mainframes, by definition, have awesome I/O relative to
anything else.
What I wonder is, how long before the micros just tear away this
barrier? I agree it'll be a long time before you have the I/O
*systems* that larger machines have, if ever (these days it's common
for mainframes to be ordered with 1TB disk farms, and backup
facilities, that would probably crowd your office.)
But pure I/O performance, measured blindly, on micros with a few
hundred to 1GB or so of disk?
I stress "measured blindly" because I'd consider all sorts of disk
buffering/caching to be fair play. Particularly if they're biased
towards the single-user system so the mainframe/mini couldn't just
implement the methods and jump back ahead. I'm sure such methods
exist, memory scheduling in large time sharers is much harder than in
single or very few user systems.
For example, we'll probably start to see 128MB main memory
workstations in the next couple of years as common. With effective
buffering and inevitably faster controllers and multi-ported memory
designs (?) how long do you think it will be before the difference
between micros/minis/mainframes starts to seem insignificant?
A better question: How fast is fast? How will we know? What's the
current situation? I don't think there are any widely accepted
benchmarks (Nelson? Aims?) I guess when it becomes the marketing rage
the benchmarks will show up.
I remember when they rolled in a 30MIPS 3090 and folks were sure the
mainframe crowd had gotten years ahead of the under-$100K bunch on
CPU. They were right, about two or three years ahead...and they're not
really keeping their heads above water on that front anymore (what's
single CPU performance on a 3090J?)
Or is I/O performance in micros like the weather, everyone talks about
it but no one does anything about it? NeXT made a lot of noise about
"mainframe I/O performance", but I had one of those systems for a
while and I didn't see anything impressive in their disk performance.
Just another windmill waiting to be toppled? Then what?
--
-Barry Shein
Software Tool & Die, Purveyors to the Trade | b...@world.std.com
1330 Beacon St, Brookline, MA 02146, (617) 739-0202 | {xylogics,uunet}world!bzs
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!
usc!apple!mips!mash
From: m...@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: Evans and Sutherland quits the superbusiness
Message-ID: <32146@winchester.mips.COM>
Date: 26 Nov 89 03:28:24 GMT
References: <1128@m3.mfci.UUCP> <1989Nov22.175128.24910@ico.isc.com>
<3893@scolex.sco.COM> <39361@lll-winken.LLNL.GOV> <3898@scolex.sco.COM>
Reply-To: m...@mips.COM (0000-Admin(0000))
Distribution: usa
Organization: MIPS Computer Systems, Inc.
Lines: 32
In article <3...@scolex.sco.COM> se...@sco.COM (Sean Fagan) writes:
>In article <39...@lll-winken.LLNL.GOV> bro...@maddog.llnl.gov (Eugene Brooks)
writes:
>>In article <3...@scolex.sco.COM> se...@sco.COM (Sean Fagan) writes:
>>>most "killer micros" is defficient because I can't do *real* DMA (it tends
>>>to steal cycles from the CPU). (N.B.: some K.M.'s *do* have *real* DMA.
>>>I'm waiting for them to come out with *real* I/O subsystems [using, say, a
>>>68000 as a PP]. Then they will scream, even compared to a Cyber.)
Just to correct a potential mis-impression:
a) Since 1983 (or earlier, in a few cases, I think), anybody seriously
building multi-user systems / servers from microprocessors has tended to
build at least the high end of a product range with micros [68K, 186s,
Z8000s, V-??, etc] as I/O processors. Some workstations [Sony News,
for example] have 2 68Ks, one as an I/O processor.
b) Although one may choose to use a "Killer Micro" in a workstation/PC/cheap
server architecture, where there may be only one path to a memory bus with
SIMMs, or similar design:
1) It usually has DMA.
2) it usually has a cache, and so I/O has some impact, but is hardly
what people used to call cycle-stealing (where every I/O stopped the CPU
almost cold).
c) Any "Killer Micro" aimed at larger server/multi-user designs (as opposed to
least-cost designs):
has DMA
usually has CPUs in at least some of the I/O boards, where appropriate
sometimes has multiple paths to memory, i.e., a VME I/O bus and a
private memory bus
d) Many of the current high-performance I/O boards have 68020s, already,
as in some of Interphase's products.
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!cbmvax!daveh
From: da...@cbmvax.UUCP (Dave Haynie)
Newsgroups: comp.arch
Subject: Re: I/O, I/O, and off to work I go...
Message-ID: <8724@cbmvax.UUCP>
Date: 27 Nov 89 22:03:49 GMT
References: <1989Nov24.033516.16214@world.std.com>
Distribution: usa
Organization: Commodore Technology, West Chester, PA
Lines: 36
in article <1989Nov24.033516.16...@world.std.com>, b...@world.std.com (Barry Shein)
says:
> In-Reply-To: se...@sco.COM's message of 23 Nov 89 21:25:24 GMT
> A better question: How fast is fast? How will we know?
It's fast enough when you don't mind waiting anymore. At least for an
interactive computer like a PC or a Workstation. The reason personal
computers have been gaining ground there past 5 years or so is that they're
getting closer to what a larger number of people find acceptable for a
larger number of tasks. Most folks don't mind a short wait for a
spreadsheet recalculation, a DTP display, or a program load. After all,
they just told the computer to do something, and expect it to take a
certain amount of time to achieve that task.
Of course, as computers get better, expectations change. You might be
happy with 250kb/sec from your hard disk until you try a machine that gives
you 1 mb/sec. Certainly the limit is the point where you don't notice any
time between issuing the command and viewing the result. In fact, that's
the problem I had with the NeXT machine -- I'm used to seeing a menu the
instant I press the menu button. On a NeXT, it takes a little while. So I
precieve the NeXT as being slow, even though it's at least 5% faster than
my office machine in raw CPU power, and likely faster in I/O if it had a
decent hard disk on it.
Some jobs will practically always scream for more power, but I think in most
cases the fact that you're interacting with humans is going to set the upper
limit on the need for speed.
> -Barry Shein
>
> Software Tool & Die, Purveyors to the Trade | b...@world.std.com
> 1330 Beacon St, Brookline, MA 02146, (617) 739-0202 | {xylogics,uunet}world!bzs
--
Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests"
{uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy
Too much of everything is just enough
Path: utzoo!utgpu!jarvis.csri.toronto.edu!torsqnt!david
From: da...@torsqnt.UUCP (David Haynes)
Newsgroups: comp.arch
Subject: Re: X-terms v. PCs v. Workstations
Message-ID: <549@torsqnt.UUCP>
Date: 29 Nov 89 13:25:15 GMT
References: <1128@m3.mfci.UUCP> <1989Nov22.175128.24910@ico.isc.com>
<3893@scolex.sco.COM> <39361@lll-winken.LLNL.GOV> <17305@netnews.upenn.edu>
<1989Nov25.000120.18261@world.std.com>
<1989Nov27.144016.23181@jarvis.csri.toronto.edu> <1989Nov27.213238.24130@cs.rochest
Organization: Sequent Computers (Canada) Ltd., Toronto, CANADA
Lines: 31
I guess my take on this is that both centralized and decentralized computing
have their places. For example, let's look at X terminals vs. X workstations.
I don't think it will come as much of a surprise if I state that X binaries
are relatively large. For a system without shared libraries, these programs
can be anywhere from 500 Kb to 1 Mb or more. Even with shared libraries these
puppies aren't tiny. An average user may have 3 to 10 windows/icons active
on their terminal at any one time. This argues that the computing resource
driving the X terminal needs to be large and powerful. This tends to say
that a centralized system will work more effectively.
However, a little time ago a program called 'dclock' was posted to the
X sources newsgroup and nearly everyone compiled and ran this program.
It had a neat digital display that slowly scrolled the numbers whenever
the hours or minutes changed. Now, whenever the hour changed the centralized
system supporting the users just *crawled* along. It turns out that the
network traffic generated by the smooth scrolling of the numbers was
horrific and that the network was getting saturated. This tends to argue
that some applications are best left on a dedicated workstation.
Naturally, intelligent workstations with a large centralized server would
be ideal, but other considerations (cost, data security, backup, software
maintenance, ...) also come into play. This leads nicely into the observations
that Rayan was making in his articles.
-david-
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
David Haynes Sequent Computer Systems (Canada) Ltd.
"...and this is true, which is unusual for marketing." -- RG May 1989
...!{utgpu, yunexus, utai}!torsqnt!david -or- da...@torsqnt.UUCP
Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!
brutus.cs.uiuc.edu!apple!mips!mash
From: m...@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: X-terms v. PCs v. Workstations
Message-ID: <32382@winchester.mips.COM>
Date: 29 Nov 89 18:33:17 GMT
References: <1128@m3.mfci.UUCP> <1989Nov22.175128.24910@ico.isc.com>
<3893@scolex.sco.COM> <39361@lll-winken.LLNL.GOV> <17305@netnews.upenn.edu>
<1989Nov25.000120.18261@world.std.com>
<1989Nov27.144016.23181@jarvis.csri.toronto.edu> <1989Nov27.213238.24130@cs.rochest
Reply-To: m...@mips.COM (John Mashey)
Organization: MIPS Computer Systems, Inc.
Lines: 68
In article <5...@torsqnt.UUCP> da...@torsqnt.UUCP (David Haynes) writes:
>However, a little time ago a program called 'dclock' was posted to the
>X sources newsgroup and nearly everyone compiled and ran this program.
>It had a neat digital display that slowly scrolled the numbers whenever
>the hours or minutes changed. Now, whenever the hour changed the centralized
>system supporting the users just *crawled* along. It turns out that the
>network traffic generated by the smooth scrolling of the numbers was
>horrific and that the network was getting saturated. This tends to argue
>that some applications are best left on a dedicated workstation.
>
>Naturally, intelligent workstations with a large centralized server would
>be ideal, but other considerations (cost, data security, backup, software
>maintenance, ...) also come into play. This leads nicely into the observations
>that Rayan was making in his articles.
Well, actually, I think there is a much more cost-effective technology for
this: it's far more distributed than any other choice; it has zero impact
on the network or central site; it is reliable; some releases include small
calculator functions and useful alarms; fonts and such are trivially chosen
by the user; it has portability than an X-terminal.
It's called a wristwatch.....
-----
More seriosuly, this does illustate that sometimes, when one trades
a centralized environment [minicomputer plus ASCII terminals] for a more
distributed one [workstations or PCs], you're kidding yourself if you
think the network isn't a central resource, and that it is HARDER to
manage than a simpler big machine. [This is not an argument for
central machines, just an observation that one must have a clear view of
reality.] If work can be done on an isolated machine, that's fine,
but people in organizations want to share data, and now at least part
of the system is a shared resource that needs sensible management, not
anarchy. There's nothing that brings this home like having an Ethernet
board go crazy and start trashing a net, and have to shut everything
down, one at a time, to find it, belying the "if my system goes down,
it doesn't bother anybody" model.
How about getting this off the sociology track [because most of it came
down to "I know good compcenters" vs "I don't], and consider some of
the interesting system architectural issues, like:
1) How much load do X-window terminals put on a a host?
2) How much load do diskless nodes put on a host?
3) If the people are doing the same kind of work, does the host do more
or less disk I/O in cases 1) or 2)? How does the Ethernet traffic differ?
4) Experiences with X-window terminals: how many can be served, doing what
kind of work, from what kind of host?
5) How do you characterize the kinds of work that people do in any of
these environments?
I'd be interested in data on any of these, as I think would many.
(MIPS is neutral, of course, since we actively sell multi-user systems
with ASCII terminals, servers, workstations, and X-window terminals,
we probably have less axes to grind than many people;
people here use a mixture of: X-window terminals, ASCII terminals,
MIPS workstations, MACS, DECstations, Suns, Apollos, and PCs as makes
sense them, NFSed with 400+ VUPS worth of servers. Distributed systems are
wonderful:thank goodness the people who centrally wadminister this are great..)
--
-john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR m...@mips.com
DDD: 408-991-0253 or 408-720-1700, x253
USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086