Chrony configured with stratum 0 for PTP hardware clock (PHC)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
NTP Charm |
Fix Released
|
Undecided
|
Xav Paice |
Bug Description
The default operation of the charm is to set up a local reference clock when that is available. This reference clock is configured with stratum 0.
This is problematic as chronyd then will end up selecting the local clock as the preferred source, which is not what you want when it's way off.
Log excerpt:
Apr 2 07:06:35 ps5-ra4-n6 systemd[1]: Starting chrony, an NTP client/server...
Apr 2 07:06:35 ps5-ra4-n6 chronyd-
Apr 2 07:06:35 ps5-ra4-n6 chronyd[637507]: chronyd version 3.5 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG)
Apr 2 07:06:35 ps5-ra4-n6 chronyd[637507]: Frequency -2.748 +/- 0.005 ppm read from /var/lib/
Apr 2 07:06:35 ps5-ra4-n6 systemd[1]: Started chrony, an NTP client/server.
Jan 6 06:50:36 ps5-ra4-n6 chronyd[637507]: Selected source 91.189.91.157
Jan 6 06:50:36 ps5-ra4-n6 chronyd[637507]: System clock wrong by 24104636.056977 seconds, adjustment started
Jan 6 06:50:36 ps5-ra4-n6 chronyd[637507]: System clock was stepped by 24104636.056977 seconds
Jan 6 06:50:55 ps5-ra4-n6 chronyd[637507]: Can't synchronise: no majority
Jan 6 06:51:43 ps5-ra4-n6 chronyd[637507]: Source 91.189.91.157 replaced with 91.189.94.4
Apr 2 07:07:47 ps5-ra4-n6 chronyd[637507]: Selected source PHC0
Apr 2 07:07:47 ps5-ra4-n6 chronyd[637507]: System clock wrong by -24104636.056942 seconds, adjustment started
Apr 2 07:07:47 ps5-ra4-n6 chronyd[637507]: System clock was stepped by -24104636.056942 seconds
The above system first correctly steps the clock based on information from the one NTP server configured and then suddenly reverts back to using the local clock as source due to it having a better stratum.
The charm is in this case configured with a single NTP server which probably is a factor in the mix, but even servers that have multiple NTP servers confgiured may end up with a connection to one or none at any point in time.
I would suggest adding the stratum [0] statement to the configuration file to avoid situations like this.
Related branches
- Benjamin Allot: Approve
- Canonical IS Reviewers: Pending requested
-
Diff: 57 lines (+8/-7)2 files modifiedreactive/ntp.py (+7/-6)
templates/chrony.conf (+1/-1)
Changed in ntp-charm: | |
status: | Confirmed → Fix Released |
Not sure about the PHC0 as that is very setup dependent, but for NTP I agree that it would be useful to use mutliple servers, it will only sync to one anyway. But is able to use the others to check them against each other.
Since the charm can be smart and while improving it - if the charm could probe/test if the network is "hwtimestamp" compatible, then enabling that would be a huge improvement. Almost PHC accuracy with NTP reliability.