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