[ntp:questions] LOCL clock reachability not 377?

mike cook michael.cook at sfr.fr
Wed Jul 30 09:35:17 UTC 2014


Le 30 juil. 2014 à 11:00, Rob a écrit :

> mike cook <michael.cook at sfr.fr> wrote:
>> 
>> Paradoxically , the LCL clock is fine when there are no refclocks. That is, when you don't need or want it.
>> 
>>     remote           refid      st t when poll reach   delay   offset  jitter
>> ==============================================================================
>> *127.127.1.1     .LOCL.           5 l    8   64  377    0.000    0.000   0.008
>> +192.168.1.4     .PPS1.           1 u    5   16  377    0.900   -0.022   0.030
>> +192.168.1.23    .GPS.            1 u   23   64  377    0.804   -0.134   0.017
> 
> Maybe someone tried to handle that condition and had the sense of
> the test the wrong way around???
> 

 Someone who knows the code would pin this down in a second. What I think is happening is that the local clock driver along with all other refclocks/servers gets polled once at initialization time, so we see reach 1, and then there is some condition tested (do we have another, better refclock?) which if true causes the local clock to be left out out of the loop and so it's reach drifts, 2,4,8,10 etc. till the local clock is flagged a false ticker.   


> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions


More information about the questions mailing list