🚀 go-pugleaf

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>