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
tims@uunet.uu.net (Tim Sesow (SSDS Rocky Mntn)) (11/16/90)
Neil Rickert writes: >Suppose you wanted a system to manage huge databases. You needed strong >integrity controls for concurrent database updates. You needed to access the >data in a huge room packed to the gills with disk drives. You needed to be >able to access the same data from any CPU in the system. You couldn't >tolerate the performance hit of the bottleneck caused by pumping all the data >down an ethernet. > > You just might find the mainframes a better solution than the workstations. > Mainframes do not really solve the stated problem either. My understanding is that DB2 (IBM's mainframe database star) is limited in database size to something less than 32 gigabytes (which is a real problem for databases in credit card companies, the Social Security Admin, etc)). Also, the channel speeds (FIPS60, etc) don't really match the performance of IPI-3 drives (not to mention PTDs and RAIDs). FDDI, not Ethernet, would be a preferred networking interface to get up to 24 Mbps effective throughput. It is practical with current products to build distributed processing systems with over 100 gigabytes of disk space using SYBASE or ORACLE and to provide the level of concurrency and integrity control necessary for thousands of users. However, cost is probably not the biggest advantage (big, fast disks are expensive everywhere) as is the increased reliability of loosely coupled (networked) multi-processors. Tim Sesow SSDS,Inc. Littleton, CO