On Fri, Jun 28, 2024 at 09:48:12 -0400, Stefan Monnier wrote: > Oh, indeed, thanks. I had computed it manually from > `journalctl | grep stepped` and it gave close enough results. > The question remains: how to make use of that info upon wakeup to adjust > the "initial" time before NTP takes over.
As I understand it, the drift is used to speed up or slow down the system clock, so that it more closely tracks real time, and needs fewer nudges by NTP. As such, it really has nothing to do with how the system clock is initialized at boot time (or wake-from-suspend time? I don't do laptops). At boot time, the system clock is initialized by reading the hardware clock, with the assumptions that the hardware clock is not very accurate, but is better than nothing. The system clock will be adjusted by NTP once the network is up and once the NTP daemon has had a chance to communicate with its servers and figure out what time it actually is. > Indeed, I could try and shorten the time before the NTP info takes > precedence over the RTC-derived initial approximation (I haven't found > any way to tell ntpsec to do that, short of limiting the maximum > interval between pollings or maybe killing&restarting the deamon, both > of which seem too crude for my sense of aesthetics), but I'm more > interested in improving the initial approximation. I'm failing to understand your thought process here. The hardware clock has a time, which is loaded into the system clock to initialize it. That's it. The only variable factor here is whether the hardware clock's time is in UTC or some local time zone. You can't do anything with drift at this point, because you don't actually know how long you were asleep. All you know is the current HW clock time. It's not like you can say "Oh, I was asleep for 7.5234 hours, so I need to adjust the HW clock time forward by X seconds because I know it runs a bit slow." That information is not available to you.
