[ntp:questions] Re: NTP stepping issue
david at djwhome.demon.co.uk
Wed Oct 20 20:44:23 UTC 2004
In article <4175335D.1020705 at motorola.com>,
Robert Rati <Robert.Rati at motorola.com> wrote:
> Let me test for understanding here, as I've gotten a number of replies
> to my question. While it is possible to configure the NTP client daemon
> to step regardless of the time difference (as I have done), it is not
I assume you meant *not* to step. You can set an arbitrary small
step threshold and have it step for very small differences, but it
won't behave at all well then; it will always be in error recovery.
Setting step to zero actually sets an infinite step threshold.
> recommended to do so. In my testing, I saw the client daemon slew to
> the correct time but then it continued slewing past the correct time.
> Is this a bug? Once it slews to the correct time provided by the
> servers, the client should remain synchronized, right?
Although there is always a risk of taking analogies too literally, ntpd
is behaving like a car suspension, when operating within normal parameters.
It has both spring like and damper like behaviour. It's job is to smooth
out the roughness in the road of time.
I seem to remember that car suspensions are designed to overshoot slightly
and Dr Mills has said that ntpd overshoots 7%.
If you set step to zero, you are asking for ntpd to behave like a car
suspension that doesn't bottom out when you drive it at thirty miles
an hour over a high curb. If you do this a lot in your car, you are
likely to void the warrantee! What it will be doing is trying to treat
the kerb as another random bump in the road, not a permanent change in
the road level.
ntpd does have rather different overload behaviour to a car suspension. If
you don't allow it to step, it won't allow the vertical velocity of the
car body to exceed a certain figure, which means it will take longer to
recover. If you allow it to step, rather than bottoming out, stepping
by the excess of the input step over the limit range, then coasting on
normally for the balance of the step, the mass of the body will, temporarily
be made infinite, and the relative speed of the ground measured. At the
end of this temporary period, the mass will be restored to normal and
the whole of the step, not just the excess over the limit applied, and
the body also accelerated to account for the new slope in the groud.
> Is there another way to solve the problem I laid out? (Once daemon is
> running, always step no matter what the time difference and eventually
> stay synchronized with the time servers)
Again I assume you mean always *slew*. If you mean always *step*, the
answer is to use a very simple SNTP, with no frequency correction, not
NTP. That will remove all the measured error at every poll, but the
ride with be rough.
There used to be code in ntpd that inhibited the actual step,
unconditionally, or only for backwards steps. I'm not quite clear how it
was supposed to work. I believe that it didn't actually work because the
flags that controlled it weren't actually connected to the user interface.
I presume it was felt that it wouldn't have worked sensibly, even if it
had been possible to turn it on.
Basically, you should not be driving over kerbs with ntpd, and real NTP
roads are really quite flat, with only extremely gentle changes in slope,
so you should only hit kerbs if there has been an earthquake.
More information about the questions