[ntp:questions] Spike detection and clock runaway

A C agcarver+ntp at acarver.net
Thu Feb 23 22:45:49 UTC 2012

On 2/23/2012 14:34, Dave Hart wrote:
> On Thu, Feb 23, 2012 at 21:14, A C<agcarver+ntp at acarver.net>  wrote:
>> I had ntpd running ok for the past six days with what appeared to be no more
>> problems.  The libc issues were not present (ntpq was polling regularly with
>> no lockups of ntpd), PPS seemed to be working with kernel discipline enabled
>> (though I have an outstanding question about PPS and the PPM adjustments).
>>   It was giving me offsets of only +/-5 ms or less.
>> However, very suddenly it went off track and I don't understand exactly what
>> happened.  The log file is available at http://acarver.net/ntpd/
> Please take a look at the graphs attached to http://bugs.ntp.org/2143
> and see if it looks like the same sort of problem.  Hal Murray
> identified a regression in refclock_nmea.c 4.2.7p204 affecting GPSes
> reporting poor signal/lost reception.  Juergen Perlinger fixed this in
> 4.2.7p258.
> It may be a different issue, but in your shoes I'd still want p258 to
> avoid confusion from fixed bugs.

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).  I do have a 
clockstats on the GPSD clock so I can tell if there's a signal fade 
(number of reported samples will shift down from 128) but since I'm 
using PPS, it should be slightly more immune to signal loss as long as 
one satellite is visible and locked.

Once I process the graphs I'll put them up for review.

More information about the questions mailing list