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.
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.
- 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?
- 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.
Understood, at least in part. I have a nice Christmas reading list of man
pages and white papers!
Cheers,
Paul
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
