🚀 go-pugleaf

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?

How do you define "room"? I'm sure the blimp hangar over at Moffet would do  
it. I expect the average machine room you stuff an Amdahl mainframe in could  
hold enouhg PCs to numerically add up to an Amdahl mainframe. Being  
generous, the Mainframe = 1000 SPECMarks (N way multiprocessor) and 10  
Gigabytes/sec of "I/O bandwidth". At 30 SPECMarks per 486 box, thats 33 PCs.  
At 10 Megabytes per second I/O Bandwidth per EISA 486 (a probably bogus  
number) thats 1000 PCs. Assuming 3 cubic feet per PC that's somewhere  
between 100 and 3,000 cubic feet. You can put 1 or 2 gigs of disk in each PC  
to take care of the disk farm. Then just pile all them PC's up floor to  
celing and you're ready to do some real computin'!

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.)
--
Zalman Stern		   zalman@adobe.com		    (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
 "...And I didn't even need pants!!"--Dilbert on The Net (by Scott Adams)

Michael Jones of SGI was generous enough to take the time.  He also
comments that the mainframe as a whole is a more usable configuration
than the sum of the PC's.

Michael Jones:

I bet we could estimate it closely this way: Amdahl's powerful
mainframe must use advanced technology parts in order to be
so powerful. Parts of 2x the performance usually cost > 2x the
price. Harwdare system vendors get 4x to 6x parts cost as sale
price, while PC parts at Frye's are close to wholesale (2x). 

Ergo:

   Amdahl mainframe at $a. (say $3M)
   Amdahl cost at a/4 (at the most)
   this figure (a/4) represents "potential energy" of a sort.

   Typical system at Frye's is $p (say $2000).
   Frye's price is 2x cost, say, so the question is:
      How many cheap PC's for 2*(a/4), == a/(2p).

   Answer: 3,000,000/(2*2,000) = 750 pc's == 1 Amdahl

How reasonable is this, I wonder?

       750*30 MIPS = 22.5 BIPS
         750*200MB = 150 GBytes of DIsk
         750*1Mb/s = 750 MBytes/sec Disk transfer
 750 floppy drives = 1.08 GBytes removable storage ;-)
       750*4Mb RAM = 3 Gbytes of RAM
   750*Lotus 1-2-3 = 750 concurrent users
      750*1 RS-232 = 750 network attachments

Sounds ok. Now how big would the room capable of housing
750 pc's need to be? Well, if they were stacked in a cube
and each was 24"x24"x8", we have 3x^3 = 750, x^3 = 250, 
and x = 6.3. Rounding to x = 7, we have a stack that's
7x7x(3x7) for a size of 7*24 = 14 x 14 x 14 feet. Well,
that's too big, lets stack them half as high. Now the
room is 2^(1/2) bigger on each side, so it must be 19.7
feet on a side. Rounding, we get:

  A room 20' x 20' stacked solid with PC's 7' high.

Well, we need some room to get to the machines, so we can
change the 750 floppies during backups. Let's make the 
room 3x the length, so we have long rows of stacked PC's
with 4' aisles. Now the room is:

 20' wide, 60' long, and 7' high.

The question is, are there any rooms this large in the
world? 

	Considering that the mainframes last bastion of use is in the very
large database management (and transaction processing). I don't think a
gaggle of PC's can compete here BUT if you include a fileserver (data-
server) then the picture changes and the PC, as a smart data entry/query
terminal will win... the software is what's needed (if it doen't already
exist). IMHO.

  - Jim L.

In article <1993Jan26.225943.21955@enterprise.rdd.lmsc.lockheed.com>, lando@zycar.lmsc.com (Jim Landowski x45016) writes:
|> 
|> 	Considering that the mainframes last bastion of use is in the very
|> large database management (and transaction processing). I don't think a
|> gaggle of PC's can compete here BUT if you include a fileserver (data-
|> server) then the picture changes and the PC, as a smart data entry/query
|> terminal will win... the software is what's needed (if it doen't already
|> exist). IMHO.
|> 
|>   - Jim L.
|> 
Have you ever looked at the Tandem.  Granted it takes a lot of good software
and some special hardware to make it work right.

