On Fri, 4 Jan 2002, Mike Mason wrote:
> Why is the kernel.all.uptime metric provided in hour units rather than
> minutes or seconds?
No good reason that I can see ... gilly@xxxxxxxxxx provided the code
and markgw@xxxxxxx did the integration into the open source code base.
It seems to divide by 60 * 60, so the base data is obviously in seconds.
The only issue I can think of is overflow ... if the system is up more
than 136 years, the 32-bit unsigned long will overflow when counting
in seconds ... 8^)>
> I'm looking into converting "top" to use PCP. Top
> displays uptime in days, hours and minutes, but I can't get an accurate
> minute count out of PCP. Can kernel.all.uptime be changed to minute units
> or do I need to add another uptime metric for that?
Unless someone can contribute a good reason, I'd suggest just change it
and send us the patch.
> It seems that, as a general rule, metrics should be provided at the smallest
> reasonable units, then let the client programs convert to larger units if
> desired. ...
Agreed.
> ... Is there a general rule like this that PCP developers follow?
For the most part we have followed this rule.
The one caveat I'd make is that I am not going to export metrics in
bozo units like ticks and blocks because they are meaningless in the
larger context of multiple OSes and multiple OS versions and the
passage of time. We have always converted these to msec and Kbyte (in
both cases this does not _reduce_ the precision, but it does bring on
some overflow problems that need to be addressed through careful
arithmetic or extending the precision of the exported metric).
|