Re: Measuring clock drift results

Suggest checking for competing time synchronization software.  E.g., run #
tcpdump -i any -n -w /tmp/port123.pcap port 123
Look for NTP requests to unexpected systems.

I had a system running ntpd + systemd with sporadic spikes.  Turns out
timesyncd would also adjust the system clock.

.


On Thu, Jul 13, 2023 at 3:32 PM Thangalin <[email protected]> wrote:

> Hi all,
>
> Thank you for suggesting we use /sys/class/pps/pps1/assert to measure the
> clock. Attached are graphs from running both chronyd and ntpd overnight.
> The images are also online:
>
> https://ibb.co/album/5YxH2m
>
> Chrony clearly improves the offsets to sub-20 microseconds much of the
> time. We're seeing some spikes in the timing, though, that exceed ntpd.*
> The chrony configuration file is the same as in the other thread (
> https://www.mail-archive.com/[email protected]/msg03281.html).
> We can't use the GPIO polling driver until I have a clear yes/no answer on
> the licensing issue.
>
> Other processes may be affected by changing the CPU, so we haven't
> switched to a constant frequency nor disabled the power saving states (e.g.
> idle=poll).
>
> Are there any other ways we could help chronyd stay below 20 microseconds
> (e.g., optimized build)?
>
> Many thanks!
>
> *ntpd had a single 1500+ us outlier, which we removed.
>