[ntp:questions] fudge time1 for gps-18x-LVC?

Dave Hart davehart at gmail.com
Sun Feb 7 16:25:28 UTC 2010


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




More information about the questions mailing list