On Feb 7, 12:24 UTC, David Lord wrote: > Downside of not having fudge is first few NMEA offsets are 350ms > until the NMEA driver sorts out its own handling of pps. As soon as > offset shifts to a few ms or less jitter then rockets to near 350ms > and works down from there fairly quickly. > > It's probably worth trying with the fudge time1 in place as that > might just improve startup.
I would suggest you upgrade to ntpd 4.2.6 or 4.2.7. Based on your chronicles, I'm guessing you're using 4.2.5 or earlier, because you note that the NMEA driver is switching from serial end-of-line timestamps to PPS timestamps soon after starting, and because I'm assuming you don't have a fudge flag set for that driver to enable its PPSAPI use. IIRC, that is the classic behavior of NMEA compiled on a system with PPSAPI support -- if PPSAPI works on the NMEA serial port, it's used unconditionally. With 4.2.6, you have to specifically ask the NMEA driver to enable PPSAPI use with fudge 127.127.20.x flag1 1. Moreover, with older NMEA there is a single offset fudge available, used at least for serial end of line fudging but I think it was also used to offset the PPS timestamps. With 4.2.6, fudge time1 affects only NMEA PPS timestamps, and fudge time2 affects only NMEA serial EOL timestamps. That should enable you to cleanly fudge away the startup 350ms offset. If you do go to 4.2.6 or later, I suggest you do not attempt to use the same PPS signal via two different drivers at the same time, unless one is marked noselect. That is, either use NMEA alone with fudge flag1 1 to enable PPSAPI, or use NMEA without fudge flag1 and marked prefer alongside PPS/ATOM (22). http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver22.html Cheers, Dave Hart _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
