Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!agate!riacs!pioneer.arc.nasa.gov!lamaster From: lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) Newsgroups: comp.arch Subject: Re: Fast I/O Message-ID: <1991May21.203316.28924@riacs.edu> Date: 21 May 91 20:33:16 GMT Article-I.D.: riacs.1991May21.203316.28924 References: <97b302n807vo01@JUTS.ccc.amdahl.com> <13096@pt.cs.cmu.edu> Sender: news@riacs.edu Reply-To: lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) Organization: RIACS, NASA Ames Research Center Lines: 50 In article , marc@watson.ibm.com (Marc Auslander) writes: |> The old System 370 rule of thumb for I/O capacity was 1 instruction |> per BIT of I/O. The ratio is called (at least in IBM) E/B, spoken "E |> over B". Less than one was I/O intensive, greater than one cpu intensive. |> These numbers can vary widely, depending on system and application. And what you are measuring. Old examples: I once studied I/O on a CDC 7600. *User* I/O was about 30KW/sec=1.8 Mbits/sec. The 7600 was about 20 VAXMIPS (don't argue - it isn't germane) or 10 IBMMIPS of the day. Note: that did not include system generated I/O == swapping. So, I guess E/B > 5 This machine was batch only. And system I/O was not measured. Yet, it could easily have been 3X user I/O, based on current examples. The IBM 360/67, 2 processors at .5 IBMMIPS each, could page at about 200 pages/sec (all I/O was paging). So, swapping/paging is included. 200 pages X 4K Bytes/page. So, it was spending about .5 MIPS on users, and .5 MIPS on paging, and doing 6.6 Mbits/sec. Which is an E/B of (does E include overhead or not?) .1-.2 Gee, I wish more machines could do I/O proportionately as well as that 360/67. Another data point: a statement sometime in the last month on this newsgroup, that Daniel Siewiorek (the author) believes the current ratios should now be 8 MBytes/MIPS and 8 MBits==1 MB/sec/MIPS, due to the current demands of interactive processing. It should not be that difficult to achieve, since an IBM 360/67 could do it over 20 years ago. Of course, that system had fairly smart channels, as do the current generation of IBM (and Cray) systems. Somewhere I read recently that Sun planned for a sustained I/O rate of about 4 MBytes= 32 MBits/sec I/O on the Sun-4/4xx systems (16+ "MIPS" = SPECmarks), and the I/O cache can sustain over 9 MBytes/sec. So, improvement is possible, even on bus-based systems. I am inclined to agree with Siewiorek's numbers, based on my experience with network based applications, so I am concerned that next year's 100 SPECmark systems (threatened by a number of vendors) will not have adequate I/O. Multiple HiPPI channels will be a must if these systems are not going to spend most of their time waiting for I/O, at least for compute and file servers. On workstations, I confidently predict that another layer inserted on top of Motif and OpenLook will soak up the spare CPU cycles :-) |> Marc Auslander -- Hugh LaMaster, M/S 233-9, UUCP: ames!lamaster NASA Ames Research Center Internet: lamaster@ames.arc.nasa.gov Moffett Field, CA 94035 With Good Mailer: lamaster@george.arc.nasa.gov Phone: 415/604-1056 #include