[ntp:questions] Re: limitation on the client time/date at ntp startup
user at domain.invalid
user at domain.invalid
Mon Sep 11 18:56:49 UTC 2006
I have no idea whatsoever what you are talking about. If you need to
test whether the clock state machine correctly responds to large time
offsets, then my suggested scheme is exactly what you need. I have
tested every NTP version since 1982 in just that way, most recently to
confirm the clock is set correctly after the 2036 roll.
Using a large time step offset is not the way to test the PLL/FLL
functionality, and I did not intend the "classic" scheme to test it thar
way. The PLL/FLL loop is pseudo-linear and needs to be perturbed by a
small offset less than the step threshold (128 ms). Either that or
change the step threshold to something large and set the offset manually.
I test by setting the frequency to something large, like 500 PPM and
running the daemon (or kernel) for a few minutes in order to accumulate
a modest error, like 100 ms. Then, restore the original frequency file
or delete it, as required and restart the daemon. The intent is to
confirm the zero crossing as the loop converges (about one hour) and to
confirm the overshoot is modest (less than 6 percent). All this with a
64-s poll interval.
Your last comment is confusing. I have never criticized folks for doing
tests involving step or linear adjustments. What I have done is question
the wisdom of forcing the step threshold to very large values in order
to insure monotonic adjustments. The reasons for this are explained in
the white papers at the NTP project site.
David Woolley wrote:
> In article <ecl43a$n38$1 at scrotar.nss.udel.edu>,
> David L. Mills <mills at udel.edu> wrote:
>>Classic way to test NTP functionality is to stop ntpd, set the time by
> This isn't a classic way because it hasn't been an available option for
> long enough. It's also not classic because it is not what people actually
> do; what they actually do is to change the time on a running client (or,
> if they are using an undisciplined local clock on the server, change the
> time on a running server).
> As I pointed out, it is also not a valid test because it fails to demonstrate
> the phase locked loop in ntpd, which is the main part of ntpd, except in as
> much that someone more knowldedgeable than the sort of person for which this
> sort of demonstration is done, may be able to see the final convergence onto
> the correct time and frequency.
> If you really think it is a good test, I'm surprised that you have let so
> many regulars here criticise people for doing these step change tests in the
>>some other means within 68 years of the correct time, then start ntpd
More information about the questions