Re: [gpsd-dev] gpsd/ntpd

[Fred Wright]

It would be helpful in general if you'd provide more details.

On Thu, 28 Jul 2016, Henning Hakonsen wrote:

> I am currently trying to send a PPS signal to gpsd or ntpd. I am using
> u-blox gps receiver for gps clock, but the PPS signal is hardwired to
> GPIO. Our software can get the PPS signal and I would like to signal
> ntpd with this signal over shared memory much like gpsd is.

You don't specify what hardware platform, what OS, or what "our software"
is doing.

On Fri, 29 Jul 2016, Henning Hakonsen wrote:

> Thanks for the reply. I got my program to feed ntpd with the PPS signal.

You don't specify what you did.

> Now the only thing I am struggeling with is that I need to edit
> (linechange or something) ntp.conf file and restart ntp after boot.

If you mean that you need to edit ntp.conf on every boot, I would be very
surprised if that were actually true.

As far as restarting ntpd goes, that *may* be necessary, but it also may
be that you're just not sufficiently patient.

In order for ntpd to trust a PPS source, that source has to be in
reasonable agreement with at least one peer that's passed the intersection
tests and is flagged with the "prefer" keyword (note: examples that put
the "prefer" keyword on the PPS source itself are incorrect, albeit
harmless).  It's documented that the "reasonable agreement" test is false
if the difference is more than 128 ms.  What's not documented is that
discrepancies substantially less than 128 ms are sufficient to make it
significantly reluctant to trust the PPS.  And any PPS sample that fails
the "reasonable agreement" test is treated as "no response" and hence
shows up as a 0 bit in the reachability mask.  This may lead one to
falsely believe that the PPS source isn't working.

If the "prefer" source is a GPS NMEA stream, then the time lag in the NMEA
data can make ntpd take a long time (or forever) to trust the PPS.  One
can compensate somewhat by setting the "time1" fudge parameter to the mean
offset, though variability in the delay can still cause issues.

I've also seen cases where the loss of PPS data for too long causes it to
stop using PPS, apparently forever, but maybe just exceeding my patience
to the point where I restarted it.  This isn't limited to PPS; I've seen
it give up on network peers due to temporary network outages as well.
However, it may be that it's actually retrying, but with a really long
poll interval that isn't reflected in "ntpq -p".

Fred Wright