[ntp:questions] stepping and slewing
david at djwhome.demon.co.uk
Sat May 5 19:36:31 UTC 2007
In article <ywn94pmrjjoy.fsf at ntp1.isc.org>,
Harlan Stenn <stenn at ntp.isc.org> wrote:
> Assuming the OS plays by the rules, there is no difference in how long it
> will take to slew a difference of X regardless of the choice of ntpd -gq,
> ntpdate, sntp, whatever.
You have to qualify this by:
1) as long as X is the same;
2) as long as it is instructed to slew at the maximum rate.
If the daemon is using the user space time discipline code, it
instructs the kernel to slew by (for NTP v3) no more than 2ms at a time,
and only in exceptional circumstances does it request the full 2ms. I think
the current ntpd uses a one second update, so slews by no more than
500 micrososeconds at a time. Averaged over the update interval, the
slew rate is likely to be a lot less than 0.5ms/s.
If the kernel time discipline is in use, the kernel is generally requested
to slew at less than 0.5ms/s, except if it starts a very long way from the
target, or has been slewing for some time and not cleared the phase error.
More samples will typically arrive before the initial offset has been
There is no slewing state in ntpd for initial "errors" less than 128ms, it
is in the normal discipline mode. Actually, there is no "slewing" state
> Ditto for a step.
Steps are instantaneous, although the daemon will sometimes take about
quarter of an hour to confirm the need for them.
> If you want the time set well "reasonably quickly" and stay "correct", set
> things up properly, run 'ntpd -g' and have a known-good drift file. Your
> ntpd will be in state 4 in about 11 seconds.
In addition, you need to ensure that the initial offset is > 128ms,
otherwise there is no step and you have to wait the full loop time
constant at its fastest setting.
> I am hazy on this one. I *think* ntpd will DTRT thing here - it either
> knows how to report the correct time during a slew period or it reports that
> it is unsync'd and not ready to offer correct time.
As I remember it, ntpd will start reporting an OK state as soon has enough
upstream samples, which I think is the same condition for starting the
slew. If the initial offset is 127ms, it will be on one side of the
"correct" time, for the full loop time constant. There is no distinct
Checking the 4.2.0 code, there is a slight special case for the very
first sample, in that no permanent adjustment is made to the frequency,
but, from the second sample, the full normal state handling is in
effect, even though the phase error may still be in the 120ms range.
More information about the questions