[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 

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 

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 
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