Jakob Bohm wrote:
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.
This is exactly right:
LI=3 is normally only seen on a recently booted server, but it would
also be correct if a server is configured with a single reference (like
a GPS clock) and that reference has lost its sync.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
