Re: PSA: Clock drift and pkgin

On 2023-12-24 09:22, Jan-Benedict Glaw wrote:
> On Sat, 2023-12-23 12:49:16 +0100, Jan-Benedict Glaw <[email protected]> wrote:
>> After swapping terminators and cables, the conclusion is that one of
>> the system's SCSI cable's plug doesn't make proper contact to the
>> cable. Using a different plug on the same cable (which isn't at the
>> "perfect" location though) makes it work.
>>
>> So I'm now prepared with a 4000/60 :)
> 
> With the HDD image I used on the /90, that 4000/60 is running since
> some hours. No network connection, no ntpd. The image is a few months
> old, but for finding a misbehaving clock or lost interrupts, that
> should be good enough.
> 
>    While running idle (~ 3 h), I didn't notice loss of time. Maybe a
> second? But no more. (And that's over 9k6 serial...)
> 
>    Then I let it call gcc on a simple C file in a loop for another six
> to seven hours, and now I seem to have an offset of some 1.5 to 2
> seconds. No further messages (negative runtime) in `dmesg`. And a
> total of 2 sec over a timespan of 9 h would be totally fine for ntpd.
> 
>    I'll now run a fresh install with a newly built install ISO (already
> containing the recent page invalidation patch) and give it another
> try. But I wonder why that box shows a reasonable time. Maybe there's
> actually an issue with the code behind adjtime()?

Interesting thought. There could defiitely be something in there. I have 
ntp active on my systems. Maybe I should try not have that and see if 
time is more stable then. Thanks for that idea...
Anyone else who have observed if having ntp active or not have any 
correlation to how well time is managed?

   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