[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


David,

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.

Dave

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
> past.
> 
> 
>>some other means within 68 years of the correct time, then start ntpd 
>>with -g.




More information about the questions mailing list