[ntp:questions] Sudden change in precision and jitter

A C agcarver+ntp at acarver.net
Sun Jun 2 22:26:40 UTC 2013


On 6/2/2013 13:33, David Woolley wrote:
> Harlan Stenn wrote:
>> A C writes:
>>> On 6/2/2013 02:24, David Woolley wrote:
>>>>> That would be interesting since I have a cron job restarting it at an
>>>>> odd hour away from any other cron jobs left.  I'll check and see if
>>>> Why are you restarting it?  ntpd works  best if left to run
>>>> continuously.
>>> I know it does...unless there is a bug (a compound bug between ntpd
>>> and the kernel) that causes ntpd to spin out of control every few
>>> weeks and forces me to restart it anyway.  By spin out of control I
>>> do mean that CPU usage goes to near 100% and ntpd stops disciplining
>>> the clock after it managed to force the clock to run at some insane
>>> rate (e.g. nominal PPM tick adjustment might be -78 and it ramps the
>>> tick to +350 PPM over a few minutes).  The end result is that the
>>> clock is very wrong, ntpd has totally stopped doing anything, but
>>> somehow it's caught in an infinite loop with maximum CPU usage
>>> meaning almost nothing else on the system is working right.
>>
>> It would be really great to run truss or something in this case, and
>> I would also hope that the GSoC project to upgrade NTP's loggingd and
>> debugging interface will help with this too.
>>
>> If you want to open a bug report on this that's fine too - we won't be
>> able to do much about it until we can repeat it or debug it, but it
>> might be useful information for the aforementioned GSoC project.
>
> I think this could be an already known NetBSD bug, see
> http://groups.google.com/group/comp.protocols.time.ntp/browse_thread/thread/dd92eaf7bdb1c1f3/4449c41fcd6a78bd

Possibly but there's some situation unique to ntpd that triggers the 
issues.  I kept going with that thread on the NetBSD list because the 
problem still showed up although with a longer period before the crash. 
  Various test programs were written and compiled to stress all of the 
floating point operators that ntpd might use but nothing ever happened, 
the system ran the test applications without fail.  That's why I said at 
the beginning of this particular thread that it's a combination bug, 
NetBSD on sparc plus something very peculiar to ntpd's operations trips 
it up.  Any other program never has an issue.



More information about the questions mailing list