[ntp:questions] Client taking a long time to sync after clock changed
mayer at ntp.isc.org
Fri Aug 24 02:42:33 UTC 2007
Merit Wilkinson wrote:
> Hello all,
> We have a small isolated NTP subnet with two stratum 1 servers. As
> part of a test we reset the clock on one workstation backwards two
What was the point of this test? There are only two ways that a clock
can ever get reset this way:
1) some deliberately changed the clock;
2) you have hardware problems.
In both of these cases you should not expect ntp to fix the problem
since it's not something that will happen on it's own without ntp
preventing the situation in the first place and ntp has plenty of
defenses against believing any specific server.
ntpq immediately showed the offset (and claimed it was still
> synchronized to one of the servers) but it took about 14 minutes until
> it was suddenly corrected with one step.
> We're using ntp 4.1 built for win32. Here is the clients ntp.conf:
Upgrade. This is positively ancient.
> disable auth
> tinker panic 0
> server sn-a maxpoll 4 minpoll 4 burst
> server sn-b maxpoll 4 minpoll 4 burst
People who touch minpoll and maxpoll and use burst need to really
understand ntp very well. The default values were carefully chosen to
provide the best results over a long time period. We'd love to require
that people who touch these values have passed one of Dave Mill's
graduate courses with an A grade...
> I added the maxpoll and burst options in an attempt to get this time
> down. It was similar before I changed it.
Don't. Use only iburst on the line.
> Does this seem normal? Is there some way I can reduce this time?
> Note, I realize this isn't a particularly valid test, hopefully no one
> is going around changing the system time (or has permission to do so)
> but it got written into the test procedures...
That means that the person who wrote the test procedures doesn't
understand either NTP or QA and what circumstances are valid to test.
NTP cannot fix people's wandering fingers...
More information about the questions