On Fri 28 Jun 2024 at 10:06:23 (-0400), Greg Wooledge wrote:
> 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.
In chrony, you'd use its rtcfile directive, which saves the time
when it last made a correction. Here's an outline:
rtcfile file
The rtcfile directive defines the name of the file in which
chronyd can save parameters associated with tracking the
accuracy of the RTC.
An example of the directive is:
rtcfile /var/lib/chrony/rtc
chronyd saves information in this file when it exits and when
the writertc command is issued in chronyc. The information
saved is the RTC’s error at some epoch, that epoch (in seconds
since January 1 1970), and the rate at which the RTC gains or
loses time.
So far, the support for real-time clocks is limited; their
code is even more system-specific than the rest of the
software. You can only use the RTC facilities (the rtcfile
directive and the -s command-line option to chronyd) if the
following three conditions apply:
1. You are running Linux.
2. The kernel is compiled with extended real-time clock
support (i.e. the /dev/rtc device is capable of doing
useful things).
3. You do not have other applications that need to make use
of /dev/rtc at all.
Perhaps ntpsec can do something similar.
Cheers,
David.
