Xref: utzoo comp.arch:19286 comp.unix.questions:26907 comp.unix.internals:1022 comp.unix.admin:528 comp.unix.large:188 comp.unix.misc:552 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!world!bzs From: bzs@world.std.com (Barry Shein) Newsgroups: comp.arch,comp.unix.questions,comp.unix.internals,comp.unix.admin,comp.unix.large,comp.unix.misc Subject: Re: Killer Micro Question Message-ID: Date: 15 Nov 90 01:07:25 GMT References: <16364@s.ms.uky.edu> <3849@vela.acs.oakland.edu> <1990Nov14.154322.8894@mp.cs.niu.edu> Sender: bzs@world.std.com (Barry Shein) Organization: The World Lines: 29 In-Reply-To: rickert@mp.cs.niu.edu's message of 14 Nov 90 15:43:22 GMT > 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. No, but FDDI runs at near bus speeds, so you're talking old technology for an application like this. IBM/370 drives run at about 5 MB/s max, not much a challenge for fiber, tho the software can be challenging for other reasons. Most of the advantage of IBM mainframes is that they *are* a distributed operating system, disk channels have significant processing power. One can do things like send a disk channel off looking for a database record and go back to something else until the answer is found. So we're sort of talking in circles here. > IBM didn't get that big by ignoring its customers' needs and forcing >them to buy an excessively expensive and underperforming system. >Instead they carefully monitored those needs, and evolved their >hardware and software to meet them. That's an interesting theory. -- -Barry Shein Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD