[EMAIL PROTECTED] wrote:
Richard B. Gilbert wrote:
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.
Is too! Nah-nah-nah!
Okay, now that I have that out of my system, let me explain:
NTP is interested in measuring two quantities about your system
clock, namely the phase and the frequency. The phase is what is
more commonly called the offset. If your clock does not run
fast or slow, the offset from actual time is a constant. Of course,
it is likely that your clock is a little fast or slow, so the
offset will grow or shrink with time. Since there is an error with
each offset calculation, what you want to do is take a bunch of
offset measurements, close together, so that the clock drift doesn't
have time change the offset. On the other hand, some of the types
of errors that creep in to these measurements are systematic and
transient, so you don't want the measurements to be too close
together; you want the transient errors to have time to transition.
Once you have decided what the offset is, you set the clock, and
now your clock has the correct time. But since it is running fast
or slow, it wont be correct for long. After a little while,
it will have a measurable offset again, so you will need to measure
the offset again and then adjust the clock. The sooner that you
do this, the smaller the offset will be when you do. So, for a
first cut, most people figure that the shorter the poll interval,
the more accurate the clock. And that is not incorrect.
However, NTP tries to do better. After the first time that it
adjusts the clock, it takes a timestamp. The next time it
adjusts the clock, it looks at what the offset was and how long
it has been since the last time it adjusted the clock, and
determines how fast or slow the clock was. So, this time,
instead of just setting the clock, it also adjusts the clock's
speed.
Now, when the time comes to adjust the clock, the offset will
be much smaller. Since the offset is much smaller, the error
in the measurement will tend to be more dominant, making it
more difficult to determine the actual offset. And likewise,
the frequency adjustments will be more difficult. Once the
offset and frequency adjustment calculations become so small
that they are smaller than the error, there is no point in
making further adjustments, because you will be just as
likely to move away from the correct values as you are to
be getting closer.
At this point, the only thing to do is wait a longer period between
measurements. This will allow the offset to increase enough to
be larger than the measurement errors, so that you will have
accurate adjustments to make. The longer the period, the larger
the offset will be when you make the correction, but the more
accurate the correction to the frequency will be, meaning the
smaller the offset for the same period the next time. By increasing
slowly, we can put an upper bound on the size of the offset at
each step.
Once the offset stays below 128ms, we stop stepping the clock.
There are two reasons for this. One, applications often react
poorly to clock stepping. Two, once we get to a very small offset
correction, it becomes difficult to accurately set the clock,
due to physical realities. We reach a point where it is better
to say "the clock is 100 microseconds behind" than to say
"the time is now 1:20:32.1234". We eventually reach the point
where the finest control is achieved by only adjusting the
frequency and not the offset at all.
So, given the above, you might think to go the other way from
your previous position, and say, set the poll interval to the
maximum, so we can figure out the frequency very accurately,
right from the start. The problem with that is that the
frequency is also not a constant amount too fast or slow. It
changes with time. This is called frequency wander. Just like
with offset, the more often you measure it, the less the effect
the wander will have. So, to recap, what we have is:
The farther the frequency is from the correct amount, the more
often you need to poll.
The smaller the offset at each poll, the less often you need
to poll.
The closer the frequency is to the correct amount, the less
often you need to poll.
The more the frequency wanders, the more often you need to
poll.
The greater the error in each offset measurement, the less
often you want to poll.
There is an algorithm for determining the optimal poll interval
given the frequency wander over time, and the jitter (error)
in the offset measurements. This is called the "Allan intercept",
after the late comic Fred Allen. No, wait, that can't be right.
Just a sec...
Sorry, the Allan intercept is named for the still-very-much-with-us,
Mr. David W. Allan, timekeeper extraordinaire.
So, there you have it. I hope that helps you to understand how
a longer poll interval can lead to a more accurate clock, and
why it is a good idea to let NTP decide what the best poll interval
actually is.
I have noticed that with bad clock hardware, such as a SUN Sparc,
it does a poor job of controlling the poll interval.
Them's fightin' words. There's good Sparc hardware and bad Sparc
hardware. There's good software and bad software. I hope you
aren't casting aspersions on the whole product line are you?
--
blu
Rose are #FF0000, Violets are #0000FF. All my base are belong to you.
----------------------------------------------------------------------
Brian Utterback - OP/N1 RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
