Hi, i’m been fetching NTP Pool error reports on my server and i’m trying to get some sort of error out of it. When analyzing offsets reported by peers does it make sense to take the best offset i.ie. the lowest? In the sense that there are plenty of factors that make the offset big, but not small. This is assuming the offset reported by the peer is accurate enough. What would you do I have a txt file with almost 21 months of data includin g SNR of satellites, number of visible satellites and used satellites and the average error of all peers and the best offset reported by peers.
Are you using NTPd or Chrony, as they have a different approach to offset.
NTPd is counting everything as offset, including the internet-trip-time.
Chrony doesn’t, that uses offset as it a calculated time only offset and used a device-trip-time.
Peers are not accurate that much, not even in your own network, in my network they are within 50us or better.
But if you compare to direct sat-pps, then the accuracy is close to 1-20ns, depending on the weather.
If you look at steady peers, best to look at the stand-dev time with Chrony, as a stable trip-path will give the best time from a peer.
Hope this helps, but beware, peers are typical below 1ms, good peers 250us.
Please clarify what you want to accomplish. A functioning GNSS (GPS, Galileo, etc) based NTP server with good sky view can synchronize within 10 microseconds of UTC. The NTP Pool offset reports are collected over the public Internet and are reliable to typically 1-50 milliseconds.
Unless your server or the remote monitors are not syncronized to UTC, the offset reports are measuring network delays. The notion of “best offset” is not applicable.
NTP Pool saves an offset report of my server. I have no other NTP server to compare with, within my network. I’m trying to se if the law of large numbers can be in my favor and see if i can pinpoint the GPS NTP accuracy out of it. I’m getting a mean error of -12 us +/- a sigma of 0.398 ms. The -12us error sounds consistent and sigma contains daily variations and possibly a seasonal one. Also maybe -12us can be totally casual/random obtained number.
System statistics through Munin shows a yearly average NTP offset of a couple of other servers of -21us and -159ns, but that is how good is that particular servers’s clock adjusted against the NTP GPS server, so…
There is an inversion of the error near 17hs UTC that is puzzling. That curve is a daily curve averaged over 2 years.
The limit to accuracy testing by a remote monitor is limited to the root distance: That is, the root delay/2 + root dispersion of the remote monitor.
Your server is the only stratum 1 I know in Uruguay.
I don’t see a way to measure your server (at the NTP level) without the use of other co-located stratum1s. Better would be to measure at the PPS level.
The NTP offset is most likely due to changes in your upstream internet; or if it’s a “real” change in the local clock it could be if you had a dramatic temperature change perhaps and the equipment took a few hours to recalibrate.
