[ntp:questions] stepping and slewing

Serge Bets serge.bets at NOSPAM.laposte.invalid
Tue May 15 23:30:19 UTC 2007

 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?


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

      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

> 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 point Bets arobase laposte point net

More information about the questions mailing list