[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