🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #2264

Re: 88000 vs 3081. (long response)

#2264
From: Gregory G. Woodbury
Date: Sat, 16 Sep 1989 04:40
140 lines
8236 bytes
In article <22130@cup.portal.com> cliffhanger@cup.portal.com (Cliff C Heyer) writes:
>Re: Gregory/88000 vs 3081.
>
>In article <mumble@wolves> ggw@wolves.uucp (Gregory G. Woodbury) writes:
>
>>So what is a "workstation"?   I have been unable to
>>make any real distinction between a "workstation" and a "high-performance PC".
>>The distinction (if there is one) is purely marketing hype.

	Please allow me to correct this:  "I have been unable to find any
real distinction between SOME (so called) workstations and MOST (so called)
high-performance PC's."

	The point of my article was to second the need to scream at the
manufacturers in order to get a reasonably priced but fast buss.  Its too
bad that the EISA consortium seems to have buckled under and died.

>Ask yourself why a 1974 DECsystem-10 could support 40 users with
>only 1 MIPS of processor power, and today we have PCs that have 8 MIPS
	(or a 1979 PDP-11/60! with even less MIPS)
>but could NEVER handle 40 users with UNIX. The DECsystem-10 had a 
>20MB/s bus I/O BW, and had 2MB/s I/O to each of several MASSBUS 
>disk drives.
:
:
>A VAXstation 3500 CPU w/box costs about $11K, and then you can
>hook up all the same SCSI stuff as the IBM PC. The cost is the
>same as a souped up 386, except the VAX CPU board goes for
>$10K instead of $3K. So you pay a *bit* more for that 1.3MB/sec.
>In fact, with the faster I/O you may get more work done with
>the 4 MIPS VAX than the Clipper, because the Clipper has memory wait
>states that slow it down to maybe 3 MIPS.

	Actually, these co-processor implementations only  slow down for
the i/o - all universially (seem) to have an amount of their own dedicated
memory that is NOT accessed via the AT-style buss.  The Clipper board have
16MB of 1 wait dynamic RAM, which combined with the dual cache controllers
and large chunk prefetches, make the things scream in terms of computations,
but the I/O, being bottlenecked through the AT-buss and the host CPU, still
s**ks.  The 88K co-processors each have 20MB of similar DRAM.  In fact, it
is that we NEED the most memory available that boosts the costs of these
machines up into the price ranges mentioned.  With the recent stabilization
of the memory market, the newest machines we bought are actually a little
less expensive than machines bought 2 years or so ago.

>Perhaps you could try this file copy on your machine and see
>what you get?
	no need to benchmark, the disk i/o is directly limited by the
hosting AT-class machine.  What it can do in DOS, is the most that the
co-processor can ever get.  It may be a horrible way to handle the i/o,
but it does make the machine reasonably easy to design and get to market.
And that is what I am objecting to! 
	Getting the 88K as a co-processor and placing it in a "high-
performance" PC host (e.g. 33MHz '386 with 11MHz buss) costs significantly
less than getting the 88K workstation from DG (for example).  We knew that
we could effectively use the 88K, but the budgets and things are such that
we can finagle a less expensive co-processor based machine several times,
whereas we cannot get the money together (all at once) to get the more
expensive workstation.

>>We are/have been replacing our dependency on mainframe computing
>>by acquiring a network of dedicated, "high performance" (and relatively)
>>low cost "PC's".  Some of these things are "workstations", but they all
>>use the AT style PC buss, and take too bloody long to do the disk i/o.
>
>Yup. And that's the way companies want it (& need to have it) If they
>all started to sell PCs today with 3MB/s to each disk and memory with
>those *non existent* PC profit margins, no one would buy their $1M 
>mainframes in which case they would go broke.
	(hmm, there are enough people in the business that there
	must be some kind of profit to make.  Any capitalist
	knows that there has to be some kind of profit there to
	attract all the "fish". ;-)
>
>If I remember, the 3081K (is it a 3081KX?) can give about 9 MIPS *per
>job*, first shipped in early '82, and had an internal BW of about 70MB/s.
>Your Clipper has more MIPS but no BW like 70MB/s. But the 70MB/s is
>divided up to about 3MB/s per disk channel and user. Even this is vastly
>faster than anything on the AT bus.
	(I stipulate the advantages of "mainframe" io structure and
	channel architecture ;-)
