[ntp:questions] NTP Peer Keeps Swapping on Start-up
David L. Mills
mills at udel.edu
Mon Oct 4 23:25:57 UTC 2010
The simple answer is the local clock driver is never enabled unless no
other synchronization sources are present, so it never enters the
mitigation process. What often happens is that during startup and before
at least one synchronization source is found, the local clock driver
steals the clock. This one of the reasons I have strongly recommended to
avoid this driver in favor of orphan mode. There is a new feature called
orphan wait that delays a switch to orphan mode for five minutes, long
enough for at least one source to be selected.
If you are using a software distribution prior to the great code cleanup
of 2005, the local clock deriver at one time was always enabled.
Using either the local clock driver or orphan mode on a leaf client with
no dependent clients is a very problematic configuration. It doesn't
improve the clock performance in any way. Orphan mode might be useful
for a client operating as an orphan child where there are more than one
orphan parents on the same wire.
The "Mitigation Rules and the Prefer Keyword" page in the documentation
explains the mitigation process in great detail, but most would consider
it heavy reading.
David Woolley wrote:
> SteveW wrote:
>> On Oct 4, 4:40 pm, David Woolley <da... at ex.djwhome.demon.invalid>
>>> SteveW wrote:
>>>> Also, just to clarify regarding the reach value, the snippet I showed
>>>> is right at start-up and it quickly goes to 377 for the remote ntp
>>>> server and remains there.
>>> ntpq assoc, followed by ntpq rv for the association number.
>>> Typically the problem is that the local clock has rather narrow error
>>> bounds, and if the remote source disagrees, but also has narrow error
>>> bounds, there is conflict as to which one has the true time. If you
>>> have a legitimate need for a local clock, you should make sure all your
>>> local clocks can be outvoted by real clocks.
>> How do I make sure the local clocks can be outvoted by real clocks?
> You ensure that more server lines reference servers traceable to true
> time, than reference servers dependent on a local clock.
>> Also, here is the result from debug:
>> [16:53:13] ind assid status conf reach auth condition last_event cnt
>> [16:53:13] ===========================================================
>> [16:53:13] 1 58883 9424 yes yes none candidate reachable 2
>> [16:53:13] 2 58884 963a yes yes none sys.peer sys_peer
> Neither is being rejected, but I guess that the anti-clock hopping
> logic is in effect. If this weren't the local clock, I would say the
> time was being disciplined by a combination of both sources. I'm not
> sure what happens with the local clock. rv 0 will tell you what
> offset value is being used to discipline the clock. If only the local
> clock is being used, it will be zero.
> questions mailing list
> questions at lists.ntp.org
More information about the questions