Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!amdcad!cayman!davec From: davec@cayman.amd.com (Dave Christie) Newsgroups: comp.arch Subject: Re: SCSI on steroids, mainframes move over Message-ID: <26970@amdcad.AMD.COM> Date: 25 Aug 89 20:09:19 GMT References: <5932@pt.cs.cmu.edu> <3238@scolex.sco.COM> Sender: news@amdcad.AMD.COM Reply-To: davec@cayman.amd.com (Dave Christie) Organization: Advanced Micro Devices, Inc., Austin, Texas Lines: 66 Summary: Expires: Sender: Followup-To: In article <5932@pt.cs.cmu.edu> butcher@g.gp.cs.cmu.edu (Lawrence Butcher) writes: >My new question. Is fast I/O all that micros need to bury mainframes? Or >is user level I/O needed? In article Sean Fagan writes: >CDC Cyber's don't; they do have protection (in both senses that I got from >the above paragraph). Like other Seymour Cray machines, it doesn't have >virtual memory; instead, you have a "base address" and a "limit register" Being an ex-CDC'er, I have to clear up a glaring omission: the above applies to the old Cyber 170's - the newer 180's do have virtual memory - quite Multics-like. (Except much bigger segments. "For God's sake," said the Multics folks, "make the segments as big as you can!") Having seen other postings of Sean's, I'm sure he's aware of this - just a slip. Don't let it happen again ;-). As for user-level I/O, do you (LB) mean for controlling special-purpose devices (not common in the mainframe world) or for dealing with weird and wonderful data structures out on disk? For the latter, the 180 architecture, along with the NOS/VE OS, provides what I think is the ultimate(*) in user-level i/o: none! What I really mean is: implicit i/o via memory mapped files. Simply associate a file(s) with a data structure(s) in the virtual address space of your software, and access it anyway you like. Actual physical i/o occurs simply as part of normal paging. No fuss, no muss. (*) but then, I'm not up on what people generally mean by user-level i/o. This works really well with large memories (like where your database starts to look memory-resident). Especially if you can safely leave modified data in memory without writing it to disk until the pages simply get aged out. I believe this is one place where current micros, risc or cisc, fall down on the job: it's difficult, if not impossible, to recover central memory when the system crashes. (I'm sure people who know otherwise will enlighten me as to how easily it can be done!) The segments and rings of 180 provide firewalling - errors, be they hardware faults, user, application, or os bugs, are well identified and well contained. Only if something goes wrong in the innermost ring, in which the system spends a minimum of time, do things get tricky - and that can usually be handled with a consistency check. This sort of recovery capability is crucial for database systems - one of the primary domains of mainframes. This is starting to look more like an advertisement for fault-tolerance rather than efficient user-level i/o. Just another aspect of the world of difference between micros and mainframes. Lest this also look like an advertisement for Cyber 180s, let me say that other mainframes likely have similar capabilities, and probably some micro- based systems can do some of it (like memory mapped files), but like I said, there's still a world of difference between micros and mainframes. >Fast I/O is necessary, yes, for micros to "bury mainframes"; however, you >also need a way to *use* that, which, hardware-wise, will require better >memory subsystems (so that you can do I/O to at least one memory location and >still run code at full speed). Also, of course, you need an OS that will >take advantage of it, etc. >Sean Eric Fagan | "[Space] is not for the timid." Hear, hear. And effective cache coherency - no mean feat in this sort of system. ---------------- Dave Christie An ex-CDCer who knows just enough to form dangerous opinons like these...