Re: Accurately measuring clock drift

William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology |____ [email protected]
Canada V6T 1Z1 ____|____ and Gravity ______|_    theory.physics.ubc.ca/

On Tue, 20 Jun 2023, Thangalin wrote:

> [CAUTION: Non-UBC Email]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

It is not the clock drift-- that is averave rate at which the clockticks
faster or slower than UTC. It is not the offset between the system time and
the pps time. That can jump around for all kins of reasons-- interrupt delays,
other programs delaying the reading ofthe system clock, etc.

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

You can have three machines all getting data from each other, without using
that data to disciplin the system clock.
> 
> Aside, is there anywhere in particular in the chronyc sources we should look?

You could tell us why you want to do what you say you want to do.

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