accurate runtime accounting (was Load Avarage graph pattern)

[Chris Torek]

>In article <14398 at dog.ee.lbl.gov> I wrote:
>>... I believe [a relatively prime accounting clock] will miss
>>short-lived processes on modern (fast) machines.

In article <1991Jun18.175921.14843 at fccc.edu> stodola at orion.fccc.edu
(Robert K. Stodola) writes:
>I guess I should have explained the context of the project.  The purpose was
>to obtain accurate usage information on a per user basis, and provide good
>average load statistics.

This is somewhat different from situations I have in mind, in which
people run one-time (or few-times) short throwaway programs.  In this
case there simply are not enough instances for the statistics to
average out.  What I do not know is whether increasing the frequency of
the sampling clock (always keeping it asynchronous with respect to the
scheduling clock) would suffice to flatten out the sampling jitter.

>... The importance of the statistical method of measurement is that you
>avoid the rhythms imposed by the system clock entirely.

Right.  The clock synchronization problem has been demonstrated
repeatedly, under various Unix systems and under other systems.  We
know it exists; we know an unsynchronized sampling clock fixes it in
some situations.  Whether it fixes it in what is becoming a more common
situation (fast Unix boxes) is, I think, still an open question.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek at ee.lbl.gov