[ntp:questions] LOCL clock reachability not 377?
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
More information about the questions