Re: PSA: Clock drift and pkgin

On Thu, 21 Dec 2023, Jan-Benedict Glaw wrote:

> Looking at the numbers, I wonder about multiple issues here. Why did
> the jitter values rise up that much, while the delay keeps its value?

 I've seen that too, but I have no answer to this one.

> Why was two days ago's reachability so limited?

 It's the normal procedure when `ntpd' cannot cope with the drift and the 
sync drops.  It then adjusts system tick duration and tries to resync from 
scratch.  Reachability will cycle through 1, 3, 7, 17, 37, 77, 177, to 377 
octal then.  This also means `ntpd' was still in sync two days ago, though 
my samples didn't actually catch it (at 1024 poll rate I'd have to wait 
long).

> Did it max out its PLL frequency (`kerninfo` or `rv` will show that)?

 Frequency is now at 485.274, I don't know what the maximum is.

> ...and finally: Why didn't ntpd react with increasing the poll
> interval?

 Well, 1024 is already the maximum AFAIK.

> Do you, by chance, know the approximate times when you fetched
> "yesterdays" and "todays" numbers? Between that time, it drifted away
> by some 30 sec, but over what interval?

 I can restart `ntpd' with logging enabled, but really what has to be done 
at this point it is fixing the high-resolution timer frequency set in the 
kernel, and only then it will make sense to fiddle with NTP further.

 I do hope to have some time next week or maybe one after next to patch up
the kernel and rebuild (I've never done that before and need to figure out 
if I am able to cross-build the kernel on my POWER9/Linux system (with GCC 
14, to make things more interesting) or will I have to resort to a native 
build, which I suppose can take forever (but will be closer to how GENERIC 
has been built)).

  Maciej