On Thu, 2023-12-21 12:07:56 +0000, Maciej W. Rozycki <macro%orcam.me.uk@localhost> 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 --
Attachment:
signature.asc
Description: PGP signature