Re: Accurately measuring clock drift
Miroslav Lichvar <[email protected]>
| Newsgroups | gmane.comp.time.chrony.user |
|---|---|
| Message-ID | <ZJFZxvCrbFGJH1oD@localhost> |
On Mon, Jun 19, 2023 at 03:11:44PM -0700, Thangalin wrote: > I'm wondering, in no particular order: > > - Do the *esterror* values from calling *adjtimex()* yield an > apples-to-apples comparison between chrony and NTP? The values are estimated differently. Not an apples-to-apples comparison. > - Do we need to combine PPS1 with the NTP server? > - If so, how? Your configuration looks good to me. > - What else would we need to do to achieve sub-30 μs clock drift (or > sub-10 μs)? That depends on the hardware. There might be a better way to timestamp the PPS that doesn't involve interrupts. Is it an x86_64 machine? See these two examples: https://chrony.tuxfamily.org/examples.html#_server_using_reference_clock_on_serial_port https://chrony.tuxfamily.org/examples.html#_server_using_reference_clock_on_nic > - How can we verify that the clock isn't drifting more than 30 μs, > programatically (i.e., what API calls return the recent clock drift > adjustment value)? I don't think that is possible without a more accurate time source. > - What API call returns the most recent clock drift adjustment value in > nanoseconds? This information is not available in the kernel (adjtimex). You would need to use chronyc sources. -- Miroslav Lichvar -- To unsubscribe email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org with "unsubscribe" in the subject. For help email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org with "help" in the subject. Trouble? Email [email protected]