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" _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
