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