[ntp:questions] How common is LI=3 (clocks not synchronized)?

William Unruh unruh at invalid.ca
Fri Feb 3 09:09:51 UTC 2017


On 2017-02-03, Miroslav Lichvar <mlichvar at redhat.com> wrote:
> On 2017-02-03, Jakob Bohm <jb-usenet at wisemo.com> wrote:
>> On 03/02/2017 04:15, Robert Scott wrote:
>>> When the two LI bits come back as 11 (clocks not synchronized) I have
>>> been treating that as a fatal error for that server.  I ignore that
>>> packet and do not attempt to retry my query for that server.  However
>>> I have found that LI=11 is not all that uncommon for servers from the
>>> pool.  Is my response to LI=11 the correct one?  Should I discard the
>>> response and should I write off that server for retries?  So far, the
>>> only reason I might retry a server is if my recvfrom() socket call
>>> times out.
>>>
>>
>> I suspect this is the expected response from a time server which has
>> recently booted and has not yet synchronized itself, probably combined
>> with stratum=15 or more.  But I haven't double checked this against
>> code or RFCs.
>
> Another reason for the "unsynchronized" leap bits might be a recent step
> of the system clock. If the clock is unstable, ntpd may need to step the
> clock often (after reaching the threshold of 128ms). I think I've
> seen some servers in the pool that behaved like that.

Those pool sources you probably would want to blackball.
>



More information about the questions mailing list