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

Jakob Bohm jb-usenet at wisemo.com
Fri Feb 3 05:41:57 UTC 2017


On 03/02/2017 04:15, Robert Scott wrote:
> I am writing some parsing code for reading Time Server packets.  The
> first 32 bits of the returned packet are:
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |LI | VN  |Mode |    Stratum    |     Poll      |   Precision    |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> 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.

Retrying after a standard poll delay (with exponential backoff as
usual) is probably the best way to handle this.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded



More information about the questions mailing list