lindsay@gandalf.cs.cmu.edu (Donald Lindsay) (05/18/91)
In article <97b302n807vo01@JUTS.ccc.amdahl.com> haw30@DUTS.ccc.amdahl.com (PUT YOUR NAME HERE) writes: >>>Also, is there anything to prohibit a RISC based machine from having a high >>>speed IO subsystem? > The HIPPI? interface with RAID (Redundant Arrays of Inexpensive Disks) >disk systems is one possible solution. The Amdahl rule (1+ Mb/s, sustained, per MIP) suggests that the push towards 100 MHz processors is also a push past 100 Mb/s. The most desirable kind of I/O is network I/O: so, FDDI rates seem inevitable, with heart's desire somewhere beyond. A project here is building a gigabaud LAN. With that LAN, the RAID disk farm can be down the hall: no problem. The big fiber-and-laser push by telecom companies has made the network side entirely possible (at a price which will, we hope, drop). A rather less tractable problem is connecting the network to the RISC machine(s). For instance, there are machines which boast a 4 MB/s VMEbus interface, and that just doesn't mesh well with an 80 MB/s firehose. Those machines have to drink through a straw. Not surprisingly, the net will talk to the nearest Cray and Maspar over HPPI. With all respect to HP, I didn't hear plans for an EISA interface. -- Don D.C.Lindsay Carnegie Mellon Robotics Institute
wayne@dsndata.uucp (Wayne Schlitt) (05/20/91)
In article <13096@pt.cs.cmu.edu> lindsay@gandalf.cs.cmu.edu (Donald Lindsay) writes: > The Amdahl rule (1+ Mb/s, sustained, per MIP) suggests that the push > towards 100 MHz processors is also a push past 100 Mb/s. [ ... ] i havent been able to find Amdahl's law stated in any of the books i have looked at, but i cant say that i have looked real hard either... :-> if i remember correctly, it says something to the effect that for every mips of cpu, you need 1Mb of memory and 1Mb of I/O in order to have a "well balanced system". questions: 1) are those "Mb" mega-bytes or mega-bits? 2) what about flops? 3) when did Gene come up with this rule? 4) have the rules changed since the time Gene first said this? it seems to me that any more you have something like megabytes of memory = 2 to 4MB + 1 to 3MB/mips and the the i/o rate is _much_ lower than what Gene suggests. and 5) are there any computers that still live up to this rule? even ibm mainframes have more memory than mips (especially if you count the memory in the disk controllers). i really have no idea what a typical mainframe system has in terms of disk i/o... i guess you could argue that "modern" computers are trading memory for i/o, but could it be that the "old" computers were really trading i/o for memory? lastly, why do i feel like asking so many questions tonight? -wayne
marc@watson.ibm.com (Marc Auslander) (05/21/91)
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. A risc workstation running a real 10 mips today might be capable of 100 4k disk transfers a second, which is about 3 megabits. So E/B is about 3. In other words, by the old standards, workstations are optimized for computation - which is in fact correct. -- Marc Auslander <marc@watson.ibm.com>
colin@array.UUCP (Colin Plumb) (05/22/91)
The modern notion of a memory hierarchy rather blurs the notion of I/O in many cases. You've got registers<->on-chip cache<->off-chip cache<-> local memory<->shared memory<->ramdisk<->fast disk<->slow (archival) disk<-> tape<->off-site storage. Has anyone got any rules of thumb for the apropriate sizes for these levels and the apropriate bandwidths to them? E.g. How fast should my local memory be to keep up with the load from the cache? How fast should the fast disk be to keep up with the paging load? How fast should the tape drives be to keep up with backup needs? I assume that the larger one level is, the less bandwidth it needs to the levels below, except for uncacheable writes (I may want to force a megabuck contract I just edited into off-site storage). Suggestions, anyone? -- -Colin
lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) (05/22/91)
In article <MARC.91May21081226@marc.watson.ibm.com>, 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 <marc@watson.ibm.com> -- 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 <std.disclaimer>