From: lamaster@pioneer.arc.nasa.gov (Hugh LaMaster)
Subject: Re: HOw many PC's make an Amdahl mainframe
Organization: NASA Ames Research Center, Moffett Field, CA
Date: Wed, 27 Jan 1993 02:43:51 GMT

In article <1993Jan26.215541.9957@adobe.com>, zstern@adobe.com (Zalman Stern) writes:
|> In article <1k46ioINNijv@fido.asd.sgi.com> gints@prophet.esd.sgi.com (Gints  
|> Klimanis) writes:
|> > An Amdahl CEO in yesterday's San Jose Mercury news claimed there was no
|> > room in the world that could how enough personal computers to match the
|> > power of an Amdahl mainframe.  Any guesses  as to the # of PC's and disk
|> > drives required to match this Amdahl Mount Everest of computing?


|> Comments like this indicate that the big iron boys are pretty desperate.  
|> They are fighting the dynamics of the market. There are *relatively* few  
|> problems that require "mainframe power." Over time mainframes must either  
|> become cheaper or more powerful. More powerful is limited because there are  
|> fewer and fewer problems that require that kind of power and it becomes  
|> harder and harder to make the machine more powerful. Cheaper is a problem  
|> because the margins go down and a lot of a mainframe's costs are not  
|> hardware oriented. (I.e. service, paying for the space and other central  
|> facilities required.)

Actually, though, there are plenty of problems that require the largest 
available power, and, in the commercial world, there are an increasing
number of really big applications (e.g. VISA-type credit cards) which,
generally, need an increasing number of transactions-per-second.  Anyone
tried to buy anything with a VISA card the last week before Christmas?
The wait can be rather long.   Credit card companies, Airline Reservations, 
banks with ATM applications, you-name-it.  All have increasing needs for
systems with expanding transaction rates.  A system which can do 2000 
transactions/sec may indeed be worth a *lot* more than 200 systems which 
can do 10 trans./sec.

The "problem" is not that users are not buying Big Iron.  In recent
articles, numbers have been cited in the ~$14-$14 Billion dollar range
for sales.  I would say that is a large market.  In dollar volume sales
declined *slightly* over the last few recessionary years.

If there is a problem, I suspect that it dates from the days when machines
being manufactured for $90K could sell for $1M+.  The industry is 
restructuring as competition increases and margins shrink.  The market for
big iron will be there for a long time, and it will continue to be large.  
It is just going to be a lot harder to stay in that market.  And even harder
to be in sales.


The reason I am posting this is that I think it is a big mistake
to underestimate the importance of big iron systems.  IMHO, most large
data centers will continue to use large systems to provide the cheapest
deliverable "bulk" CPU cycles, to manage large and growing data
requirements, and to provide the highest possible transaction rates.
As well as large engineering and scientific simulations.
What has already disappeared is the use of "mainframes" for relatively
mundane word processing, etc.  But, the data management requirements
are still there.  Today, big iron systems have memory bandwidths of
1-200 GBytes/sec, raw IO bandwidths of 1000 MBytes/sec., I/O
throughputs of around 100-200 MBytes/sec and up to 2000 integer-scalar 
MIPS.  While this is maybe only ~200 486 systems, there is an enormous 
difference in the capability between such systems.  A 200:1 difference in 
power totally changes the capability of a system, as was pointed out 
recently at Supercomputing '92.  I could go on, but, let's not confuse
the financial troubles of a few big iron manufacturers with the 
disappearance of their market.


-- 
  Hugh LaMaster, M/S 233-9,     UUCP:      ames!lamaster
  NASA Ames Research Center     Internet:  lamaster@ames.arc.nasa.gov
  Moffett Field, CA 94035-1000  Or:        lamaster@george.arc.nasa.gov 
  Phone:  415/604-1056                     #include <usenet/std_disclaimer.h> 
Newsgroups: comp.arch