Sam

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> 

lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) writes:

>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  
>|> 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.)

[stuff deleted] 

>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.

That is true. I have run some simulations on CONVEX machines, workstations,
and PC's. I have an interesting simulation which would take about 3 months
on my PC, one month on the fastest workstation, and two weeks on a CONVEX.
(pretty well vectorizing code with big datasets, as you may quess. The PC
and workstation times are estimates from partial simulations.)

The PC time is completely unusab|e, even if I divide the problem for one
hundred PC's, I'd not get much more than communication traffic between those
PC's. The workstation time is almost usable, and the fortnight on CONVEX is
clearly practically usefull. Not every problem can be distributed for a
number of PC's because the dependencies would require so much communication
that most of the cycles would be wasted for it.

I'm sure that there will always be need for machines that are 6+ times
faster than the fastest PC. Well, 100+ is always better :-). 

----------------------------------------------------------------------
Jarmo J. Ahonen
Computing Centre, Lappeenranta University of Technology, P.O.Box 20,
SF-53851 Lappeenranta, Finland. email: Jarmo.Ahonen@lut.fi

In article ... gints@prophet.esd.sgi.com (Gints Klimanis) writes:

   Well, we need some room to get to the machines, so we can
   change the 750 floppies during backups. Let's make the 
   room 3x the length, so we have long rows of stacked PC's
   with 4' aisles. Now the room is:

    20' wide, 60' long, and 7' high.

   The question is, are there any rooms this large in the
   world? 

The HP open-plan office I am in at the moment is about 14' high and 
about 90' x 180' (this is just the Labs half), assuming that I can manage 
3' a stride and that my estimation by eye that the building is twice as 
long as wide is in bounds. A safety-factor of 27 seems acceptable.

Just strip out the cubicle walls. We've even got power and LAN laid on under
the floor-tiles ...
--

Regards | "Always code as if the guy who ends up maintaining your code will be
Kers.   | a violent psychopath who knows where you live." - John F. Woods

In article <1993Jan27.024351.17902@news.arc.nasa.gov>, lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) writes:

| 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.

  So who's doing the research on this? Obviously there will always be
problems which need a lot of peak TPS, and I doubt that making bigger
machines will prove practical for long.

  Just as scientific calculation has gone parallel, I would expect some
distributed TPS to be coming, but I sure see a lot of bigger and bigger
iron rather than cheap solutions you can put on a network of smaller
systems. I count vector processors as parallel for this discussion,
because they bypass the limitation that N operations take N times
longer than one operation.

  Recently we have seen PVM running here, a program which allows a user
to spread a problem over many machines while flooding the network and
bringing all the machines in question to a grinding halt. Has someone
done a similar program for TPS which I've missed? 

  The solutions I've seen are not seamless, don't scale well, and fail
to provide database consistency able to meet the standards I see met
with single machine systems.


-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
	A terible poker player can have a great hand,
	A obnoxious fool can have a good idea.
	Both are winners, regardless of who has them.

In article <1993Jan27.024351.17902@news.arc.nasa.gov> lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) writes:
>In article <1993Jan26.215541.9957@adobe.com>, zstern@adobe.com (Zalman Stern) writes:
>|> 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.

Amex have brought several `super'computers recently as I recall (though
it is late at night...) eg a CM-5 for doing ``promotional mailshots''
around 92Q2, and think I remember an nCUBE being mentioned too.

And they are not alone.  Much as I hate to think of all these `big'
machines being used for sending junk mail and running subscription
lists, those are big jobs that will get bigger.

Damon
-- 
Damon Hart-Davis        d@hd.org   London UK   Tel/Fax: +44 81 755 0077  [1.37]

