[ntp:questions] stepping and slewing

David Woolley david at djwhome.demon.co.uk
Tue May 15 06:27:36 UTC 2007

In article <slrnf4eihj.1em.serge.bets at laposte.net>,
Serge Bets <serge.bets at NOSPAM.laposte.invalid> wrote:

> Hello David,

> > The current ntpd -gq code does not set the kernel frequency from the
> > frequency file, but it can be set using ntptime -f.

> It would be the right thing for ntpd -gq to set the frequency by itself.
> And of course it's well designed, so it does it. :-)

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).

                 * Assume the kernel supports the ntp_adjtime() syscall.
                 * If that syscall works, initialize the kernel time
                 * variables. Otherwise, continue leaving no harm
                 * behind. While at it, ask to set nanosecond mode. If
                 * the kernel agrees, rejoice; othewise, it does only
                 * microseconds.
                if (mode_ntpdate)

If one goes back to one of the stable versions, 4.2.0, there is even a 
comment that has got lost, that explains this.  I think the code and
comment were deleted in error in your version.

                 * Call out the safety patrol. If ntpdate mode or if the
                 * step threshold has been changed by the -x option or
                 * tinker command, kernel discipline is unsafe, so don't
                 * do any of this stuff.
                if (mode_ntpdate || clock_max != CLOCK_MAX)

which causes 


to be skipped.

I still think that failing to account for the drift in some way  makes 
ntpd -qg less useful than it might be, although, on Linux, 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.  ntpdate cannot account for the drift.

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.

More information about the questions mailing list