[ntp:questions] Interesting PPS/GPS interaction discovery

unruh unruh at wormhole.physics.ubc.ca
Sun Sep 4 22:29:51 UTC 2011


What kind of serial port do you have? Is it a legacy serial portwith
interrupt <9, or is it a serial card with a shared serial port? 

It sounds like the serial port driver is taking over the interrupt as
a non-shared interrupt and when the PPS driver comes in, it never gets
any signal from the serial port because the serial port driver is
servicing the interrupt and never passing it on.


On 2011-09-04, A C <agcarver+ntp at acarver.net> wrote:
> 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