[ntp:questions] Accuracy of NTP - Advice Needed

unruh unruh at invalid.ca
Fri Dec 23 04:33:53 UTC 2011


On 2011-12-22, Paul Sobey <buddha at the-annexe.net> wrote:
> Dear All,
>
> I work for a firm which requires clocks to be synchronised to quite a high 
> degree of accuracy.

What does "quite a high degree of accuracy" mean? Nearst hour, minute,
second, millisecond, microsecond, nanosecond, picosecond,...?
Those could all fall under that description. 

>
> We have an existing ntp-based infrastructure but want to improve on it to 
> the point where the bulk of our hosts are synchronised to single digit 
> microseconds of each other if possible. We have about 400 hosts in 
> production, spread across about 15 sites.

Not possible. Even if you give each a gps it is going to be hard (both
temp effects and time it takes for the signal to be timestamped by the
system are on the usec level.) And over the net it is absolutely
impossible. 


>
> I hear from many vendors and industry colleagues that 'ntp just isn't 
> suitable for high precision work and anything less than 1-2ms precision 
> requires ptp or direct connection to gps clock'. I find these numbers 

Well, no. direct network can give you 10s of usec accuracy. But not
gigabit networks or switches. That is more like 100s of usec.

> somewhat suspect, and wanted to ask the advice of you experts. In 
> particular I've read several threads on this list and other sites which 
> suggest that highly accurate synchronisations are possible, assuming OS 
> and network jitter can be minimised.
>
> 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.

No Network delays will dominate. 

>
> 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)

?? If the servers are off site, you will not get that. And gigabit
systems have variable latencies due to interrupt consilidation, etc. 

>
> - 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?

Attach a gps to each machine.
On a local network you can make them as agressive as you like. It is
your network. 

>
> - 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

Because if it did it could discipline the clock better. 

Attach a gps to the system, write a direct interrupt driven timestamping
routine and test it. (That was what I did)


>
> 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.
>
> Many thanks,
> Paul



More information about the questions mailing list