[ntp:questions] Re: tinker step 0 (always slew) and kernel time discipline

David L. Mills mills at udel.edu
Sat Sep 23 17:07:36 UTC 2006


Joe,

The intended application and behavior scenario of the prefer keyword is 
are carefully explained on the "Mitigation Rules and the prefer Keyword" 
page in the documentation. Your expectation goes beyond the intend 
stated in that page.

Dave

Joe Harvell wrote:

> Thanks for the information about fallback local reference clocks.  This 
> will help me when I talk to whomever is responsible for the NTP 
> configuration in this lab.
> 
>> Normally, I believe, if you have just two servers and they have non-
>> intersecting error bounds, they will both be rejected and the system 
>> will free run.  However, I think that prefer confuses the issue,
>> by not allowing the preferred one to be discarded.  I have a feeling
>> this is actually done by saying that the system stops discarding when
>> it would discard that one.  I suppose that the other one could still
>> be in contention at that point.
>>
> 
> I agree that the "prefer" keyword doesn't make sense in the case of an 
> NTP client without a physical clock.
> 
> Documentation about the "prefer" keyword states that if the prefer peer 
> survives the selection algorithm, then it will always survive the 
> clustering algorithm.  Additionally, if the prefer peer does survive, 
> then the combining algorithm is not used, and the "prefer" peer's clock 
> is supposed to be the only clock used when correcting the local clock.
> 
> So if the two servers have non-intersecting error bounds, then I would 
> expect both peers (including the "prefer" peer) to not survive the 
> selection algorithm, and the local clock should free run.
> 
> I wonder if whoever decided to use the "prefer" keyword thought it would 
> serve the same purpose as putting the fallback reference clocks at 
> different strata.
> 
> I'm not sure I can readily reproduce the scenario without the "prefer" 
> keyword being used.  But I can look into doing this if it would help.
> 
> 
>> The expected behaviour is that this has happened because one is giving
>> a false time and the other is giving UTC time.  The remaining servers
>> will also give UTC time, so the bad one will get voted out.
>>
>> I don't think prefer is intended to deal with broken clocks, only with
>> more accurate ones.




More information about the questions mailing list