Thank you, Miroslav, that helps.
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:
What we're trying to do is find a way to confirm whether switching from NTP to chrony will give us less clock drift. Based on our measurements (my aforementioned graphs), it looks like switching from NTP to chrony has made the clock drift worse. This doesn't make sense to me because chrony is known for providing significant improvements upon NTP, and we're polling at 1-second intervals.
How would you go about measuring the clock drift between NTP and chrony so as to verify the drift has been reduced? I thought using the estimated error would provide a good indicator, but since it's not an apples-to-apples comparison, what alternatives are available?
Aside, is there anywhere in particular in the chronyc sources we should look?
Thank you!
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.