Replies: 1 comment 4 replies
-
There is not really a notion of system peer, however to comply with the ntpv4 spec ntpd-rs chooses one of it's peers as it's primary source for calculating both the reference id and the stratum. For the time synchronization it by default does a weighted average between the sources that are marked as acceptable. The spike in dispersion likely has a different reason. Likely for some reason one of the sources became a lot less reliable around that point in time. You can likely see which by looking at the source uncertainties. |
Beta Was this translation helpful? Give feedback.
4 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I ask this because from the data I'm collecting from the metrics endpoint it seems to imply some notion of tracking a different host on the basis of the reported stratum. Here is a snapshot of my metrics since I started monitoring the endpoint: https://snapshots.raintank.io/dashboard/snapshot/1aYZ0MsowSAVRTfdjfzf2kGcWTIL6i5g?orgId=2
Notice how the reported stratum has been jumping between 2 and 3 reasonably frequently over the last couple of days, and how when it initially jumped to stratum 3 for an extended period, this resulted in a large jump in root dispersion, along with some interesting skewing of the peers towards higher offsets, both lagging behind the initial jump to stratum 3.
If there is a system peer, can it be exposed in
ntp-ctl status
and in the metrics endpoint?Beta Was this translation helpful? Give feedback.
All reactions