On 2017-02-03, Miroslav Lichvar <mlich...@redhat.com> wrote: > On 2017-02-03, Jakob Bohm <jb-use...@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. > _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions