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
Uh oh!
There was an error while loading. Please reload this page.
-
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