accurate runtime accounting (was Load Avarage graph pattern)
Chris Torek
torek at elf.ee.lbl.gov
Tue Jun 18 18:03:51 AEST 1991
In article <14081 at dog.ee.lbl.gov> I noted that Unix CPU accounting is
generally fairly poor, and wrote:
>>The solution is simple but requires relatively precise clocks. ...
In article <1991Jun12.130441.20640 at fccc.edu> stodola at orion.fccc.edu
(Robert K. Stodola) writes:
>One of my associates and I did a study of this a number of years ago
>(actually it was with a PDP-11/70 running IAS). We found that there
>was substantial clock synchronized usage on the system. The solution
>we found didn't require very precise clocks at all. Simply one whose
>rate was relatively prime to the system clock.
This works well in a number of situations, but I believe it will miss
short-lived processes on modern (fast) machines. Unix boxes generally
run their scheduling clock in the range 50..500 Hz. Some of these have
CPUs that run 40 million instructions per second; some things take only
a few thousand instructions, and it seems intuitively obvious% that
they might `slip through the cracks'. [%This is research-ese for `We
did not try it out but we wrote a paper on it anyway.' :-) ]
In other words, I think `PDP-11/70' may be an important constraint
above. A relatively prime profiling clock is likely to work well on
many VAXen as well (the 11/780 is typically slower than an 11/70, and
most microVAXen are only a few times faster). I would like to see
some measurements done on MIPS RC6280s, HP 700s, and so forth; I
expect things may have changed. (Of course, we could always speed
up the profiling clock, still keeping it relatively prime.)
--
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA Domain: torek at ee.lbl.gov
More information about the Comp.unix.wizards
mailing list