[ntp:questions] why is this clock not even considered?
David L. Mills
mills at udel.edu
Thu Dec 27 02:03:45 UTC 2007
Folkert,
First, temporarily remove all but the SHM driver to simplify debugging.
Then, look at the rv billoard for that association and note the flasher
bits. Then, look at the peer_unfit() routine in ntp_proto.c. The
comments detail the reasons for each bit. More information is in the
specification document and the notes on debugging a radio clock in the
documentation. The probable cause is dispersion too high or the noselect
option is present. The prefer option has nothing to do with this.
Dave
Folkert van Heusden wrote:
> Hi,
>
> See this:
> remote refid st t when poll reach delay offset jitter
> ==============================================================================
> +belle.intranet. 192.87.106.2 2 u 251 256 375 0.105 6.605 0.122
> +thegateap.intra 192.87.106.2 2 u 106 256 277 1.250 6.193 0.150
> *mauer.intranet. .DCFa. 1 u 253 256 377 0.154 0.068 0.071
> -auth1.xs4all.nl 193.79.237.14 2 u 53 256 277 7.899 17.204 2.084
> +ntp1.nl.uu.net .GPS. 1 u 8 256 337 13.599 6.001 8.832
> -ntp3-rz.rrze.un .DCFp. 1 u 21 256 377 29.566 0.059 0.237
> +ntps1-1.cs.tu-b .PPS. 1 u 1043 256 360 29.793 7.204 0.097
> +chime1.surfnet. .GPS. 1 u 42 256 377 9.135 6.485 2.794
> SHM(0) .SHM. 0 l 11 64 377 0.000 -5.365 1.810
>
> Why is the '.SHM.'-clock not even considered? Because of the negative offset?
>
>
> Folkert van Heusden
>
More information about the questions
mailing list