Re: PSA: Clock drift and pkgin

On Thu, 2023-12-21 12:07:56 +0000, Maciej W. Rozycki <[email protected]> wrote:
> On Thu, 21 Dec 2023, Jan-Benedict Glaw wrote:
>  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).

The "377" is an octal representation of a (shifted) bitlist showing
the most recent 8 time requests for that peer. As you wrote, you
synced (ntpdate?) that box about a week ago, so I would have expected
(as the two oldest `peers` stats are waaay after that) that it, since
then, always reached its peers. But the non-377 values tell that ntpd
thinks it didn't reach that peer at those times.

> > 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.

IIRC at 500 it cuts off.

> > ...and finally: Why didn't ntpd react with increasing the poll
> > interval?
> 
>  Well, 1024 is already the maximum AFAIK.

Eh, that was expressed misleadingly :(  I ment: It recognized trouble
keeping time, why didn't it increase poll rate (ie. _reducing_ the
poll _interval_ from its maximum of 1024 seconds)?

> > 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)).

That's just a GENERIC kernel? You can easily cross-build NetBSD on any
Linux box and copy over the kernel to the NetBSD system. I usually
just let it build on my CI host and fetch whatever I need from stored
build artifacts. NetBSD will use the host compiler to build its
internal toolchain (GCC 10 based) and use that to actually cross-build
the release artifacts.  Feel free to drop me patches, you'll get free
compilation-as-a-service. :)

MfG, JBG

--

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQQlDTvPcScNjKREqWEdvV51g5nhuwUCZYQzzwAKCRAdvV51g5nh
u8SLAJ97GsJ7puiIl5Od/yrAwz376Xgc+gCfTvBjPCoh5uluJRfL4CzsQLH5NWI=
=2fyH
-----END PGP SIGNATURE-----