Paul Sobey wrote:
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.
There are very few applications where this sort of accuracy is meaningful over distances of more than single figure kilometres.
You will need to consider latency between external events and the application program reading the time, and the resolution of the time presented, by the OS, to application programs.
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
For microsecond accuracy, I would say that NTP needs direct (PPS) connection to a GPS clock. On a very well managed LAN, with very good temperature control and a constant power dissipation on the machines, you might achieve it over LANs. On realistic internet connections, I don't think any technology will achieve it. (I guess you could use the internet to coordinate atomic clocks.)
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
Setting tight minpoll and maxpoll gives you poor frequency stability and reduces the tolerances to wander in the round trip asymmetry.
priority class. 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)
You need to consider more than this; for example, ethernet switches can be a major source of degradation.
- 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?
Very good temperature control, and maintaining a constant load on the machine.
It is also essential that you calibrate the system. This either means using GPS or a portable atomic clock.
- 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
It can be trusted as what it actually measures. It is not a measurement of the error from true time. If it were, and it could be trusted, ntpd would be remiss not to use it to correct the time to a point where the remaining offset was no longer a good measure. The offset on a locked up system should be several times larger than the RMS error in the actual system time.
_______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
