[ntp:questions] Sudden change in precision and jitter
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: 0.0.0.0 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).
>>> If you need/want more data just say so.
>> 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