Re: Accurately measuring clock drift

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:
>

It's armv7l running kernel 4.14 with chrony 3.4. The 1PPS signal comes from
an Orolia SecureSync 1200-313 (
https://safran-navigation-timing.com/wp-content/uploads/2021/07/SecureSync_UserRefGuide_PN_1200-5000-0050_r31-1.pdf
).

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.
>
>