[ntp:questions] Re: [Bug 177] Clock stepping messes up frequency. (fwd)
roy at suespammers.org
Thu Oct 23 03:55:06 UTC 2003
"David L. Mills" wrote in message news:<3F96B513.74985B4D at udel.edu>...
> I am cross-posting this and an earlier message from bugzilla, since the
> "bug" is unresolved and the issue should be considered by the general
> user population.
> The issue has to do with recovery following a holdover period when the
> local clock driver disciplines the clock in the absence of external
> synchronization sources. The report is that, if the local clock has
> drifted outside the step threshold, the correction introduces an
> unwanted frequency surge. The frequency surge is a secondary effect
> resulting from an engineered response to a possibly corrupted frequency
> file. However, this is not the issue I am concerned about. Rather, I'm
> concerned about how the offset could have drifted greater than the step
> threshold in the first place.
> In general, the clock discipline maintains the frequency within one
> part-per-million (PPM) once the algorithm has settled down in a few
> hours after restart. Therefore, the local clock should be able to
> free-run for periods up to 36 hours without the offset exceeding the
> default step threshold of 125 ms. One report suggests that, when the
> sources are once again reachable via dial-up connection, a residual
> offset greater than the step threshold is created. I can't confirm this
> here, but there may be something I have missed. Note that similar
> scenarios happen all the time with the HF radio drivers when the signals
> are lost for a day or more and the residual correction when the signals
> are again found is only a few milliseconds.
> So, I am looking for reports that, following an extended outage and
> whether or not the local clock driver is used, the local clock has
> drifted greater than the step interval. I can't confirm this here,
> either in simulation or practice, unless something serious is broken in
> the harware or operating system. One possibility to consider is that
> sleep/suspend mode could have torqued the clock during the holdover
> interval. Other reports relating to this issue would be much appreciated
This may not be quite what you are looking for, but on my home NTP
server I can frequently see times when the local clock drifts more
than the step interval. Here's a quick sample from an old loopstats
52850 54400.148 -0.033933043 -119.678411 0.020886736 0.449823 14
52850 70785.151 -0.000764412 -119.426726 0.025568197 0.409380 14
52851 768.147 -0.054226675 -119.835474 0.034450925 0.409222 15
52851 17151.152 -0.027192308 -119.630382 0.034108466 0.368934 15
52851 49918.149 0.038115401 -119.381501 0.052961734 0.342885 15
52851 82685.150 -0.051950561 -119.724717 0.069032111 0.342968 16
52852 29055.149 0.009548464 -119.490629 0.067511066 0.319248 16
52853 70790.149 -0.303959474 -121.936574 0.161662943 1.253835 4
52853 73715.141 -0.166563500 -178.880252 0.140650012 28.492537 4
52853 74620.152 -0.021400267 -129.140914 0.019528909 35.033826 4
52853 74684.148 -0.015529604 -129.200154 0.017238256 30.340198 6
52853 74748.147 -0.015106461 -129.257781 0.015280701 26.275398 6
I see this type of behavior anytime I set MAXPOLL to 16 or 17.
MINPOLL was set to the default of 6 and the step threshold was also
set to the default of 128 ms. This example was using the local clock
driver, but ntpd never lost contact with the synchronization sources
and never switched to use the local clock driver. Probably the only
unusual setting is that ntpd was started with the -x command line
option, because the operating system disallows setting the time
backwards. This system is currently running NTP 4.1.2, although I've
seen this problem on earlier versions as well.
I had set the MAXPOLL up to 17 in an attempt to reduce the load on the
NTP servers. But with that configuration, ntpd sends a whole lot of
packets at MINPOLL every time it exceeds the step threshold. MAXPOLL
of 15 seems to be more stable.
If this seems relevant, just let me know. I'm sure I can find more
examples and details in the various log files.
Have a great time,
The suespammers.org mail server is located in California. Please do
not send unsolicited bulk e-mail or unsolicited commercial e-mail to
my suespammers.org address or any of my other addresses. These are my
opinions, not necessarily my employer's.
More information about the questions