Hello folks,
I have a chrony 3.4 NTP server running on a rpi zero. That rpi zero also has an RTC and a 10base-T connector. Via that connector the chrony NTP server is on the local network connected to an unmanaged switch as 192.168.4.3 The time is provided by a Beiian 880
(it has an ublox gen 8 GPS with a ceramic patch antenna).
I also have an equivalent NTP server on an rpi 4 with another ublox M8T timing GPS but with an antenna connected via an RF cable and running ntpd 4.2.8p12 , the rpi4 is also connected to the same local network/switch as 192.168.4.2.
I use two Windows Intel NUCs gen 10 running the Meinberg NTP client to sync to the (rpi zero) 192.168.4.3, and keep the 192.168.4.2 as noselect just as a comparison as the final setup will only have the rpi zero Chrony NTP server. The whole thing, the two time
servers, the two NUCs and the network switch have been living on my south facing window for the last month as I tested various things. Windows Ntp is reporting about 1.7 to 2 msec
network delay on the rpi zero and about 0.5msec on the rpi4 (it has true 1Gps port)
The goal is to have a sub msec time accuracy on the windows NUCs from the rpi zero Beitian GPS, and that is accomplished easily, see below for a random snapshot:
Fig. 1 How the two NUCs are in sync with 192.168.4.3 (rpi zero chrony time server) - Adding link as I'm not sure how the mail list works.
|
|
drive.google.com
|
Now the issue:
I have seen a couple of times the Chrony server drift away from the ntpd server only to reset back hours later. I have enabled chrony logging and I was able to verify that when this happens, the PPS is not being logged in rfclocks.log while the GPS still is.
This means that the GPS still has a lock as NMEA GPS has meaningful data, hence the PPS is still available, but it is not being picked or used by chrony. The way I have setup the ublox is that PPS is only sent out if there is a GPS lock.
Here is the last drift I caught for which I have the chrony logs:
Fig. 2 Meinberg NTP in windows checking the offset againts the two NTP servers. The 192.168.4.3 is the chrony, and it is always on zero average as it is the only one used to sync time. The 192.168.4.2 (rpi 4 M8T) drifting means that actually the rpi zero is
drifiting.
The Meinberg NTP did keep on tracking the chrony server, but when chrony started to use PPS again it needed to make a 350+ usec correction to go back to true time (back to what the rpi4 ntpd server had). See below for that:
Fig.3 Meinberg NTP offset to rpi zero 192.168.4.3 with the large correction (>350usec) at around 18:00.
|
|
drive.google.com
|
Here is the refclocks log that shows the PPS disappearing at around 12:49
...and then returning at around 17:53:
Just for completeness I'm attaching here the chrony config file:
# Welcome to the chrony configuration file. See chrony.conf(5) for more
# information about usuable directives.
#pool 2.debian.pool.ntp.org iburst
#server 192.168.4.2
# This directive specify the location of the file containing ID/key pairs for
# NTP authentication.
keyfile /etc/chrony/chrony.keys
# This directive specify the file into which chronyd will store the rate
# information.
driftfile /var/lib/chrony/chrony.drift
# Uncomment the following line to turn logging on.
log tracking rawmeasurements statistics refclocks
# Log files location.
logdir /var/log/chrony
# Stop bad estimates upsetting machine clock.
maxupdateskew 100.0
# This directive enables kernel synchronisation (every 11 minutes) of the
# real-time clock. Note that it can’t be used along with the 'rtcfile' directive.
#rtcfile /var/lib/chrony/rtc
#rtcautotrim 0.01
rtcsync
#Serve time even if reference is lost
#local stratum 10
# Step the system clock instead of slewing it if the adjustment is larger than
# one second, but only in the first three clock updates.
makestep 0.001 3
allow 192.168.0.0/16
broadcast 60 192.168.4.3
refclock SHM 0 refid GPS precision 1e-1 offset 0.008 noselect
refclock PPS /dev/pps0 refid PPS lock GPS precision 1e-9 offset 0.000124 prefer
If you made it all the way down here 🙂 the question is, why is chrony dropping PPS for many hours allowing the system clock to drift a few hundreds usec? I'm try to understand the root cause so I can fix it. The final setup for this rig will
be with just the rpi zero with chrony and one Windows NUC so I would need it to be reliable and consistent over time like it would if I used the larger and more power hungry rpi4 with M8T and ntpd.
Please let me know if any other piece of data would make this more clear and I will add it.
Thanks a million!!
Enzo