Killer Micro Question vs. mainframes
John R. Levine
johnl at iecc.cambridge.ma.us
Thu Nov 15 12:53:04 AEST 1990
In article <1990Nov14.210314.20463 at dirtydog.ima.isc.com> suitti at ima.isc.com (Stephen Uitti) writes:
>In article <1990Nov14.154322.8894 at mp.cs.niu.edu> rickert at mp.cs.niu.edu (Neil Rickert) writes:
>> You just might find the mainframes a better solution than the workstations.
>
>... If you can get the transaction rates high enough for the individual
>machines, and if your data can be partitioned properly, and if your plan
>allows easy expansion with new nodes, the cost effectiveness of the
>workstations may give them an edge. I wouldn't use a million Commodore
>C64's, though.
Mainframes CPUs aren't all that fast by current standards. On the other hand,
they have breaktaking I/O bandwidth, with dozens of disks simultaneously
transferring at once, each disk attached to several controllers, each
controller attached to several channels, each channel attached to all of the
memory.
An interesting paper from IBM that I saw a few years ago pointed out that for
most data base applications, you're better off with a smaller number of
faster processors than a larger number of slower ones even though the
aggregate MIPS is the same. The reason is contention -- the slower any
single processor is, the longer it will hold its locks and the more likely
that other processors will have to wait for it to get out of the way.
Large airline reservation systems, which support the highest transaction
rates around, have always used small numbers (like one or two) of the fastest
CPU they can get. When United airlines went to a multi-CPU system a few years
back, they cut the entire data base in two so each of two back end CPUs has
its dedicated disk farms, and the front end (or maybe two front ends) routes
the requests to the appropriate back end.
--
John R. Levine, IECC, POB 349, Cambridge MA 02238, +1 617 864 9650
johnl at iecc.cambridge.ma.us, {ima|spdcc|world}!esegue!johnl
"Typically supercomputers use a single microprocessor." -Boston Globe
More information about the Comp.unix.admin
mailing list