PCP does not accept the unit of "tick" is a sane measure of time because
it has changed several times over the life of PCP (and changed even more
times over my lifetime).
All the cpu times are exported in milliseconds, ...
$ pminfo -d kernel.all.cpu.idle
kernel.all.cpu.idle
Data Type: 64-bit unsigned int InDom: PM_INDOM_NULL 0xffffffff
Semantics: counter Units: millisec
The other wrinkle is that the *all* cpu metrics are summed over all
CPUs, so the sum of the *all* counters (idle, user, sys, etc) on an N
CPU system goes up at N seconds per second (because we're purning N
seconds of CPU time every second).
So, if you have 2 CPUs and are sampling once per second, expect the
counter kernel.all.cpu.idle to go up by 2000 per second, so the rate
converted value is 2000 milliseconds per second which is correct.
The conversion breaks down as
/ hz -> seconds
* 1000 -> milliseconds
This is a common misunderstanding ... it should be captured in a FAQ
somewhere I guess.
On Thu, 2009-08-06 at 12:54 -0500, Martin Hicks wrote:
> I went looking today at these metrics, and I'm a bit confused by the
> values that are printed out. For example:
>
> case 23: /* kernel.all.cpu.idle */
> _pm_assign_utype(_pm_idletime_size, atom,
> 1000 * (double)proc_stat.idle / proc_stat.hz);
> break;
>
>
> What's the goal of the multiplication and division by HZ? This just
> looks plain wrong to me, but maybe I'm missing something. Additional
> support for this is that the idle metric in PCP advances by 10x what it
> should (200/sec):
>
> mort@laplace:~$ pmdumptext -t 1 kernel.all.cpu.idle
> Thu Aug 6 13:52:34 ?
> Thu Aug 6 13:52:35 1989.809
> Thu Aug 6 13:52:36 2000.010
>
> mort@laplace:~$ pminfo -f kernel.all.hz hinv.ncpu
>
> kernel.all.hz
> value 100
>
> hinv.ncpu
> value 2
>
>
> mh
>
> _______________________________________________
> pcp mailing list
> pcp@xxxxxxxxxxx
> http://oss.sgi.com/mailman/listinfo/pcp
|