Two separate jobs, two employers: (1) Editor of Parallelogram, (2) Consultant
and seller of uucp news/mail feeds (UK#5 pcm, FIRST MONTH FREE) and cheap Suns.

To answer the question someone asked, a large database is one with more
than 2^32 bytes. Addressing becomes a major ugly mess at that point.
For the end user, perhaps actually at 2^31 if you C, since the offset
is signed.

I doubt that faking offsets in BCD, or as extents, or whatever is
consistent with high performance and bug-free code.

Our RAM and disk have outgrown the word size in a decade. The original
XT had 10MB, today servers with multiple 2.3G drives, or even RAIDs of
1.3 or 2.3G units are not unheard of.

-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
	A terible poker player can have a great hand,
	A obnoxious fool can have a good idea.
	Both are winners, regardless of who has them.

Our news feed missed the beginning of this thread, so I never saw the original
posting.  But, I'll toss out some numbers to kick around.

Our current high-end machine is an 8-CPU shared memory symmetric
multiprocessor.  The FCS cycle time was 6.5ns, but I don't know what we are
currently shipping them at.  The CPU pipeline is capable of issuing an 
RX-format instruction every cycle, which is equivalent to a load immediately
followed by an ALU operation.  The machine holds 2GB of 25ns main storage, 
and 8GB of 80ns extended storage.  It supports 4 I/O processors, each of
which can handle up to 128 channels.  Both high-speed fiber-optic and older
parallel 370 channels are supported.

I won't argue a lot about CPU performance, because our metrics are different
from those used by the non-IBM compatible markets. 

As far as memory and I/O are concerned, PC's in general still can't support
more than 16MB of RAM.  A SCSI controller with DMA support provides about 
the same functionality as a mainframe I/O channel.  In theory, you can put
more than one in a PC, but the bus can't really support it at that point.

So, divide 10GB by 16MB and you get something in the range of 640 PC's to
match a mainframe on memory.  If you're concerned about I/O, it'll take 
about 512 PC's to match the mainframe.  I could also dig up the numbers on
weight and power consumption, but those are too scary to think about.

On a side note, someone mentioned interrupt handling capability.  The IBM
390 architecture has complex facilities for batching up multiple interrupt
events and distributing them across multiple CPUs.  This is a major win
when it comes to running thousands of I/O devices at the same time.

-- 
John Sullivan, Engineer/CPU Development  |  "Fools!  I'll destroy them all..."
Amdahl Corporation, Sunnyvale CA         |  jjs40@cd.amdahl.com, (408)746-4688

In article <128R02pn34lx01@JUTS.ccc.amdahl.com> jjs40@cd.amdahl.com (John Sullivan) writes:
> 
> As far as memory and I/O are concerned, PC's in general still can't support
> more than 16MB of RAM.  A SCSI controller with DMA support provides about 
> the same functionality as a mainframe I/O channel.  In theory, you can put
> more than one in a PC, but the bus can't really support it at that point.

Hmmm...  We regularly sell pc's with 32MB of memory, and an EISA bus
can certainly handle a couple of 32bit SCSI cards.  Many motherboards
now a days support 64MB of memory, and local bus SCSI boards are going
to up the performance a lot.  FDDI and such are making connecting
hundreds of pc's together more practical.  I would say that your
numbers are already off by a factor of 2-4 and they number of PC's
needed to "match" a mainframe is closing by a factor of 1.5 per year.


This is really a battle of "economy of scale" vs "economy of
locality".  It used to be much cheaper to by one 400MB disk than ten
40MB disks, but now with disk sizes exceeding 2GB and with the
incredible volume of PC's the cheapest way to by a 40GB disk is to buy
20 2GB disks and put them in a RAID.  Likewise with CPUs.  The IBM
370/158's were around 200 times faster than an apple II, but now the
fastest mainframe cpu is barely a factor of 2 or 3 faster than the
high end RISC chips and _much_ more expensive.  (CPU power as
measured by integer or floating point code, not memory bandwidth,
multiprocessing/interrupt stuff, etc.)  The easiest way to get lots of
MIPS nowadays its to use multiple CPUs, and many of the fastest
computers are going toward using pretty much standard PC CPUs.


By the year 2000, what people call a "mainframe" and the things they
will do with a "mainframe" won't look very much like what a
"mainframe" was when the term was coined.  Mainframes aren't dead, but
they are having to fight really hard to just to stay sort of alive.



-wayne