mehra@aquinas.csl.uiuc.edu (Pankaj Mehra) (11/27/90)
There was an error of oversight in my posting: (pointed to me by heddaya@cs.bu.edu) > Consider the case when HZ is 50 (typical on SMI's Sun 3/50 workstations). > If you sample every 10**6/HZ microseconds, and you are looking for idle > versus non-idle cycles, the instantaneous value of %CPU busy, defined > cycles spent non-idle > --------------------- x 100 > total cycles elapsed > is going to be 0% or 100%. Now, reduce the sampling period to 0.5(10**6/HZ). ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > The resolution will improve to 0%, 50%, or 100% busy. And, so on. > > Thus, the minimum resolution of raw (unaveraged) measurements places an > upper bound on sampling frequency, if one is trying to measure resource > utilization. The marked line should have read: double the sampling period to 2.0(10**6/HZ). ---------------------------------------------------------------------------- Summary of responses received: ---------------------------------------------------------------------------- From: Eugene N. Miya <eugene@wilbur.nas.nasa.gov> We just discussed this in a SPEC meeting. I prefer the hardware at thie time and fast clocks also help, anything else is open for discussion. John Hennesy made a special extra plea today as well. ---------------- From: mafla@cs.purdue.edu That is an interesting problem. It is well known that Unix is very weak in that area. I think commercial systems must have more accurate methods for timing (to do accounting). The authors of "The design and implementation of the 4.3BSD UNIX OS" hint that commercial systems have an exact method to collect information on CPU usage (rather than statistical sampling). For that what you need is separate clock(s) dedicated exclusively to do the measurements (like the microsecond resolution clock we have). ---------------- From: motcsd!greek!lance@apple.com For unix, I've given up on the concept of interrupt-based sampling. I want one clock (milliherz, perhaps) and two hardware counters, one that runs in system mode and the other that runs in user mode. That is, the system/user mode signal that exists somewhere in the CPU and MMU is ANDed with the clock into the two counters. This gives very solid kernel measurement and user program profiling. Measurement of particular subsystems (disk, network, etc.) is easy: on entry, save the current kernel counter, then restore it on exit, marking the difference up to the subsystem's "account". ---------------- -Pankaj Mehra University of Illinois -- Pankaj Mehra e-mail: {mehra@cs., mehra@aquinas.csl., p-mehra@}uiuc.edu phone: (217)244-7176