On Sat 29 Jun 2024 at 06:53:48 (+0200), to...@tuxteam.de wrote: > On Fri, Jun 28, 2024 at 02:05:48PM -0500, David Wright wrote: > > On Fri 28 Jun 2024 at 11:14:34 (-0500), John Hasler wrote: > > > David writes: > > > > It's not clear to me which NTP (protocol) packages are set up to use > > > > the util-linux stuff, assuming you're not rolling your own > > > > startup/shutdown scripts. (That's the problem in the Subject line, in > > > > a sense.) > > > > > > Chrony can. I don't know about Ntpsec. But that doesn't get the > > > adjustment made early enough. > > > > By "use the util-linux stuff" I meant use /sbin/hwclock. Neither > > chrony nor ntpsec can use hwclock by default as they don't list > > util-linux as a dependency. They use their own binaries. IDK whether > > you can deliberately configure them to use hwclock instead, or why > > any one would do so. > > Still they can set (and AFAIK discipline) the "hardware clock", via the > Linux kernel -- if things are set up this way. See the notes on the Linux > kernel's "11 minute mode" in the hwclock(8) man page.
I don't think that's a good idea for solving drift correction over long periods of time. You should periodically check the RTC and system clocks with NTP, and store the measurements of the RTC, in order to refine its drift rate over a longer and longer time interval. Every time you set the RTC, you invalidate any measurements you've already collected. Cheers, David.
