cl

folkert folkert at vanheusden.com
Wed Nov 20 13:47:05 UTC 2019


Hi,

I created a gps-interface. This clock ticks every 2 seconds sometimes 3, 4 of 13 seconds.
Not very reliable but very precise (as it is a contraption connected to a gps).

After it ran for an hour or so, I looked at the output of ntpmon:

     remote           refid      st t when poll reach   delay   offset   jitter
*SHM(0)          .SHM.            0 l    9   64  377   0.0000   0.0898   0.2752 <----
+192.168.65.211  .PPS.            1 u    4   64  377   0.8002   1.0819   0.1592
+kanval.intranet .PPS.            1 u   60   64  377   0.3585   1.3389   0.2585
+firewall.intran 192.168.64.79    2 u    7   64  377   0.2619   3.6651   0.4063
ntpd ntpsec-1.1.0+419 2018-03-14T12:03:57-0700Updated: 2019-11-20T14:42:05 (32)
assoc=26882: 1 event, clk_bad_signal                                            <----
dstadr=127.0.0.1:123 srcadr=127.127.28.0:123
reftime=2019-11-20T13:41:54.99991Z      leap=no-leap    rootdelay=0.0
    rec=2019-11-20T13:41:56.1686254Z    stratum= 0      rootdisp=0.0
    xmt=2019-11-20T13:41:56.1686018Z    precision= 21   dispersion=0.949185
unreach=0 hmode=3 pmode=4 hpoll=6 ppoll=10 headway=0 flash=0 keyid=0
filtdelay  =    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
filtoffset =    0.09    0.09    0.27    0.29    0.30    0.35    0.50    0.50
filtdisp   =    0.00    0.96    1.98    2.88    3.84    4.81    6.72    8.64
device='SHM/Shared memory interface' name='SHM' timecode='1574257318.000000000' poll=91 noreply=21 badformat=0 baddata=0
stratum=0 refid=SHM flags=

I noticed it says clk_bad_signal which indicates signal loss. That seems
to be correct. I'm surprised though that the clock is still selected as
a source?
Is this an ntp bug? Is it expected? And/or is there a setting I could do
to work around it? (e.g. will setting a minimum/maximum poll interval to
something help?)


regards

Folkert van Heusden


More information about the devel mailing list