Re: PSA: Clock drift and pkgin

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> Agreed. But it does not make sense that it goes above 100%.  That
> cannot be a result of decaying average, nor because of FP rounding
> errors.

It certainly can, at least theoretically, be because of rounding
errors.  Each number can be rounded up for display by slightly less
than half of one ULP of the displayed value; the total of the displayed
values will then will be larger than it should be by (number of values
affected) times (half an ulp minus epsilon).  And if the theoretical
sum is 100%....

> Oh, I agree that they are not straight numbers read out.  But I am
> pretty sure they are also not decaying averages, or a new process
> that starts running, even if it took the CPU 100% would have a slowly
> growing number in the CPU and WCPU column, which is not the case.

It's what I see.

I just now tried on a 9.1 machine.  Two ssh sessions to it.  In one of
them, I run top.  After top starts and has updated a time or two, in
the other, I run sh -c 'while :; do :; done'.

Truncating the displayed values at the decimal point, the WCPU column
showed, on the first five successive replots (five-second interval)
that showed that process at all, 64, 90, 95, 96, and 97 percent.  In a
repeat test, watching the CPU column instead, the first five values
(again, truncating at the decimal point): 12, 31, 46, 58, and 67
percent.

Also, that 9.1 machine has two cores, according to cpuctl list.  Doing
a test with two such infinite loops makes me think the actual limit,
for each column, is not 100% but rather 100% times the number of cores
available.  (If the original machine was multicore this could explain
numbers adding up to over 100%.)  After some 30+ seconds of settling
down, here are the top two lines from top on that two-cpu two-loop
test:

  PID USERNAME PRI NICE   SIZE   RES STATE      TIME   WCPU    CPU COMMAND
14313 mouse     30    0    20M 1648K RUN/1      1:24 99.41% 98.00% sh
 8862 mouse     30    0    20M 1640K CPU/0      1:19 99.22% 97.41% sh

I don't have a single-core 9.1 machine handy, but on a single-core 5.2
machine, a two-loop test gives me

  PID USERNAME PRI NICE   SIZE   RES STATE      TIME   WCPU    CPU COMMAND
 6071 mouse     34    0  2964K  952K RUN        0:24 49.07% 44.63% sh
 5956 mouse     33    0  2964K  952K RUN        0:24 48.14% 43.99% sh

The above test machines are not VAXen.  But in this respect I doubt top
varies from architecture to architecture.

> Anyway, I consider that number and issue to be unrelated to any clock
> drift.

Agreed.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B