[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>
>> wrote:
>>> 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
> http://lists.ntp.org/listinfo/questions

More information about the questions mailing list