>
>>If I could have this processor (88000) in a machine with a decently
>>fast bus AND at a cost nearly the same, then it would be perfect.
>>...The VME bus based box would have
>>cost us THREE times the cost of the co-processor configuration!
>
>Fast components simply cost more, and it takes more time to engineer
>& test fast boards. Its the laws of physics.

	But once they have been designed and tested, then they should
cost somewhat less to produce and price should ramp down after the
bus has been around for a while.  The real price-killer of the VME
system we were trying to configure was the ethernet controller! 
NatSemi only supported one or two possible cheapernet talkers and the
cost of them was way out of sight.  Even being willing to do some of the
integration ourselves (by getting source and kernel hacking!) could not
bring the cost of the system down to the level that we were willing
to really consider.
 
>But what *you* can do is at least make sure you are getting state
>of the art for your buck. This means learning facts like the Amiga's
>ability to do 900KB/s DMA disk I/O, and not permitting a 33MHz 386
>to be sold with 200KB/s without writing nasty letters to the editor 
>of Infoworld, PC Week, etc. If you demand quality by making public the
>facts, the manufacturers will be forced to at least do the best they
>can. There are allot of ripoffs out there now because people have not
>educated themselves sufficiently to know what not to buy. I wish 
>Infoworld and PC Magazine would include disk-to-disk copy benchmarks
>in all their tests. (but then I have not written to them either!)
>
>There is allegedly some kick-ass hardware out there in 386 AT land
>via SCSI/ESDI controllers ON BOARD bypassing the AT BUS. Mylex?
>ALR? I'm trying to find out before I buy.  ONE thing is for sure - you
>can bet it won't come from IBM or DEC!  They are too busy saving the BW 
>for their *big iron*.

	Yes, they (IBM and DEC - and all the rest, including DG) will
save the bandwidth and fast i/o for the *big iron* machines AND the
high-end "workstations".  This is just what the main problem is!  The
marketoids and management are so concerned in keeping the distinction
between certain types of machine, and they manipulate the prices in order
to do so, that they miss the boat.

	Actually, as we research the "next" machine we are going to get,
some "workstations" are actually getting a real look.  We are almost at the
point of deciding that we have enough compute power for the moment, and
we actually need a less number-cruncher of a machine in favor of a machine
that can do efficient DMA i/o and network management and maybe acting
as a file server.

	Sorry that this is so long, but this is of extreme interest
to me and some of my colleagues.
-- 
Gregory G. Woodbury
Sysop/owner Wolves Den UNIX BBS, Durham NC
UUCP: ...dukcds!wolves!ggw   ...dukeac!wolves!ggw           [use the maps!]
Domain: ggw@cds.duke.edu  ggw@ac.duke.edu  ggw%wolves@ac.duke.edu
Phone: +1 919 493 1998 (Home)  +1 919 684 6126 (Work)
[The line eater is a boojum snark! ]           <standard disclaimers apply>
Technical Details
Message-ID: <1989Sep16.044013.429@wolves.uucp>
Path: arc1-ca.pugleaf.net!utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!ukma!gatech!mcnc!ecsvax.uncecs.edu!dukeac!wolves!ggw
References: <21962@cup.portal.com> <1989Sep12.031453.22947@wolves.uucp> <22130@cup.portal.com>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!ukma!gatech!mcnc!ecsvax.uncecs.edu!dukeac!wolves!ggw
From: ggw@wolves.uucp (Gregory G. Woodbury)
Newsgroups: comp.arch
Subject: Re: 88000 vs 3081. (long response)
Summary: need for i/o bandwidth
Message-ID: <1989Sep16.044013.429@wolves.uucp>
Date: 16 Sep 89 04:40:13 GMT
References: <21962@cup.portal.com> <1989Sep12.031453.22947@wolves.uucp> <22130@cup.portal.com>
Sender: Uecsgate@uncecs.edu (Unix-to-Unix Copy)
Reply-To: ggw@wolves.UUCP (Gregory G. Woodbury)
Followup-To: comp.arch
Organization: Wolves Den UNIX BBS
Lines: 140