[ntp:questions] Re: Getting good NTP tracking
Eino-Ville Talvala
quantumet at gmail.com
Tue Jun 27 17:44:55 UTC 2006
Richard B. Gilbert wrote:
> David Woolley wrote:
>> In article <jJqdnWKEcajxyT3ZnZ2dnUVZ_o-dnZ2d at comcast.com>,
>> Richard B. Gilbert <rgilbert88 at comcast.net> wrote:
>>
>>
>>> Look at your /etc/ntp.conf. In that file, look at the server
>>> statements. Do they include the keyword MINPOLL? Or MAXPOLL?
>>
>>
>> He included it in his original posting and it has been (over) quoted
>> several times since. He had no minpoll or maxpoll. It's really not
>> uncommon for the poll interval to stick at the maximum once the system
>> has stabilised.
>
> Sorry, I missed that, or thought he missed it. He didn't cut and paste
> it. His complaint seems to be that he's getting large offsets and that
> suggests to me that the system has NOT stabilized.
>
> Requoting the the numbers we're talking about:
> peers.20060620
> ident cnt mean rms max delay dist disp
> ==========================================================================
> <UNIVERSITY> 132 -4.089 90.922 986.193 4.340 939.038 30.380
>
> The University server seems to have been polled only 132 times in 24
> hours while the maximum offset is 986.193 milliseconds. I've used a few
> servers that looked that bad and the polling interval did not get very
> large. The picture suggests a network problem of some sort which I find
> a little surprising since the network he describes would seem to be a
> LAN or a small WAN (note the small value of delay).
>
> My NTP experience has been almost entirely with 10-base-T and 100-base-T
> switched full duplex technology. If he has 10-base-5 (thick coaxial
> cable) or 10-base-2 (thinwire) or even twisted pair with hubs instead of
> switches he could be getting enough phase noise from his network to
> force a long poll interval.
This is actually on GigE, at least in my building - I'd assume the
campus backbones are probably all GigE by now, certainly 100-base-T.
The departmental NTP server should be in the same building with me, at
least.
I could certainly simply have one machine use an undisciplined local
clock and point the other at it as the sole timing source, but when I
tried that earlier, I didn't have any better luck in maintaining good
tracking.
I haven't yet collected enough data to tell if disabling SELinux and
adding more servers will help - hopefully those will do the trick.
More information about the questions
mailing list