[ntp:questions] Accuracy of NTP - Advice Needed

Terje Mathisen "terje.mathisen at tmsw.no" at ntp.org
Fri Dec 23 10:09:50 UTC 2011


Paul Sobey wrote:
> Our internal testing to this point is that a stock ntpd pointed against
> a stratum 1 clock on a low contention gigabit ethernet (stratum 1 source
> and client less than 1ms apart) reports its own accuracy at approx 200
> microseconds. Further tuning the ntp config by adding the minpoll 4,
> maxpoll 6 and burst keywords result in ntpd reported accuracy dropping
> to within 10-20 microseconds (as reported by ntpq -p and borne out by
> loopstats). Further improvements can be made running ntpd in the RT
> priority class.

Good, you've done your homework! :-)
>
> My questions to you all, if you've read through the above waffle are:
>
> - what is a sensible expected accuracy of ntpd if pointed at several
> stratum 1 time sources across a low jitter gigabit network (we'd
> probably spread them over several UK and US sites for resiliency but all
> paths are low jitter and highly deterministic latency)

Gbit and low jitter is not quite compatible: 100 Mbit switches were 
using cut-through, while (afaik) all Gbit and up switches use store & 
forward, leading to higher latency and jitter.
>
> - are there any obvious tunables to improve accuracy other than
> minpoll/burst and process scheduling class, and how agressive can the
> polling cycles be sensible made?
>
> - can ntpd's own reported offset (ntpq -p or loopstats) be trusted
> (assuming high priority means it gets scheduled as desired)? I've quoted
> our apparent numbers at several people and the response is always 'pfft
> you can't trust ntpd to know its own offset' - but nobody can ever tell
> me why

You can use ntpd's internal numbers to verify the maximum possible 
offset (half the round trip time), you should be able to use statistics 
to show that the jitter is quite low as well.
>
> I appreciate these may appear to be silly questions with obvious answers
> - I am grateful in advance for your patience, and any research sources
> you may direct me to.

The best (and probably only possible) solution that does give you 
single-digit us is to route a PPS signal to each and every server, then 
use the network for approximate (~100 us) timing, with the PPS doing the 
last two orders of magnitude.

Terje
-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"



More information about the questions mailing list