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?
-----
Peer stats from yesterday:
peers.20060627
ident cnt mean rms max delay dist disp
==========================================================================
A.A.A.A 133 0.604 2.726 11.346 99.133 69.698 11.311
B.B.B.B 134 1.486 14.164 137.654 67.729 250.569 11.178
C.C.C.C 123 32.648 34.108 176.643 119.703 264.385 19.212
D.D.D.D 131 -2.643 67.035 731.930 0.486 22.607 11.261
E.E.E.E 132 -0.432 1.872 17.620 3.671 37.519 11.287
F.F.F.F 140 -2.113 1.226 4.530 0.998 938.963 39.071
I'm not sure overall this is any better - however, the tracking with the
peer F.F.F.F seems good - if it maintains track like this, I'll be
satisfied.
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
