[ntp:questions] NTP with GPS + PPS falsetick

juergen perlinger juergen.perlinger at t-online.de
Fri Jun 18 09:01:25 UTC 2010


On 06/15/2010 04:46 PM, Marc Leclerc wrote:
> Hi,
>
> So it seem that after a while NTP reject my GPS and PPS input for time
> keeping. The only source for time sync is the GPS, I cannot use other
> devices and/or remote servers.
>

Hi Marc,

I have/had similar problems with a Garmin GPS18x and the NMEA / ATOM
driver pair.

As far as I see it (and others are welcome to correct me) it is the fact
that ntpd sees this as two independent clocks, which they are not;
things get worse worse over time if they keep a a difference, which they
do if you cannot 'fudge' the 'real' clock close enough to the PPS clock.

>    remote        st t when poll reach   delay  offset  jitter
> ================================================================
>
> xGPS_PALISADE(1)  0 l    8   32  377    0.000   -1.193  0.409
> xPPS(0)           0 l    8   64  177    0.000  -104.82  6.030

In your case there seems to be shift of 103.6ms between the PPS and the
palisade clock, and since there are no other sources, both are marked
falsetickers after a while. (They are not from beginning, because they
are close enough for inital sync and ntpd likes to get enough sampled
data to trust it's own measurements and make a decision. This is
probably a bit over-simplified...)

And two is a terrible number of clocks to make a decision on -- or, as
Murphy's Law states: "A man with a wrist watch always knows the time; a
man with two can never be sure."

I would suggest to make the PPS a 'noselect' peer and have the palisade
clock to a fudge time of 0, with a maxpoll of 6. Start ntpd and keep it
running for an hour or so, longer if can. Monitor the offset difference
between PPS and palisade; this is what you need to fudge away finally on
your palisade clock.

Then adjust the fudge time on the palisade driver, enable the PPS clock
again and restart ntpd. If you can get both clocks close enough to
survive the internal selection algorithm as a pair, you should be fine.

And check the comments on 'tos minsane' and/or 'tos minclock' in the
description of the ATOM driver in case you haven't yet.

This nearly worked for me with NMEA/ATOM; but because the GPS18x has a
terrible jitter of up to 20msec (serial line vs. PPS), I needed to
modify the NMEA driver finally. Since your jitter numbers seem to be a
lot better, there is hope.





More information about the questions mailing list