Karel Sandler wrote:
"Eino-Ville Talvala" <[EMAIL PROTECTED]> wrote:
Richard B. Gilbert wrote:
Charles Allen wrote:
I've lost track of who's said what, but at some point the original
poster mentioned that the offset gets worse during the day. To that I
ask a question: Are the server(s) more utilized during the day? If
so, would the gurus consider lost interrupts a possibility? Looks
like CENTos uses the 2.6.x kernels which some have mentioned had
trouble at least at some point in past.
I mainly mention this because this has come up as a possibility
several times over the previous months, and I was wondering if there
is a way to diagnose this problem, either with NTP tools, or using
OS tools.
Lost interrupts result in the local clock being slow with respect to the
server. The server will fall behind, step in the positive direction,
fall behind again, step, etc. This seems to be a problem mostly with
Linux systems that update the clock at frequencies greater than 100 Hz.
Some systems can set the update frequency to 250 or 1000 Hz and those
that do so have been known to exhibit this problem.
Where would I check on the clock update frequency?
You can cat /proc/interrupts and look for the update rate of int0. This is
the timer.
Karel Sandler
Ok, I did
cat /proc/interrupts; sleep 1; cat /proc/interrupts
and subtracted the first INT0 value from the second. Result = 1004.
Looks like it's running at a kHz. Kernel recompile, here I come...
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
