[ntp:questions] Interesting PPS/GPS interaction discovery
A C
agcarver+ntp at acarver.net
Sun Sep 4 20:52:51 UTC 2011
I decided to try something slightly different with the PPS/GPS
configuration in ntpd to see if I could figure out what's going on with
the configuration and why they don't work together.
What I've done is use the internal PPS refclock (22) and the shared
memory refclock (28). The shared memory data is coming from gpsd. I
did this because I can turn on and off serial port access whenever I
want for each component (PPS or GPS). I don't know how to do this
directly with ntpd (to shut off the NMEA refclock, for example, and
leave the PPS running). It was easier to simulate the NMEA refclock via
the SHM and let gpsd handle the serial port access for the NMEA data.
The PPS data is still coming from the same physical port.
In this case, /dev/gps1 points to /dev/dtyb and /dev/pps1 also points to
/dev/dtyb.
Here's what I've discovered given that both of the mentioned reference
clocks are enabled in the configuration at all times. I temporarily
reduced the minpoll on the servers to 4 so that PPS would be enabled
sooner (after the reach on the servers reaches 017 PPS turns on and
starts showing reachable under my original config of PPS only without
NMEA or SHM).
First condition: start ntpd without gpsd running.
Under this condition, once all the servers have been reached four
consecutive times, PPS is enabled and it's reach counter begins to
increment. The shared memory refclock never counts reaches because no
data is there.
Second condition: start gpsd first then start ntpd
Under this condition, ntpd does see the shared memory data and the reach
counter starts incrementing. However, after allowing the reach counters
to show the full eight cycles (377), PPS is still dead with a reach of zero.
Third condition: a continuation of the second condition, namely gpsd
started first and then ntpd started. However now kill gpsd leaving ntpd
running.
Under this condition, the PPS immediately begins counting the reach
counter. The shared memory refclock stops counting.
Fourth condition: a continuation of the third condition, namely
restarting gpsd after the PPS clock shows being reached.
Killing gpsd allowed the PPS clock to be reached. Interestingly,
restarting gpsd after PPS is showing reachable results in BOTH PPS and
SHM working and reachable.
Fifth condition: start ntpd first then start gpsd immediately.
Under this condition, the shared memory is available as before but,
again like the second condition, the PPS is never reached even after all
other servers show a reach of 377. Killing gpsd after this allows the
PPS to be reached.
Sixth condition: start ntpd, wait for PPS to be reachable, then start gpsd.
Much like the fourth condition, as long as the PPS is already reachable
when the serial port is opened for reading the NMEA data, they both
coexist peacefully.
This correlates with my problems running the NMEA refclock alongside the
PPS refclock (leaving out gpsd). Specifically, the NMEA refclock opens
the serial port first and locks out the PPS refclock. But if the PPS
refclock opens the port first, then the serial port still remains
available for opening to read data.
What would be useful is a way to instruct ntpd to actually open the PPS
port immediately even if the data is discarded while the rest of the
system settles down. Then it can open the GPS port once the PPS port
has opened.
Currently it appears to open the PPS port only when it is ready to
accept PPS data but the GPS port opens right away at startup. Therefore
the NMEA refclock locks out the port and the PPS refclock is never able
to open the port. If the order were switched it looks like everything
would work fine.
More information about the questions
mailing list