> 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. >
Hello, A server I manage with Garmin 16x LVS has time2 of 1.1 second at 4800 baud. Another server with 18x LVC has time2 of 0.6 second at the same 4800 baud. The corrections were configured after calibration with noselect. Not sure about 16x LVS firmware - it was setup about four years ago and was never updated afterwards, but 18x LVC was updated on Spring to the last release. Thank you, Hrant > Regards, > Paul > > _______________________________________________ > pool mailing list > [email protected] > http://lists.ntp.org/listinfo/pool -- Hrant Dadivanyan (aka Ran d'Adi) hrant(at)dadivanyan.net /* "Feci quod potui, faciant meliora potentes." */ ran(at)psg.com _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
