[ntp:questions] Spike detection and clock runaway

A C agcarver+ntp at acarver.net
Thu Feb 23 23:09:53 UTC 2012


On 2/23/2012 15:01, Dave Hart wrote:
> On Thu, Feb 23, 2012 at 22:45, A C<agcarver+ntp at acarver.net>  wrote:
>> I will have to process and plot my peerstats and loopstats files but the
>> graph does seem to line up with approximately what I see on my system. The
>> difference in my case is that I'm using ATOM as the refclock (instead of
>> NME) and Internet servers as my other sources (gpsd is still not involved
>> here, it's in the config as noselect).
>
> The 2143 fix affects only the NMEA driver #20, but if it symptoms look
> similar to what you're seeing, the underlying cause may be the same.
> If switching to using NMEA temporarily for testing fixes it, you would
> know your PPS is not so trustworthy when the NMEA sentence indicates
> less than acceptable reception.  That sort of the obvious win in using
> the nmea driver's integrated PPS support -- you're not artificially
> disconnecting the GPS PPS signal from its NMEA context.

The only problem with NMEA in this case is that NMEA+PPS doesn't work on 
NetBSD/sparc due to some kind of issue with the serial port driver.  I 
don't know what the cause is and no one else seems to be able to figure 
it out, either, but it is just not possible to collect serial data from 
the port and attach the DCD pulses to the kernel discipline.  I tried 
that configuration the very first time I started working with this 
system and I never got a PPS flag on the NMEA clock.

But, I'm willing to try it again and see what happens.  I just need to 
flip the GPS over to NMEA mode.  I'll also look at the clockstats that 
were collected on the GPSD SHM clock to see what the signal levels were 
like.  GPSD is supposed to stop reporting if signals fade.


More information about the questions mailing list