[ntp:questions] Sudden change in precision and jitter

A C agcarver+ntp at acarver.net
Mon Aug 12 04:35:46 UTC 2013

On 8/10/2013 14:02, A C wrote:
> On 8/10/2013 11:52, David Lord wrote:
>> A C wrote:
>>> Old thread but new data coming up.  After running for a nice while
>>> ntpd finally spun out of control as I've described before.  It swung
>>> the clock around and then finally stopped doing anything.  When I
>>> finally restarted the clock was over 90 seconds off (the appropriate
>>> log entry here):
>>> Aug 10 16:23:02 sunipx2 ntpd[23542]: c41c 0c clock_step
>>> -95.543901 s
>>> I have all stats files turned on so below is a link to a combined file
>>> from the configuration, main log, peers (both filtered for ATOM and
>>> SHM and an unfiltered version), clockstats, loopstats, sysstats, and
>>> rawstats for the time period when the system spun out.
>>> Perhaps any of you can spot something that I'm overlooking in these
>>> files.  Everything works great and then it collapses very quickly
>>> (within one or two polling cycles at most).
>>> http://acarver.net/ntpd/combinedlogs20130810.txt
>>> If you need/want more data just say so.
>> Hi
>> what hit me was your "tos minsane 1"
>> Both my GPS and MSF sources I'm told cannot be blacked out by
>> weather conditions but I also see flying saucers.
> In theory my GPS shouldn't get knocked out either.  I've very rarely
> seen it misbehave and certainly not on the order of once every few weeks
> (more like once a year).  I tossed in minsane 1 in the event that my
> connections to the remotes failed so that it would continue with the
> local GPS data (PPS from ATOM and time from SHM).  I think when I first
> started tinkering with it I did have some network problems like that.  I
> know the mindist has helped during flakiness of the whole system when
> things might just teeter on the edge of the default mindist, especially
> the SHM data which moves around by many tens of milliseconds (+/- 70ms
> is fairly common).
> The billboard on the system right now after having restarted it a few
> hours ago looks fairly normal:

I just took a look at two days worth of loop files (plotting with 
ntpdloopwatch) which shows that the clock offset is reasonable (-0.048 
ms to +0.027 ms) over that period.  So initially it seems that the 
system can keep fairly reasonable time which makes the sudden upsets 
even more peculiar.


More information about the questions mailing list