[ntp:questions] LOCL clock reachability not 377?

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Wed Jul 30 02:15:39 UTC 2014


On 2014-07-29 14:46, Rob wrote:
> mike cook <michael.cook at sfr.fr> wrote:
>> Rob,
>>
>>    Looks like a bug anterior to your version. I see the same issue with version="ntpd 4.2.6p5 at 1.2349-o" whether or not there is a preferred local clock or not, and whether or not there are other active server associations.
>>
>> One for Harlen if it has not already been flagged.
>>
>> Tue Jul 29 21:32:48 CEST 2014
>>       remote           refid      st t when poll reach   delay   offset  jitter
>> ==============================================================================
>>   127.127.1.1     .LOCL.           5 l   25   64    1    0.000    0.000   0.008
>> o127.127.22.1    .PPS1.           0 l    8   16    1    0.000    0.002   0.008
>> ...
>>       remote           refid      st t when poll reach   delay   offset  jitter
>> ==============================================================================
>>   127.127.1.1     .LOCL.           5 l  300   64   20    0.000    0.000   0.008
>> o127.127.22.1    .PPS1.           0 l   11   16  377    0.000    0.004   0.008
>> ....
>>       remote           refid      st t when poll reach   delay   offset  jitter
>> ==============================================================================
>>   127.127.1.1     .LOCL.           5 l  437   64  100    0.000    0.000   0.008
>> o127.127.22.1    .PPS1.           0 l    4   16  377    0.000    0.004   0.008
>
> Ok, good that you see this as well!
>
> In the past I often had a LOCL clock because the supplier of a Linux
> system put that in as a default (we all know about that...), but in those
> days the reach for the LOCL clock was always 377 or I would have noticed.
>
> So this is something that crept in later, or is related to the PPS driver.

See http://www.eecis.udel.edu/~mills/ntp/html/prefer.html or equivalent for other releases.

One of the issues is that you always need more candidates than falsetickers to form a
majority clique (see http://www.eecis.udel.edu/~mills/ntp/html/select.html).

As I discovered recently under similar circumstances, offline servers are considered
falsetickers, and if you have insufficient other candidates, or fewer than 3, nothing
gets selected.

Is there any reason you could not specify a pool as backups to keep the numbers up?

-- 
Take care. Thanks, Brian Inglis


More information about the questions mailing list