Hi guys and girls,

I have a problem with a GPS device. It is flagged "falsetick" by ntpd. It 
worked well for a few days but it stays as a falseticker since "Jun 23 
14:19:15".

I have 2 devices in LAN:

- the device 1 (192.168.1.1) has a GPS (GARMIN G-16x HVS) connected to it and a 
ntpd server with this configuration:

    tinker panic 0
    server 127.127.20.0 mode 1 prefer
    fudge 127.127.20.0 flag1 1 flag2 0 flag3 1 time2 0.600

    statistics peerstats loopstats
    statsdir /var/log
    filegen peerstats file ntpd.peers.log type none nolink enable
    filegen loopstats file ntpd.loops.log type none nolink enable

- the device 2 (192.168.1.3) has a ntpd server with this configuration:

    tinker panic 0
    server 192.168.1.1 iburst

    statistics peerstats loopstats
    statsdir /var/log
    filegen peerstats file ntpd.peers.log type none nolink enable
    filegen loopstats file ntpd.loops.log type none nolink enable

With ntpq software, I've got these information about the ntp server 192.168.1.1:

---------------------------------------------
# ntpq 192.168.1.1
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
xGPS_NMEA(0)     .GPS.            0 l   21   64  377    0.000  -93.417   0.019
ntpq> as

ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 19198  9144   yes   yes  none falsetick   reachable  4
ntpq> rv 19198
associd=19198 status=9144 conf, reach, sel_falsetick, 4 events, reachable,
srcadr=GPS_NMEA(0), srcport=123, dstadr=127.0.0.1, dstport=123, leap=00,
stratum=0, precision=-20, rootdelay=0.000, rootdisp=0.000, refid=GPS,
reftime=dd07801f.17eafe6a  Wed, Jul  5 2017 17:11:27.093,
rec=dd078020.30f1b22b  Wed, Jul  5 2017 17:11:28.191, reach=377,
unreach=0, hmode=3, pmode=4, hpoll=6, ppoll=6, headway=0, flash=00 ok,
keyid=0, ttl=1, offset=-93.417, delay=0.000, dispersion=0.941,
jitter=0.019,
filtdelay=     0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00,
filtoffset=  -93.42  -93.41  -93.41  -93.41  -93.41  -93.41  -93.39  -93.38,
filtdisp=      0.02    0.98    1.94    2.90    3.86    4.82    5.78    6.74
ntpq> clockvar
associd=0 status=00f2 15 events, clk_bad_format,
device="NMEA GPS Clock",
timecode="$GPRMC,151202,A,4649.1519,N,00630.1749,E,002.1,352.5,050717,001.3,E*7A",
poll=19345, noreply=18, badformat=8950, baddata=0, fudgetime2=600.000,
stratum=0, refid=GPS, flags=5
---------------------------------------------

As you can see, the source GPS_NMEA is flagged "falsetick". And, I don't 
understand why. I read the page 
https://www.eecis.udel.edu/~mills/ntp/html/select.html and several posts in the 
mailing list but I don't find relevant information for my case. We can see 
"clk_bad_format" status in the clockvar command return. Can be an explanation 
of the falsetick or there is a cryptic value that is too high that I need to 
mitigate with tos mindist or something like that ?

Maybe the GPS didn't receive some NMEA packets at one point (I put the GPS 
device inside my home while it was raining). Can be an explanation why ntpd 
think is not a reliable time source since then ? The GPS device has a clear 
view now but nothin change. The source remains a falseticker.

When a source is flagged flaseticker, can it not become a truechimer again ?

I would appreciate some advices about this problem.

Regards,
Anthony.
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Reply via email to