Re: [chrony-users] Measuring clock drift results

[Steven Sommars <stevesommarsntp@xxxxxxxxx>]

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 <thangalin@xxxxxxxxx> 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/chrony-users@xxxxxxxxxxxxxxxxxxxx/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.