johnl@iecc.cambridge.ma.us (John R. Levine) (11/15/90)
In article <1990Nov14.210314.20463@dirtydog.ima.isc.com> suitti@ima.isc.com (Stephen Uitti) writes: >In article <1990Nov14.154322.8894@mp.cs.niu.edu> rickert@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@iecc.cambridge.ma.us, {ima|spdcc|world}!esegue!johnl "Typically supercomputers use a single microprocessor." -Boston Globe
devine@shodha.enet.dec.com (Bob Devine) (11/16/90)
John R. Levine writes: > 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. > > 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. It's not necessarily true that mainframe databases can't use a large number of processors. The UAL story you closed with gives the evidence that when a database is sufficiently partitioned into pieces that do not cause contention (called "shared nothing" in db lingo), a big increase in performance can be achieved. Now, knowing the amount of partitioning that gives the best price/performance is tough. Sidenote: For an excursion into the dark ages of computing when all programs were written in assembly by Real (TM) programmers and each program knows about the machine and storage architectures, go to an airline DP center. I visited UAL in Denver and was amazed at the huge disk farm and number of processors they have. Places like that and the credit card/banking folks will be using mainframes forever. Bob Devine
mandell@bach.helios.nd.edu (Dan Mandell) (11/21/90)
Dan Mandell Saint Mary's College Computer Services Notre Dame, In 46556 Internet: mandell@bach.helios.nd.edu Bitnet: xlykn8@irishmvs.bitnet