Newsgroups: comp.arch
Path: sparky!uunet!think.com!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!adingus
From: adi...@magnus.acs.ohio-state.edu (Aaron T Dingus)
Subject: The Death of the Mainframe...
Message-ID: <1992May29.065947.11906@magnus.acs.ohio-state.edu>
Sender: ne...@magnus.acs.ohio-state.edu
Nntp-Posting-Host: bottom.magnus.acs.ohio-state.edu
Organization: The Ohio State University
Date: Fri, 29 May 1992 06:59:47 GMT
Lines: 10
Alright, are mainframes doomed due to ultra-powerful workstations?
There are rumors that IBM is going to massively pull out of the mainframe
business leaving a big void.
What do you guys and gals think?
--
adi...@magnus.acs.ohio-state.edu
Any discussion on this topic via electronic mail is welcomed.
Path: sparky!uunet!ns-mx!hitchcock!fineberg
From: fineberg@hitchcock (Sam Fineberg)
Newsgroups: comp.arch
Subject: Re: The Death of the Mainframe...
Message-ID: <12882@ns-mx.uiowa.edu>
Date: 31 May 92 02:16:27 GMT
References: <1992May29.065947.11906@magnus.acs.ohio-state.edu>
Sender: ne...@ns-mx.uiowa.edu
Reply-To: fine...@eng.uiowa.edu
Organization: Department of Elect. and Comp. Engr., University of Iowa, USA.
Lines: 25
In article <1992May29.0...@magnus.acs.ohio-state.edu> adi...@magnus.acs.ohio-state.edu
(Aaron T Dingus) writes:
>Alright, are mainframes doomed due to ultra-powerful workstations?
>
>There are rumors that IBM is going to massively pull out of the mainframe
>business leaving a big void.
>
>What do you guys and gals think?
>--
>adi...@magnus.acs.ohio-state.edu
>
>Any discussion on this topic via electronic mail is welcomed.
I think mainframes will outlive us all. I am surprised they don't have
mainframes in Star Trek. Business customers aren't concerned with trivial
issues like price and performance. All they want is ``backward
compatibility.''
Sam
P.S., What we call a mainframe may change.
--
Dr. Samuel A. Fineberg Department of Elect. and Comp. Engr.
fine...@eng.uiowa.edu University of Iowa
Voice: (319)335-5962 Iowa City, IA 52242, USA
FAX: (319)335-6028
Newsgroups: comp.arch
Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!
destroyer!ubc-cs!unixg.ubc.ca!kakwa.ucs.ualberta.ca!access.usask.ca!regina!
hercules.cs.uregina.ca!bayko
From: ba...@hercules.cs.uregina.ca (J. Bayko)
Subject: Re: The Death of the Mainframe...
Message-ID: <1992Jun1.193635.1408@regina.cs.uregina.ca>
Summary: ...In Star Trek...
Sender: ne...@regina.cs.uregina.ca
Reply-To: ba...@hercules.uregina.ca (J. Bayko)
Organization: University of Regina, Regina, Saskatchewan
References: <1992May29.065947.11906@magnus.acs.ohio-state.edu> <12882@ns-mx.uiowa.edu>
Date: Mon, 1 Jun 1992 19:36:35 GMT
Lines: 21
In article
<12...@ns-mx.uiowa.edu>
fine...@eng.uiowa.edu
writes:
>I think mainframes will outlive us all. I am surprised they don't have
>mainframes in Star Trek. Business customers aren't concerned with trivial
>issues like price and performance. All they want is ``backward
>compatibility.''
>
They do have mainframes in Star Trek. Everything is controlled by
the central computer, and when that's down, they can't even open those
automatic doors of theirs.
They can also override the entire ship's security with the little
terminal in the bar that controls the drink mixer.
Pretty stupid design, really.
In our world, mainframes are more like database machines that happen
to be able to do other stuff too. As long as huge databases are needed,
so will mainframes (even if, by some chance, they run a version of Unix).
John Bayko.
Path: sparky!uunet!charon.amdahl.com!amdahl!JUTS!cd.amdahl.com!jjs40
From: jj...@cd.amdahl.com (John Sullivan)
Newsgroups: comp.arch
Subject: Re: The Death of the Mainframe...
Message-ID: <a1h.02LU146701@JUTS.ccc.amdahl.com>
Date: 2 Jun 92 01:26:50 GMT
References: <1992May29.065947.11906@magnus.acs.ohio-state.edu>
<12882@ns-mx.uiowa.edu> <1992Jun1.193635.1408@regina.cs.uregina.ca>
Sender: net...@ccc.amdahl.com
Organization: Amdahl Corporation, Sunnyvale CA
Lines: 34
> In our world, mainframes are more like database machines that happen
>to be able to do other stuff too. As long as huge databases are needed,
>so will mainframes (even if, by some chance, they run a version of Unix).
>
>John Bayko.
I work in a production design environment consisting of Amdahl's implementation
of System V UNIX (called UTS) running on several Amdahl 5990 (370-compatible)
mainframes. The 5990 is a 4-processor MP system with a 10ns cycle time. The
particular machine I am using at the moment has 1GB of main storage and 3GB of
expanded storage (used for paging.) I think the cost of this machine is about
$5 million dollars.
UNIX runs extremely well in a large-scale mainframe environment. A quick check
reveals at the moment (4:30 pm) there are a total of 851 logon sessions
supporting 487 unique users. There are a total of 3100+ processes active.
There are 322 filesystems mounted for a total of 32.9GB of disk storage.
Interactive response time (typing into an xterm, running simple shell commands)
is as good or better than the Sparc IPC sitting on my desk. The machine also
runs a lot of batch jobs. Turn-around time for a typical batch job (a static
chip timing analysis program) that takes 15-20 minutes of CPU time is about 2
hours.
In December, we started shipping a machine called the 5995M which supports
up to 8 CPUs with a cycle time of 6.5ns. Uniprocessor performance is about
double 5990 uniprocessor performance. The maximum memory configuration
is 2GB of main storage (25ns ECL static RAM) and 8GB of extended storage
(standard 4MB dynamic ram chips). The list price for a full-blown 8P system
is somewhere around $30 million.
--
John Sullivan, Engineer/Computer Development. Email: jj...@cd.amdahl.com.
Amdahl Corporation, Sunnyvale CA. Phone: (408)746-4688.
Path: sparky!uunet!stanford.edu!rutgers!rochester!cantaloupe.srv.cs.cmu.edu!lindsay
From: lind...@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: The Death of the Mainframe...
Message-ID: <1992Jun03.022959.51862@cs.cmu.edu>
Date: 3 Jun 92 02:29:59 GMT
References: <12882@ns-mx.uiowa.edu> <1992Jun1.193635.1408@regina.cs.uregina.ca>
<a1h.02LU146701@JUTS.ccc.amdahl.com>
Organization: School of Computer Science, Carnegie Mellon
Lines: 20
Nntp-Posting-Host: gandalf.cs.cmu.edu
In article <a1h.02L...@JUTS.ccc.amdahl.com> jj...@cd.amdahl.com (John Sullivan) writes:
>UNIX runs extremely well in a large-scale mainframe environment.
>... 487 unique users. There are a total of 3100+ processes active.
>In December, we started shipping a machine called the 5995M which
>supports up to 8 CPUs with a cycle time of 6.5ns.
>The maximum memory configuration is 2GB of main storage (25ns ECL
>static RAM) and 8GB of extended storage
These are impressive numbers, and I'm sure that great effort went
into making a system that can be responsive to 500 people at once.
However, 6.5ns is the cycle time of the first Alpha chip, and
multiprocessor systems are expected, ahh, shortly.
Could you comment about the effort that would be needed to get
an Alpha multiprocessor to have similar performance? I presume
that 2GB of SRAM is a lot of the cost, and a lot of the secret?
--
Don D.C.Lindsay Carnegie Mellon Computer Science
Newsgroups: comp.arch
Path: sparky!uunet!uunet.ca!geac!itcyyz!yrloc!rbe
From: r...@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Re: The Death of the Mainframe...
Message-ID: <1992Jun6.195811.20871@yrloc.ipsa.reuter.COM>
Reply-To: r...@yrloc.ipsa.reuter.COM (Robert Bernecky)
Organization: Snake Island Research Inc, Toronto
References: <12882@ns-mx.uiowa.edu> <1992Jun1.193635.1408@regina.cs.uregina.ca>
<a1h.02LU146701@JUTS.ccc.amdahl.com> <1992Jun03.022959.51862@cs.cmu.edu>
Date: Sat, 6 Jun 92 19:58:11 GMT
Lines: 60
In article <1992Jun03.0...@cs.cmu.edu> lind...@cs.cmu.edu (Donald Lindsay) writes:
>
>In article <a1h.02L...@JUTS.ccc.amdahl.com> jj...@cd.amdahl.com (John Sullivan) writes:
>>UNIX runs extremely well in a large-scale mainframe environment.
>>... 487 unique users. There are a total of 3100+ processes active.
>>In December, we started shipping a machine called the 5995M which
>>supports up to 8 CPUs with a cycle time of 6.5ns.
>>The maximum memory configuration is 2GB of main storage (25ns ECL
>>static RAM) and 8GB of extended storage
>
>
>However, 6.5ns is the cycle time of the first Alpha chip, and
>multiprocessor systems are expected, ahh, shortly.
>
>Could you comment about the effort that would be needed to get
>an Alpha multiprocessor to have similar performance? I presume
>that 2GB of SRAM is a lot of the cost, and a lot of the secret?
Sigh. A REALLY FAST Processor is not the key to a mainframe in a shoebox.
It removes only 1 bottleneck. Mainframes are used for mainframe applications
(today - in the past, of course, they were also used to get cheap cpu
cycles) today for the following reasons:
a. Extremely high I/O bandwidth. Even S/370s of ten years ago had
I/O bandwidth in the 100-200 megabyte/second range. Today's
systems are significantly faster.
They also are supporting fiber optic channels, which boosts the
per channel bandwidth a goodly amount.
b. High concurrent I/O capability. S/370s of that era had 48 or 64
channels. Today's machines are likely better than that.
c. Fairly exotic I/O channels to avoid the need to interrupt the cpu
on each character or bit of data transfer.
d. Ability to support large numbers of I/O devices. Systems with
hundreds or even thousands of devices are not uncommon.
e. And, as I said above, you CAN get a fair hunk of cpu power out of
them as well, but that's becoming a relatively non-important issue.
f. Large amounts of main store and fast (dram) secondary storage.
By large, I mean in the multi-gigabyte range.
g. They don't break any more. Since the advent of the IBM 3380-style
dasd, and the 3081-style cpu, these machines have achieved,
IMHO, rock-solid reliability. When you spend millions on a machine,
it's not a big deal to place a lot of money into ECC, multi-pathing,
recovery logic, etc.
So, even if cpu cycles are free, you can't build a system with supercomputer
or mainframe power unless you spend a lot in other areas.
Bob
Robert Bernecky r...@yrloc.ipsa.reuter.com bern...@itrchq.itrc.on.ca
Snake Island Research Inc (416) 368-6944 FAX: (416) 360-4694
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9
Canada
Path: sparky!uunet!charon.amdahl.com!amdahl!JUTS!cd.amdahl.com!jjs40
From: jj...@cd.amdahl.com (John Sullivan)
Newsgroups: comp.arch
Subject: Mainframe...
Message-ID: <89T002r315xe01@JUTS.ccc.amdahl.com>
Date: 8 Jun 92 21:10:01 GMT
Sender: net...@ccc.amdahl.com
Organization: Amdahl Corporation, Sunnyvale CA
Lines: 105
Here are some more responses to questions I've received:
Raul Izahi Lopez wrote:
>This sound like a very exciting development enviroment. Would it be possible
>to run a few standard benchmarks, like SPEC92, for us to get an idea of how
>do workstations compare with your machines? I am not interested in TPS but
>on SPECint92 and SPECfloat92 since that is what represents to a certain
>degree what I do at work.
I've never had the time or resources to personally run the SPEC benchmarks
on one of our mainframes. I have had time to run a number of "toy" benchmarks
such as the dhrystone and c-loops (Livermore Fortran Kernals) on some of
our machines. So, I'll throw out anectdotal information with caveats.
If you want more detail than this, you'll have to do the work yourself.
For the Amdahl 5990, a 4-way MP ECL system first shipped in mid 1988 with a
10ns cycle time, I have heard a uniprocessor SPEC rating of about 50 quoted.
Most of my comparision has been against the Sparc IPC, a UP CMOS system
first shipped in early 1991 with a cycle time of 40ns. The SPEC number that
I have heard for the Sparc is about 18. These numbers would seem to
indicate that the 5990 is about 2.5 times faster than the IPC.
First thing to notice here is that the 5990 shipped nearly three years prior
to the IPC. In 1988, the first Sparc/R2000 systems were shipping with cycle
times of about 67ns. A 10ns workstation CPU with a SPEC rating was simply
impossible to build.
Second, the 5990 is an MP system design from the start. A 4-way 5990 has
an MP-factor in the range of 0.8 to 0.95. This means that putting 4 CPUs
in a system really does get nearly 4 times as much work done. Sun just
started shipping MP systems last year. Someone here tried using a 4-way
Sun server to run a multi-seat mechanical CAD system and found that they were
only getting about 2.0 to 2.5 times the performance that they would have
gotten over running on a single CPU system, giving an MP factor of 0.5 to
0.63.
In terms of running "toy" benchmarks, I would have to say that dhrystone
performance is actually about 4 times faster on the 5990 than on the Sparc
IPC. C-loops (floating point) performance is about 6 to 8 times faster on
the 5990 over the Sparc IPC. I think that rating a 5990 as only being 2.5
times as fast as a Sparc IPC is probably too low, but rating more than 4
times as fast would be too high.
So, basically the bottom line here on mainframe performance is that the
highest-end workstations shipping today are about as fast as the previous
generation of mainframes (Amdahl 5990, IBM 3090) with respect to single CPU
performance. As a number of people have pointed out before, single CPU
performance doesn't tell the whole story when it comes to large multi-user
systems. Having well-balanced, high capacity I/O, memory, and multi-processor
CPU performance will beat out raw CPU speed any day.
To put this all in a historical perspective, the first machine that Amdahl
ever built was called the Amdahl 470 and (I`m not certain of all of the
numbers here) it shipped around 1976 with a cycle time of 25ns. I found a
copy of the dhrystone benchmark with a README file that claimed the 470 ran
at about 15,000 dhrystones. The same dhrystone code runs on my Sparc IPC
at about 22,000 dhrystones.
A rule of thumb with mainframes is that a new generation of machines
will double the performance of the previous generation about every 5 years.
Starting from the 470, the 5990 counts as about a 3rd generation machine.
At the end of last year, we started shipping the 5995M with nearly twice
again the performance of the 5990. Even if the 5990 doesn't look too
impressive against today's high-end workstations and mini's, an 8 CPU
5995M will still blow anything else out of the water (And you'll pay
handsomely for the privilege.)
Finally, as far as I'm concerned, the single most important metric of system
performance is: How quickly can I get my job done so that I can go home and
drink a beer? On occasion, I have had to compile fairly large pieces of C
source code (20+ megabytes) on both a mainframe and a workstation. Even
given the fact that the mainframe is fairly well loaded, I still usually see
4-8 times better real, wall-clock response time over the workstation.
If I have a choice of which system to use, I'll pick the mainframe any day.
I do chip design for Amdahl mainframe CPUs. This means that I have to
run a wide variety of software tools ranging from design entry (logic entry,
design rule checking) to physical design (chip placement, routing, static
timing analysis) to simulation (chip/unit/system simulation.) Many of these
programs want to use a lot of memory (100+ megabytes) and CPU time (10+
minutes.) Now, there are about 150+ other engineers here all trying to do
chip design at the same time. This adds up to requiring a lot of computing
resources just to get a day's work done (Currently we take up most of 3
5990's with 4GB of RAM each.)
Could we do this kind of work on workstations? Yes and no. Our logical and
physical design entry tools are moving towards running on workstations. To
do this means we needed 150+ IPC-class workstations, each with something like
64MB of RAM plus a fast network and large fileservers. The cost of this,
in the ballpark of $2M, quickly begins to approach the cost of a mainframe.
However, it's still worth putting a workstation on every desk so that we can
use design tools which have X11-based graphical interfaces.
In terms of the routing/timing analysis and simulation tools, these will
probably never run on the workstations just because of memory and I/O
requirements. We could buy a high-end HP or MIPS server with 1GB of memory
for every 5-10 engineers to run this stuff. However, this again would cost
us almost as much as a mainframe and would be a lot less efficient from the
point of view of turn around time and sharing resources. Plus, it's much
more of a pain in the ass to get work done on 10 machines than it is to get
it done on one machine.
--
John Sullivan, Engineer/Computer Development. Email: jj...@cd.amdahl.com.
Amdahl Corporation, Sunnyvale CA. Phone: (408)746-4688.
Path: sparky!uunet!darwin.sura.net!mips!mash
From: ma...@mips.com (John Mashey)
Newsgroups: comp.arch
Subject: Re: The Death of the Mainframe...
Date: 8 Jun 1992 22:46:46 GMT
Organization: MIPS Computer Systems, Inc.
Lines: 74
Message-ID: <l37oqmINNc4j@spim.mips.com>
References: <a1h.02LU146701@JUTS.ccc.amdahl.com> <1992Jun03.022959.51862@cs.cmu.edu>
<1992Jun6.195811.20871@yrloc.ipsa.reuter.COM>
NNTP-Posting-Host: winchester.mips.com
In article <1992Jun6.1...@yrloc.ipsa.reuter.COM> r...@yrloc.ipsa.reuter.COM
(Robert Bernecky) writes:
The following list of Robert's is a fairly useful one. Mainframes certainly
aren't going away ... but there are certainly under pressure. Someone else
mentioned replacing a 3090 with SGIs (to do scheduling at United Airlines);
I mention a few more: MIPS workstations at American Airlines and Ansett
Airlines to do scheduling also; small MIPS systems in Montreal to
replace a 3090 for running databases [now sitting in a near-empty room :-)]
As many have said, it's I/O that makes the difference; fortunately, people
are now working pretty hard to condense fast/multiplexed I/O onto
small silicon to catch up with the CPUs.
I include a few notes tacked onto rbe's list:
>Sigh. A REALLY FAST Processor is not the key to a mainframe in a shoebox.
>It removes only 1 bottleneck. Mainframes are used for mainframe applications
> a. Extremely high I/O bandwidth. Even S/370s of ten years ago had
> I/O bandwidth in the 100-200 megabyte/second range. Today's
> systems are significantly faster.
There is still certainly a difference, mainly due to the nature and expense
of memory systems in micros versus mainframes. Of course, you often find that
the peak bandwidth per actual data channel is similar between mainframe
and micro ... but the mainframe can attach a lot more of them, which is
point b below of course.
> b. High concurrent I/O capability. S/370s of that era had 48 or 64
> c. Fairly exotic I/O channels to avoid the need to interrupt the cpu
> on each character or bit of data transfer.
Stated this way, I don't think it is a big difference any more.
I.e., microprocessor I/O devices certainly do DMA, and there are serial
I/O multiplexors that avoid bothering you for every character.
Mainframe channels, of course, are much more complex, especially since
they'll do amazing thigns with dynamically-modified CCW-chains :-)
> d. Ability to support large numbers of I/O devices. Systems with
> hundreds or even thousands of devices are not uncommon.
There are certainly micros with hundreds of devices (i.e., serial ports,
if that counts as a device :-). There is certainly still a difference;
few micros will support what seems like acres of disks.
It's hard to tell how you count things like an Ethernet with attached
terminal servers: is that 1 device ... or many?
> f. Large amounts of main store and fast (dram) secondary storage.
> By large, I mean in the multi-gigabyte range.
Here, I think the gap is closing quickly. MIPS RC6380s already support
1GB of main memory, and although I've lost track, I believe that almost
everybody's larger micro-based servers are now up in the 768MB - 1GB range,
heading for 2GB this year or early next year.
>So, even if cpu cycles are free, you can't build a system with supercomputer
>or mainframe power unless you spend a lot in other areas.
Yes, still true; I think the fundamentals break down into:
a) Memory bandwidth; i.e., more interleaving certainly helps.
b) Peak I/O rate thru 1 channel. I'm not sure there's a lot of
difference here already.
c) Number of devices attacheable: still a difference, especially for
high-speed devices, due to physical design issues as much as anything.
As various people have noted, it's more of a software issue than a hardware
issue. Those who have big IMS databases will face noticable barriers
to moving off :-). Having talked to various mainframe users looking at
resizingwhat they're doing, it seems like a lot of them have identified
which applications move easy, which don't, and are trying to move the easy
ones quickly, so they can save the cycles for the hard ones, and thus
postpone the need to buy more mainframe cycles as possible.
Also, as people ahve noted, maybe the terminology is suspect. I.e.,
Tandem certainly sells mainframes ... but some of them have R3000s as
the main CPUs...
--
-john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: ma...@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash
DDD: 408-524-7015, 524-8253 or (main number) 408-720-1700
USPS: MIPS Computer Systems M/S 5-03, 950 DeGuigne, Sunnyvale, CA 94086-3650
Path: sparky!uunet!darwin.sura.net!mips!mash
From: ma...@mips.com (John Mashey)
Newsgroups: comp.arch
Subject: Re: Mainframe...
Date: 9 Jun 1992 01:30:11 GMT
Organization: MIPS Computer Systems, Inc.
Lines: 108
Message-ID: <l382d3INNfg7@spim.mips.com>
References: <89T002r315xe01@JUTS.ccc.amdahl.com>
NNTP-Posting-Host: winchester.mips.com
In article <89T002r...@JUTS.ccc.amdahl.com> jj...@cd.amdahl.com (John Sullivan) writes:
(Good info: it's good to see some people who actually *know* mainframes
posting data here...)
>Second, the 5990 is an MP system design from the start. A 4-way 5990 has
>in a system really does get nearly 4 times as much work done. Sun just
It's too bad these were against Suns, as they are assymmetric MPs, and therefore
may or may not scale as well as SMPs. This is supposed to change with
Solaris 2.0. Other people (like SGI, Pyramid, Sequent, etc) have been
shipping SMP micros for years.
>So, basically the bottom line here on mainframe performance is that the
>highest-end workstations shipping today are about as fast as the previous
>generation of mainframes (Amdahl 5990, IBM 3090) with respect to single CPU
Was it not true that 5990s are faster than 3090s?
Actually, I'd think it was more accurate to guess that the current *high-end*
workstations might be a bit faster than the 3090 (and maybe 5990),
as you'd want to include:
SPECmark89 SPECint92 SPECfp92 System
42 37 40 MIPS Magnum R4000PC
(no scache; single chip, i.e.,
not high end)
*59 53 57 MIPS RC6280/RC6380
50ish? IBM 3090 or Amdahl 5990??
70 62 63 SGI Crimson (R4000SC)
77 48 75 HP 750 (66Mhz)
89 42 86 IBM 560 (50Mhz)
*Not a workstation, but a server.
>A rule of thumb with mainframes is that a new generation of machines
>will double the performance of the previous generation about every 5 years.
>Starting from the 470, the 5990 counts as about a 3rd generation machine.
>At the end of last year, we started shipping the 5995M with nearly twice
>again the performance of the 5990. Even if the 5990 doesn't look too
>impressive against today's high-end workstations and mini's, an 8 CPU
>5995M will still blow anything else out of the water (And you'll pay
>handsomely for the privilege.)
A reasonable rule of thumb in micro land is to get 1.5X / year, although
not that smoothly. If I read your numbers right, I *think* that means the
high-end micros will catch the straight-line CPU performance of existing
5995s in 1Q93 or 2Q93, i.e., at that point, they're about 18 months
behind.
>Finally, as far as I'm concerned, the single most important metric of system
>performance is: How quickly can I get my job done so that I can go home and
Yes...
>source code (20+ megabytes) on both a mainframe and a workstation. Even
>given the fact that the mainframe is fairly well loaded, I still usually see
>4-8 times better real, wall-clock response time over the workstation.
>If I have a choice of which system to use, I'll pick the mainframe any day.
However, an interesting thing to see will be comparions of workstation/server
combinations; a lot of people believe that you really want to do certain
things on the servers ... as is noted in next mail.
>resources just to get a day's work done (Currently we take up most of 3
>5990's with 4GB of RAM each.)
>Could we do this kind of work on workstations? Yes and no. Our logical and
>physical design entry tools are moving towards running on workstations. To
>do this means we needed 150+ IPC-class workstations, each with something like
>64MB of RAM plus a fast network and large fileservers. The cost of this,
>in the ballpark of $2M, quickly begins to approach the cost of a mainframe.
>However, it's still worth putting a workstation on every desk so that we can
>use design tools which have X11-based graphical interfaces.
>
>In terms of the routing/timing analysis and simulation tools, these will
>probably never run on the workstations just because of memory and I/O
>requirements. We could buy a high-end HP or MIPS server with 1GB of memory
yes.
>for every 5-10 engineers to run this stuff. However, this again would cost
>us almost as much as a mainframe and would be a lot less efficient from the
>point of view of turn around time and sharing resources. Plus, it's much
>more of a pain in the ass to get work done on 10 machines than it is to get
>it done on one machine.
This is all plausible; one thing is absolutely clear: these days, it
really helps you do chip designs if you have access to the biggest and fastest
machines you can get at a reasonable price. From the numbers, it sounds
like the equivalent of a 4-CPU 5995 [sounds like about 100 SPECmark89s per
CPU +/- 20%] would be [for raw CPU speed]:
2 4-CPU RC6380s, or 4 2-CPU RC6380s.
(This would give you up to 2GB or 4GB of physical memory).
A 4-CPU RC6380-400 core [4 CPUs, 1GB memory, 1 I/O adaptor, OS]
~= $750K each, so about $1.5M for 2 together. Add disk.
A 2-CPU one (With 1GB of memory) ~= $625K, so 4 of them = $2.5M.
So, a reasonable bound is that, for raw CPU, and assuming that 1GB
memories are reasonable, is that you might grossly similar CPU thruput
for compute-intensive tasks for:
$1.5M (8 CPUs, 2GB) to $2.5M (8 CPUs, 4GB)
Can you calibrate a 4-CPU 5995, with 2GB-4GB of memory?
(Obviously all of these leaves out disks, monthly maintenance, etc, etc,
but it gives at least a little idea of what's going on. I uses these as a
a comparison, as these are certainly what our EDA folks use for their big
crunchers.)
Actually, what this leads to is: EDA simulations and such are growing rapidly
in their voraciousness; if you want to play in the next round, you'd either
better have lots of $$, or make big, fast machines yourself that you can
get cheap....
--
-john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: ma...@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash
DDD: 408-524-7015, 524-8253 or (main number) 408-720-1700
USPS: MIPS Computer Systems M/S 5-03, 950 DeGuigne, Sunnyvale, CA 94086-3650