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.
David:
I tracked down the configuration of the NTP servers 192.168.0.1 and
192.168.0.2. Their normal NTP configuration is shown below. The problem
occurred during a system upgrade on 16 Aug when the ntp.conf file of
192.168.0.1 was accidentally truncated (empty). This was fixed on 8 Sep to the
normal configuration shown below.
I don't understand why sysmgr0 or sysmgr1 would ever look at the time from 192.168.0.1
since it should have shown it was unsynced. I suspect it has to do with the
"prefer" keyword. Should I file a bug report?
==============================================================================
192.168.0.1
==============================================================================
# BEGIN NTP SERVERS
server ntp-3
server ntp-2
server ntp
# END NTP SERVERS
# BEGIN NTP PEERS
# END NTP PEERS
# BEGIN NTP OPTIONS
driftfile /var/opt/NTP/ntp.drift
statsdir /var/opt/NTP/ntpstats
filegen peerstats file peerstatistics_log type week enable
# END NTP OPTIONS
==============================================================================
192.168.0.2
==============================================================================
# BEGIN NTP SERVERS
server ntp-3
server ntp-2
server ntp
# END NTP SERVERS
# BEGIN NTP PEERS
# END NTP PEERS
# BEGIN NTP OPTIONS
driftfile /var/opt/NTP/ntp.drift
statsdir /var/opt/NTP/ntpstats
filegen peerstats file peerstatistics_log type week enable
# END NTP OPTIONS
#
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.
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
