On 10/07/17 19:06, Viallard Anthony wrote: > Hi folks, > > 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 > ... > 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 > ... > > 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.
Hi Anthony, I'm not an expert on this, but in my experience with the NMEA driver, you have to experiment with the settings a bit to find what works best for your hardware. Looking at your settings, you have: fudge 127.127.20.0 flag1 1 flag2 0 flag3 1 time2 0.600 - flag1 enable PPS - flag2 use rising edge of PPS signal (default) - flag3 enable kernel PPS discipline - time2 serial end of line time offset calibration factor, in seconds (The above are summarised from https://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html) I would experiment with flag3 and time2 first - 0.6 seconds seems an awfully long time for even a 4800 baud end-of-line delay, and I found my system worked better without both flag3 and time2. Regards, Paul _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
