Re: PSA: Clock drift and pkgin

On 2023-12-13 22:43, Mouse wrote:
>>> Some, at least, of the values printed by top are not measurements,
>>> but decaying averages of measurements.
>> Load is, yes.  And that's not top specific.
> 
> Agreed.
> 
>> However, the time in different cpu states are actual measurements.
> 
> The ones in the CPU states bar, yes.  But JMoyer@, as quoted by
> paulkoning@, said "The values in the CPU and WCPU columns don't sum up
> to the percentages in the CPU states line at the top of the display".
> In my experience the WCPU and CPU columns also act like decaying
> averages, though I don't know details decay algorithm, in which case
> that failure to add up is no surprise at all even if timekeeping is
> perfect.

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. The 
CPU and WCPU is, I think, also doing some extrapolation work, which is 
what mess them up.
Because a process that have only existed for a fraction of the time 
since the last readout is still given some value of CPU usage based on 
what the system thinks it is as a snapshot. And that's why the numbers 
sometimes go weird.

> Test case: Run an infinite loop.  Suspend it - don't kill it, or it
> will disappear entirely - and notice that the WCPU and CPU values,
> which if pure measurements should be zero the second replot after you
> suspend it (the first replot will have a partial interval of busy and a
> partial interval of stopped), take some time to decay.
> 
> At least they do for me, on 9.1, 5.2, and even 1.4T.  I'm pretty sure
> they have on every variant of top I've tried using.

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. So it's a computed 
number somehow, but the question is more about how is it actually computed.

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

>>>>> Do you have measurements that show clock drift under load?
>>>> I was assuming he had.
>>> When running 1.4T on my VAX emulator, I've noticed clock drift.
>>> [...]
>> Do you know if that was drift affected by load, or just simple drift?
> 
> I had the impression it was affected by load, but I didn't investigate
> in enough detail to be sure.

That would be interesting to investigate further.

>> Because if you run a VAX without something like ntp, you will
>> *always* have some drift.
> 
> If you run pretty much _any_ computer without something to keep it
> synced, you will.  It's just a question of whether the hardware is
> precise enough for the drift to be obvious.

Agreed. And that was my basic point, I guess. :-)

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: [email protected]             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol