[ntp:questions] Re: Drift handling....

Roman Mäder newsXXF.10.rmaeder at spamgourmet.com
Wed Jan 4 16:35:56 UTC 2006


David L. Mills wrote:

> Roman, and others,
> 
> You should tae a closer look at the code in ntp_loopfilter.c. It throws
> nothing away. The main tool for adaptation to unstable clock oscillators
> is to vary the time constant according to measured stability. You will
> note the response to observed frequency transients is to reduce the poll
>   interval and increase it when the transient subsides.

I am not concerned about response to unstable oscillators, but response to
sudden offset changes, due to causes external to ntpd. for example, one
of my servers that missed the leap second:

53736 12.250 -0.000257957 27.539499 0.001335174 0.001348 6
53736 915.986 0.000000000 -500.000000 0.027077495 553.713302 4
53736 1205.339 0.116974652 -499.553777 0.155550337 479.529838 6
53736 2168.334 0.000000000 -95.763792 0.227084448 461.761017 4
53736 2423.070 0.000000000 -95.763792 0.196824591 399.896771 6
53736 3069.263 0.000000000 185.642644 0.042492463 373.812074 4
...
53736 4429.382 -0.127968047 180.096602 0.026710882 28.070739 6
53736 5453.172 0.000000000 40.199238 0.030830475 74.052636 4

with the associated time steppings:
 1 Jan 01:03:27 ntpd[326]: synchronized to GENERIC(0), stratum=0
 1 Jan 01:15:15 ntpd[326]: time reset -1.000113 s
 1 Jan 01:15:15 ntpd[326]: frequency error -1080 PPM exceeds tolerance 500
PPM
 1 Jan 01:36:08 ntpd[326]: time reset +0.426068 s
 1 Jan 01:51:09 ntpd[326]: time reset +0.259175 s
 1 Jan 02:30:53 ntpd[326]: time reset -0.181635 s
(time is MET)

so it looks like ntpd stumbles when it suddenly notices a large offset it
cannot explain: it assumes that the frequency changed by a horrible amount.

or when it starts up:

53723 26953.191 0.000160889 4.994171 0.000002000 0.009279 6
..reboot..
53723 30097.210 -0.015328167 -40.855911 0.000137179 22.803956 4
53723 30161.197 -0.005654889 -41.046219 0.004743029 19.749034 6

even with ntpdate before ntpd or so it is rather difficult to ensure a
near-zero offset at boot time. In the example here the offset after bootup
was only 15ms, but ntpd yanked to long-term frequency of 4.99 to -40 and it
took it about 6 hours to slowly crawl back to the long-term value.

Roman




More information about the questions mailing list