On 11/05/12 11:56, Mark Rogers wrote:
[] Having looked further into this, I'm not sure that ntp is the culprit: it looks like ntp is running for "a while" then dying (signal 15) to be replaced by another ntp process, where "a while" is anything from a minute to several minutes. That explains why the clock "jumps" forward during the runtime of each ntp process (it's not jumping forward 15 mins, it's just running for 15 mins). But it doesn't explain the jumps backwards.
I note that there's nothing in the log to suggest that ntp is actually setting the clock either.
Is there anything else in the log that's getting a signal 15 at the same time as ntp dying? I can understand the log times jumping by 15 minutes as you say, that's just when separate ntp processes start.
The time jumping backwards, I would guess is because NTP *is* adjusting the clock, but, if NTP is running correctly, I'd have thought it would adjust the clock gradually, having noted the drift between the h/w clock and the internet time servers, rather than jumping.
Ideas: log ntp to a separate log file. Increase the debug-log level. Investigate ntpq -p as per http://perdues.com/doc/ntp.html
Any of this help? http://linux.die.net/man/8/ntpd
AFAICS, the iburst setting just speeds up the time in which the clock is initially set, I dunno if it makes things more reliable.
Hope this helps in some way!
Steve