[ntp:questions] Re: Getting good NTP tracking
Eino-Ville Talvala
quantumet at gmail.com
Wed Jun 28 20:36:15 UTC 2006
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.
More information about the questions
mailing list