Yes, whatever NTP daemon you run should only need to warp (set) the time once, shortly after startup. After that it can use clock_adjtime() to request the kernel to discipline the system clock in various ways.It is clear that from time to time there is a large shift of the frequency difference that slowly drift back to "close to zero" ppm.
What may be cause of this? timedatectl is trying to adjust RPi clock speed to get close to the internet time?
I was a bit skeptical that that would explain your funky graph, but I have reproduced those results. It seems that in default configuration, systemd-timesyncd requests a very aggressive correction every ~2048s, and never really gets to grips with the long-term drift.
The solution is sudo apt install chrony (no configuration changes should be necessary). Within an hour this has my Pi3's clock stable. chronyc tracking says it is 5.046ppm fast, and I think we can see that my DS3231 is around 0.3ppm fast.
I tried two other implementations from the repos, and they also stabilize the clock, but ntpsec takes much longer, while openntpd makes more erratic corrections first (many over 100ppm on the six second measurements).
Thanks for posting!
Statistics: Posted by jojopi — Sat Jun 15, 2024 8:56 am