[EMAIL PROTECTED] wrote:
Richard B. Gilbert wrote:
[EMAIL PROTECTED] wrote:
Richard B. Gilbert wrote:
JCA wrote:
I have three Linux boxes, namely, A, B, and C, in my LAN. I use C
as the NTP server for my LAN. C, in turn, gets its synchronization
from some external NTP server.
Both A and B use the same (very simple) ntp.conf configuration file:
<snip>
This is what I consider a minimal NTP.CONF:
server x.x.x.x maxpoll 6
driftfile /etc/ntp.drift
enable auth
The "maxpoll 6" forces ntpd to update every 64 seconds.
"enable auth" prevents unauthorized people/systems
from messing with your system over the network.
That simple configuration is all you really need in almost
all cases.
- Mooron
Omit the "maxpoll 6". ntpd will adjust its poll interval within the
limits of the default values of MINPOLL and MAXPOLL to the currently
optimal value. Tampering with the values of MINPOLL and MAXPOLL will
generally result in sub optimal performance. Typical behavior is for
ntpd to start polling at 64 second intervals (MINPOLL) and gradually
increase the polling interval. The polling interval will sometimes
increase to MAXPOLL (2^10 or 1024 seconds) if conditions are ideal.
Translating the math I don't really follow into English, the shorter
poll intervals let ntpd correct large errors quickly and the long
intervals allow ntpd to correct small errors accurately.
I don't follow it either. NTPD appears to use something like a PID
control algorithm with some filtering and clustering of the sample
data. How NTPD could become more accurate with less data
is something I don't understand. I doubt anyone can give a real
explanation. Probably because it just isn't so.
Think before you write! If your clock frequency is off by 50 parts per
billion (drifts about 430 milliseconds per day) do you think it would be
easier to measure that error using a 64 second poll interval or a 1024
second poll interval. It seems obvious to me that the latter is the
proper interval to use in this case.
I have noticed that with bad clock hardware, such as a SUN Sparc,
it does a poor job of controlling the poll interval.
Why do you say that SUN Sparc clocks are bad? Some may be, but I have
four Sun SPARC systems in my home that are quite good; their native
frequency errors are in the 10 to 15 parts per million range.
A polling interval that remains at 64 seconds is usually indicative of
some sort of a problem but not necessarily a bad local clock; excessive
network jitter could also account for it.
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
