[ntp:questions] stepping and slewing

mills at udel.edu mills at udel.edu
Wed May 16 14:21:17 UTC 2007


Serge,

Whether or not you observe past version of ntpd -gq to set the 
frequency, the current version does not. Whether or not you find this 
unacceptable, your objection is noted, but the code continues as 
current. There are very numerous weeds in the code to handle many 
different wrinkles in various configurations. These wrinkles might be 
changed, they might not. Should you require accurate frequency and time 
discipline, run the daemon. Should you require the ntpdate 
functionality, what you see is what you get.

Dave

Serge Bets wrote:
>  On Tuesday, May 15, 2007 at 7:27:36 +0100, David Woolley wrote:
> 
> 
>>You are using an unstable development version. The current unstable
>>development version (4.2.5p32) doesn't set the kernel frequency (even
>>if there is a kernel frequency that can be set).
> 
> 
> I am unable to understand the code, there is too much special cases for
> me to follow. But I get the same logs with 4.2.5p20, 4.2.5p33, and even
> 4.2.4 stable: ntpd -gq sets my kernel's frequency from the driftfile.
> 
> On one side I double-checked everything and it's 100% sure; on the other
> side Dr. Mills and you say it doesn't happen. Fine: There is a mystery
> to solve! Note I'm very happy to get a good freq, it seems to be a good
> thing from my POV.
> 
> 
> 
>>immediately following it by running ntpd in daemon mode should work
>>reasonably well, as the PLL frequency adjustment is applied on top of
>>the adjtime one and, although I'm not completely convinced of this,
>>the apparent clock frequency error that results from this shouldn't be
>>too harmful in a startup context.
> 
> 
> I experimented just that yesterday: the still running adjtime() slew
> seemed to perturbate the first minutes of the daemon behaviour. In a way
> I considered unacceptable. So between ntpd -gq and the daemon,
> I inserted a sleeper in awk. You pipe ntpd -gq output to the script, and
> if there is a slew, the script sleeps until the end of the 500 PPM rate
> slew. Then you can safely start ntpd itself, in the best conditions (an
> already good phase).
> 
> In practice this typically takes:
> 
>  - ntpd -gq	7 seconds
>  - slew+sleep	between 0 and 256 seconds
>  - ntpd		7 seconds to resync to iburst servers
> 
> In the worst case (127.9 ms of offset at startup) this seems a long
> delay, but is in fact a good compromise:
> 
>  - Reach the good phase at the maximum rate.
>  - Avoid steps as much as possible.
>  - Start serving time only once at good phase.
>  - No risk of unstable daemon startup (as can happen when there are some
> tens of millisecs of initial offset).
> 
> In some way, integration of a gq-like fast initial slew in the daemon
> code itself would only gain 7 seconds, right?
> 
> 
> ------------------------------------------------------------------------
> #!/bin/sh
> 
> function slew_sleeping() {
>   awk '
>     {print}		# tee to stdout
> 
>     /^ntpd: time slew .*s$/ {
>       sleep = $4 * 2000
>       if (sleep < 0)
> 	sleep = -sleep
>       sleep = int(sleep + 0.999999)	# rounded by excess
>     }
> 
>     END{
>       if (sleep) {
> 	printf "wait for the end of time slew, sleeping %d seconds\n", sleep
> 	system("sleep " sleep)
>       }
>     }
>   '
> }
> 
> # echo "ntpd: time slew -0.003000s" | slew_sleeping ; exit
> 
> ntpd -gq | slew_sleeping
> ntpd
> ------------------------------------------------------------------------
> 
> 
> 
>>ntpdate cannot account for the drift.
> 
> 
> Not alone, but with help from ntptime -f.
> 
> 
> 
>>At the moment, the best way of getting a fast start is to deliberately
>>set the clock more than 128ms off, and then start the daemon with no
>>ntpdate or ntpd -qg step.
> 
> 
> Does iburst act after a time reset?
> 
> 
> Serge.




More information about the questions mailing list