rhorn@BU-CS.BU.EDU (Rob Horn) (03/09/88)
Re: Mainframes (They aren't general purpose any more) I think Barry and others are overestimating the importance of MIPS. The real market for mainframes today is transaction processing and processors are rated together with software in terms of transactions per second. Transactions require MIPs, but they also require fast I/O that is organized specifically for transactions. Transactions are everywhere: each bank deposit, check, airline ticket, seat assignment, credit card check, etc. is a transaction. I heard the estimate that Wall Street firms process about one billion transactions per day. I have also heard otherwise intelligent people argue that UNIX cannot handle transactions. This is often true in the sense that current vendor offerings are not optimal for transactions. In terms of transactions per second against a single database, IBM mainframes are cheaper than Sun's. But this is more due to a lack of effort and interest on the part of UNIX developers. A transaction takes a few dozen bytes of input, does a few file I/O's (maybe), a bit of processing, and ships out a few hundred bytes of result. Boring. A transaction is only a glorified keystroke in emacs. But look at how they are structured on mainframes. The terminals (yes those awful 3270's) handle the input processing and send the message as a single unit. IBM's archaic interupt structure makes this particularly important, but compare the processor demand of 50 interupts on your favorite modern architecture with the total processing needed by the transaction. Often the interupt service would take more CPU than the transaction. Similarly, the structure of the process scheduler becomes important. In a transaction environment, it is probably better to wait for a natural break point like a file I/O or transaction complete, rather than interrupt a transaction. The mainframe makers are doing this kind of analysis and offer the software that is tuned for transactions. The academics and engineering researchers mostly ignore this market. If the new machines are tuned to meet the needs of transactions they will probably beat mainframes with ease. But they may also start to look a lot like mainframes themselves. Re: Mac's Don't count these out so quickly. I am writing this on a Mac that is networked to a Sun server. Not because I like little bitty screens, but because of cost and software. I need some drawing packages (MacDraft, Design, ...) and access to multiple machines on the network (NCSA Telnet). I could get the same capabilities on Sun's, but the cost for the drawing package alone on the Sun exceeded the total costs for hardware and software for four people using Mac's. For some purposes the only decent software available is on Mac's. Mac's lack multi-processing, virtual memory, and all manner of useful capabilities, by virtue of which their lowly 68000 matches the 68020 for such things as dragging, mouse tracking, etc. I wonder whether they will do as well when they are also burdened by all the demands imposed on a workstation. This will certainly affect the future of Mac operating systems. I would prefer to have an environment which was Unix plus the Mac interface, but price is definitely a factor. Rob Horn UUCP: ...harvard!adelie!infinet!rhorn Snail: Infinet, 40 High St., North Andover, MA (Note: harvard!infinet path is in maps but not working)
bzs@BU-CS.BU.EDU (Barry Shein) (03/09/88)
I agree with Rob that a lot of the interest in mainframes continues to be transaction processing. Besides mere performance (as Rob points out) there's also of course reliability, you can idle a lot of people if the system goes down and that means buckos, big buckos. To put that in perspective I have a late 70's O/S text with a case study of a transaction system that IBM did which claimed 15,000 on-line users. Hey, let's talk big... There was a recent interview in Unix/World or Unix/Review with a guy who did a big transaction processing system for Bell using Unix in the late 70's / early 80's. I remember he made a comment that if it weren't for the great support Unix gave for synchronous terminals (read: 3278s) it wouldn't have been possible (?!) I suppose one can argue whether or not transaction processing is something the Unix world should even bother with, but I guess there's big bucks in it, it's been done before apparently, so what the heck, de gustibus non disputendum. -B
daveb@geac.UUCP (David Collier-Brown) (03/12/88)
In article <8803082313.AA01918@infinet.uucp> harvard!ulowell!infinet!rhorn@BU-CS.BU.EDU (Rob Horn) writes: > >Re: Mainframes (They aren't general purpose any more) >... The mainframe makers are doing this kind of analysis and >offer the software that is tuned for transactions. The academics and >engineering researchers mostly ignore this market. > >If the new machines are tuned to meet the needs of transactions they >will probably beat mainframes with ease. But they may also start to >look a lot like mainframes themselves. Well, the academics are getting interested: there was a conference announced recently on transaction machine architectures. We're not presenting there, but Geac is in the business of producing high-peformance transaction-processing machines (multiple cpu, high reliability, high connectivity, built out of fast bitslicers for the library and financial markets). Alive and well in Canada. --dave (a Vax makes a poor 8000. An 8000 makes a poor Vax) c-b -- David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.