David Woolley wrote:
In article <[EMAIL PROTECTED]>,
Joe Harvell <[EMAIL PROTECTED]> wrote:
This actually happened in a testbed for our application. NTP stats show
* that over the course of 22 days, the offsets of two configured NTP
* servers (both ours) serving one of our NTP clients started diverging
* up to a maximum distance of 800 seconds. During this time, our NTP
This could only happen if either the implementation was broken, or
they were mis-using the local clock pseudo reference clock. If the
servers were using a proper reference clock as their primary source,
root dispersion would have exceeded it's maximum value when the
error was probably a lot less than a second and the servers would have
been rejected completely.
<snip>
This just what happened. Both servers seem to have been serving their
unsynchronized local clocks. The servers diverged and the client had no
way to judge which one was more nearly correct. If the configuration
was not designed to fail, it certainly was left prone to failure of just
the sort that actually happened.
He would have been better off not using NTP at all! The clock might not
have been accurate but it would never have stepped.
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
