Richard B. Gilbert wrote:
David Woolley wrote:
In article <[EMAIL PROTECTED]>,
Richard B. Gilbert <[EMAIL PROTECTED]> 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.
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
