On 2011-12-23, Paul Sobey <[email protected]> wrote: >>> 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.) > > Thanks for this reponse. Assuming I give NTP a direct connection to a PPS > clock, can you advise how I might determine what my accuracy actually is? > This is the piece I'm very unsure of - I had hoped I could simply use the > offset estimations from loopstats, now it seems I was mistaken in that > assumption, but I'm still unclear as to why, and what numbers I can > actually use to gain a measure.
With a good GPS receiver, AND a system which directly time tags the interrupt (no driver in between like a serial driver) you can assume that the time stamps on the gps signal are a reasonable estimate of the true offset (main problem is that interrupt latency). You could have the system put out a pulse the instant it receives the interrupt pulse (eg toggle a line on a parallel port) and attack an oscilliscope on the two lines (gps PPS line and the output port line ) to see what the time lag is. > >> You need to consider more than this; for example, ethernet switches can be a >> major source of degradation. > > Is this true even with the kind of architecture I've described? I'm aware > that switches and networks come in varying flavours, but I think I'm being > fair when I describe ours as low latency and low jitter. Most paths have > very little contention on. Not the problem. The routers have delays. Teh NICs have delays (some purposely wait to collect a reasonable amount of data before sending it out on the line). I used to have all 100MbS NICS and switches. I now have mixed 100Mbs and 1Gbs system and I see a really terrible degredation of the ntp network performance. While it used to be a very reliable 120us roundtrip on the ntp packets, it is now bimodal ( some about half 120-140, half 300 and a few up to 10ms delays). This change occured when the routers were replaced by Gbrouters. And there is very little contention on this network. > >>> - 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. > > What does calibrate the system mean? Is this 'use a GPS clock as an ntp > source' or some other technique I haven't heard of? It means using a pps source to measure the offsets of your system. > >>> - can ntpd's own reported offset (ntpq -p or loopstats) be trusted >>> (assuming high priority means it gets scheduled as desired)? I've quoted It can be trusted to tell you what the offsets are. It cannot be trusted to tell you what the difference between your system time and true time is. >>> 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. > > Understood, at least in part. I have a nice Christmas reading list of man > pages and white papers! > > Cheers, > Paul _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
