Amdahl law, 1MIPS need 1MB mem & 1Mb/s I/O
Tim Keating
>Hello Folks:
>In many computer architecture books (e.g. Hennessy and Patterson, page 17)
>and papers it is mentioned that : - " Amdahl-Case law states that a 1-MIPS
>machine is balanced when it has 1 megabyte of memory and 1-megabit per sec
>throughput of I/O."
Given the current state of the Risc,Cisc, Unix, Os/2, N/t, etc..
I would say that the ratio is 10:1 is more appropriate.
I.E. It takes several instructions per byte to do anything
usefull with the data.
Tim K.
Thomas Gruen
In <37nal4$n...@geraldo.cc.utexas.edu> gu...@pegasus.ece.utexas.edu (Sunil Gupta) writes:
>In many computer architecture books (e.g. Hennessy and Patterson, page 17)
>and papers it is mentioned that : - " Amdahl-Case law states that a 1-MIPS
>machine is balanced when it has 1 megabyte of memory and 1-megabit per sec
>throughput of I/O."
>successful. Does anyone know the reasoning or the original source of the above >law. Any information in this direction will be greatly appreciated.
In [2] is a reference to Amdahls law [1]. The authors of [2] state, that
the I/O fraction is significantly higher than 1 Bit per instruction. But
the measurement was made on a VAX 11/785, which is CISC.
On our computer centers central server (Solbourne Series 5E, 8 CPU), I
observed a peak disk I/O (read+write) of 1 GB/h = 2.2 MBit/s. Unfortunately
I do not have the exact MIPS number at hand, but it is surely over 20 MIPS.
That means >10 instructions per bit of disk I/O .
I am interested in hearing about other measurements on (single CPU) RISC
computers (different workload, computers, ...).
References:
[1]: Amdahl: Validity of the Single Processor Approach to Achieving Large
Scale Computing Capabilities. American Federation of Information Processing
Societies. 1967. 483-485.
[2]: Akella, Siewiorek: Modelling and Measurement of the Impact of
Input/Output on System Performance. In 14th Symp. on Computer Architecture,
ACM, 1991. 390-399.
--
Thomas Gruen, Universitaet des Saarlandes, | Email: t...@cs.uni-sb.de
FB 14 Informatik - Inst. for comp. architecture | Tel.: +49-681/302-4129
Postfach 151150, 66123 Saarbruecken, Germany | Fax.: +49-681/302-4290
Zoltan Somogyi
>We have been trying to find the source of the above statement and have not been
>successful. Does anyone know the reasoning or the original source of the above >law. Any information in this direction will be greatly appreciated.
If I were you I'd look at the papers by Case in the January 1978 and April 1987
issues of CACM.
Zoltan Somogyi <z...@cs.mu.OZ.AU> http://www.cs.mu.oz.au/~zs/
Department of Computer Science, University of Melbourne, AUSTRALIA
Dick Wilmot
<snip>
>
>I am interested in hearing about other measurements on (single CPU) RISC
>computers (different workload, computers, ...).
>
I studied this fairly broadly two years ago while at Amdahl and found that 370-
compatible mainframes were doing about 7 I/O operations per millions instructions
when running at peak load (the load that forces you to upgrade equipment or
decommit applications and possibly job tenure. This seemed to be in a secular
decline (to fewer I/Os per instruction). I had gathered the input mostly from
papers published in Computer Measurement Group proceedings. Larger installations
tended to do much fewer I/O per instruction (they must and do 'tune' I/O more
because everyone tended to use the same devices but an almost constant percentage
of I/O will bunch to a few popular devices and it cannot be evened out for long).
It looked then as though mainframe installations would settle out at about
5 I/O operations per million instructions. I had to guesstimate that an average
I/O was for 4K byte blocks but the MVS operating system supports variable
length blocks so it's hard to be sure.
This is 1 million instructions for 160,000 bits of I/O which is far less I/O
than in AMdahl's rule [Amdahl's Law states that you cannot win much by speeding
up only one part of a system] but this ratio has more to do with economics than
engineering or physics: RAM prices dropped considerably (until recently) and
large buffers can abosrb a very large portion of I/O which tends to be extremely
skewed (high locality of reference).
I have not had time since then to check on reported I/O:MIPS ratios.
--
Dick Wilmot
Editor, Independent RAID Report
(510) 938-7425
Lynn Wheeler
from some numbers i did around '81 showing mainframe evolution between
the late 60s until then
increase
360/67 3081 *45 cpu
pageable pages 105 7000 *66
users 80 320 *4
channels 6 24 *4
fixed-head page disk 12meg 72meg *6
page I/O/sec 150 600 *4
user I/O/sec 100 300 *3
disk arms 45 32 *4?perform.
bytes/arm 29meg 630meg *23
avg. arm access 60mill 16mill *3.7
transfer rate .3meg 3meg *10
total data 1.2gig 20.1gig *18
page i/o transfered 4kbytes per; user i/o varied, but tended to be in
the 2k-10k range.
I had the pathlength on the '67 (circa 70-71) down into the 350 range
to take the page fault, select page, do page io, schedule/switch task,
take subsequent page i/o interrupt, process page request, and switch
back to faulting task (scheduling & dispatching included for the task
switches as well as prorated portion of page write pathlength is also
included). pathlength associated with user I/O (including some amount
of application processing) ran closer to 500-600 instructions.
Come the early '80s ... what is cause & what is effect ... the
processing power increased close to 50* ... but i/o only by 5* .... in
some respects the early '80s system used lots of memory for program &
data caching to compensate for the relatively lower I/O thruput
capacity. The 3081 was SMP so some kernel pathlength was little more
complex ... but couldn't account for the nearly 10* increase. However,
if the pathlengths didn't increase by that amount ... these machines
would have been running along at possibly 10% cpu use.
The full report shows some additional detail like aggregate bytes
transferred ... for '67 the E/B ratios were in bytes ... but more
recently ratios have been expressed as bits as relative ratio of cpu
vis-a-vis i/o capacity has shifted (in the late '60s I would have
said, 1mip, 2mbyte memory, 2-4mbyte/sec i/o. In some respects
increased use of memory for caching tends to lower I/O thruput
requirements (or relatively lower I/O thruput capacity has resulted in
increased use of memory for caching).
I also expressed resources as quantity per logged on users ... and the
relative change in the 10+ year period. Also disk thruput in terms of
i/o access/thruput per mbyte of data (which significantly declined
during the period) ... i.e increase the arm performance by a factor of
four, but increase the amount of data by a factor of nearly 24 ...
then the I/O accesses per mbyte of data drops by a factor of six.
In any case, the dynamic adaptive feedback that I did in the late '60s
had a significant different resource distribution to contend with by
1980 ... in some sense, for a balanced system, the shift tended to be
from cpu saturation to i/o saturation (i.e. 50* increase in cpu, 5*
increase in I/O, relative system I/O thruput had decreased by a factor
of 10*).
--
+-+-+-+
Anne & Lynn Wheeler | ly...@garlic.com, ly...@netcom.com
Sunil Gupta
Hello Folks:
In many computer architecture books (e.g. Hennessy and Patterson, page 17)
and papers it is mentioned that : - " Amdahl-Case law states that a 1-MIPS
machine is balanced when it has 1 megabyte of memory and 1-megabit per sec
throughput of I/O."
We have been trying to find the source of the above statement and have not been
successful. Does anyone know the reasoning or the original source of the above
law. Any information in this direction will be greatly appreciated.
Thanks very much.
Sunil Gupta
ECE Dept.
Univ. of Texas at Austin
Austin, TX - 78712.
Lynn Wheeler
... oh yes, kernel cpu percent (circa '70-'71) ran in the 35%-40%,
with 100% cpu use and user cpu ran 60-75%. kernel time included all
the paging supervisor, etc ... and a little of the user state.
circa '80+ ... still tended to run cpu at saturation (dynamic adaptive
feedback and mixed-mode workload) ... but kernel percent tended to run
into the 60% and higher range. under "light" load ... cpu could still
run at 100% cpu utilization ... but with much lower paging rate and
lower kernel percent.
... i.e. for the change by nearly a factor of 10 in the E/B ratio over
the 10+ year interval ... there was possibly 14* growth in kernel
pathlength per i/o ... with possibly only a 6-7* increase in
application pathlength per i/o.
Of course this was avg. E/B ratio for broad mix of applications (in
both the '70 & 80 time-frames). There is no comment how much was due
to shift in workload mix characteristics during the period vis-a-vis
shift in the instruction pathlength characteristics of the same type
of workload.
For one thing ... the avg MPL in the '70 era system tended to be
closer to 3-4 ... where as the MPL in the '80s possibly was in the
20-40 range (depending on how it was measured) ... i.e. the '70 era
system tended to run with significant number of processes in the
swap-queue ... while in the '80s the swap-queue tended to be empty.
The net was the '70 era systems tended to have higher page I/O ratio
per user instruction than the '80 era systems ... user pages in the
'80s tended to be resident for longer periods of time (i.e. four*
growth in avg users and a 66* growth in pageable pages ... nearly 16*
growth in avg real memory/user).
simple listing of the avg. resources/user growth during the
interval ... 11* cpu, 16* real stroage, *1 page I/O, <*1 user I/O, *4
mbytes user data (i.e. per avg. logged on user there was 11* more
cpu instructions, 16 times more real memory, but nearly the same
number of page I/Os and user I/Os per second).
The mbytes/sec user I/O may have been slightly greater than one
... the physical block size of the user area format increased by a
factor of five. However, since both systems tended to do contiguous
allocation and multi-block transfer, it is difficult to draw exact
correlation.
In any case, one characterization could be that the excess growth in
real storage was used for data & program caching in an attempt to
compensate for lack of equivalant increase in I/O thruput.
So again ... what is cause and what is effect? Did the hardware
"systems" change because of the change in application execution paths
... or did changes in application pathlengths (& application-mixes)
result in the hardware changes. In any case there was approximately a
10* increase in number of instructions per I/O (or a 10* decrease in
number of I/Os per instructions) during the interval. Which roughly
corresponds to the use of mbits/sec in lieu of mbytes/sec for the
calculations (i.e. the E/B ratios for some things might appear similar
... but the unit of measure drastically changed).
Mark Smotherman
>In many computer architecture books (e.g. Hennessy and Patterson, page 17)
>and papers it is mentioned that : - " Amdahl-Case law states that a 1-MIPS
>machine is balanced when it has 1 megabyte of memory and 1-megabit per sec
>throughput of I/O."
>We have been trying to find the source of the above statement and have not been
>successful. Does anyone know the reasoning or the original source of the above
>law. Any information in this direction will be greatly appreciated.
Blaauw and Brooks in their Computer Architecture manuscript (my copy is dated
1983) attribute this separately to
_Case's ratio_. Some application characteristics appear to be
invariant over a broad spectrum of applications and performances,
leading to some heuristic rules. Case, for example, finds an
invariant ratio between memory size and CPU speed in well-balanced
systems:
instructions/second
------------------- = 1
bytes of memory
[...] (Case, 19xx). [reference not given]
_Amdahl's rule of thumb_. Similarly, Amdahl finds an invariant ratio
between internal processing and input/output traffic, known as
*Amdahl's rule of thumb*:
bits of I/O per second
---------------------------- = 1
instructions executed/second
Amdahl also observes (1970) that housekeeping operations, those used
for controlling input/output and calculating addresses, occupied some
40% of all instruction executions, a ratio holding constant for at
least a decade. [Amdahl, G.M., 1970, "Storage and I/O parameters and
system potential," Proc. IEEE Computer Group Conference, pp. 371-372.]
This message was posted to comp.arch by Lewis Flynn three years ago:
| Newsgroups: comp.arch
| Subject: Amdahl's Rule
| Date: 17 May 91 21:51:52 GMT
|
| There was a discussion in this group recently concerning Amdahl's Rule
| and whether it should be updated, if it still held, etc. Some portions
| of what was being quoted didn't ring exactly true so I did some
| homework. First, I checked Hennessey and Patterson to see what was
| said on the subject there and it mostly agreed with what was on the
| net. So rather than do more second hand research, I called Gene to
| ask him about it. As it happened, he was out of the country, but, being
| the gentleman he is, he returned my call when he got back.
|
| As to the 1 megabit of I/O capacity per MIPS rule: he and his people
| did a lot of research on what workloads were being run on the then
| current machines (709/7090) and found that, in general, these workloads
| used 1 bit of I/O per instruction. Thus, in order to run these
| workloads, you must be able to sustain this rate. Peak I/O capability
| must be much higher to handle variations in demand. The actual data
| supporting this was from several sources and included a 2 month study
| at Lawrence Livermore Laboratories. The numbers from Livermore were
| 1.01 bits per instruction during the day and 1.1 to 1.2 bits per
| instruction for night time processing (my notes are a little fuzzy, so
| I may have reversed the day versus night). He didn't say so, but from
| the time frame and from the extensive study done at Livermore, I would
| speculate that this work was done as part of the research for the
| Stretch project.
|
| As to the 1 megabyte per MIPS rule: he stated that this was influenced
| by the cost of memory for the 709 series. He later found that on the
| 7090 that 2 megabytes/MIPS was more reasonable and this value held when
| he was doing 360/370 design at IBM and Amdahl. He said it really showed
| when the 370s hit the 16meg limit (24 bit addressing) and faster
| processors got no better throughput.
|
| I guess the most useful thing to conclude from this is that the first
| rule of processor design is "Know Thy Workload". The second most useful
| thing is that there's no substitute for lots of research and
| measurement.
Also, in Chapter 3, Performance and Balance, of Dan Siewiorek and Phil
Koopman, The Architecture of Supercomputers: Titan, A Case Study, they
suggest that that the ratios be changed by a factor of eight greater for
more modern systems to be well balanced.
These rules of thumb [Case's ratio and Amdahl's ratio] were
postulated over 25 years ago when the dominant mode of computation
was batch. To satisfy the demands of a contemporary multiprocessing
environment, the amount of memory and I/O should be multiplied by
approximately a factor of eight.
--
Mark Smotherman, Computer Science Dept., Clemson University, Clemson, SC
Henry G. Baker
>In many computer architecture books (e.g. Hennessy and Patterson, page 17)
>and papers it is mentioned that : - " Amdahl-Case law states that a 1-MIPS
>machine is balanced when it has 1 megabyte of memory and 1-megabit per sec
>throughput of I/O."
>
>We have been trying to find the source of the above statement and have not been
>successful. Does anyone know the reasoning or the original source of the above
>law. Any information in this direction will be greatly appreciated.
I think it came from Sun's early marketing material...
Henry Baker
Read ftp.netcom.com:/pub/hbaker/README for info on ftp-able papers.
3939...@qq.com
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.47.3870&rep=rep1&type=pdf
G. Amdahl. Storage and I/O Parameters and System Potential. In IEEE Computer GroupConference, pages 371–72, June 1970