[ntp:questions] Re: NTP stepping issue
David L. Mills
mills at udel.edu
Wed Oct 13 04:02:33 UTC 2004
David,
No, I did intend a small nonzero value. If I understood the question
correctly, the wish was to step the clock no matter what the offset. I
wouldn't recommend that, but it can be done.
Dave
David Woolley wrote:
> In article <mailman.23.1097522252.72027.questions at lists.ntp.isc.org>,
> Robert Rati <Robert.Rati at motorola.com> wrote:
>
>
>>tinker panic 0
>
>
> I assume that this is a typo and you meant "tinker step 0".
> What I suspect this does is to disable the 128ms check completely,
> with the result that the normal control loop will continue to be
> used, but:
>
>
>>The system repeatedly threw out
>>
>>frequency error 512 PPM exceeds tolerance 500 PPM
>
>
> the phase error into the control loop will be very large, and the
> proportional part of the feedback function will demand a large frequency
> offset, which will hit the end stop. The integral part will try and
> increase the slew rate as well. ntpd uses a proportional-integral linear
> (to a first approximation) control loop, using phase error as the process
> variable and frequency as the controlled parameter - or at least this
> is what RFC 1305 effectively says, although I'm having trouble finding
> the integral part in the (oldish) version of the code I've got to hand.
>
>
>>but the time was slowing being slewed correctly. Unfortunately, it
>>never stopped being slewed. The client slowly slewed to the time
>>provided by the server, and then right past it. It went from being 30
>
>
> If it is behaving as described above, it will, being a basically linear
> system, try to do a damped oscillation. Presumably to improve convergence
> speed, the loop is underdamped, so will overshoot. In your case, it won't
> be completely linear, because of hitting the end stop.
>
>
>>seconds behind to being 2 minutes fast and counting. Is this an
>>expected behavior? It would seem to me that once the NTP daemon on the
>>client reached the time being served by the server, that the daemon
>>would stop slewing and be in sync.
>
>
> What you seem to want is a step mode that starts a slew, and
> continues the slew until enough time has passed to clear the error that
> existed at the start of the slew (or possibly until the sign of the
> error changes), then revert to the frequency just before it started the
> big correction.
>
>
>>Also, is the ntp daemon supposed to be able to handle a time difference
>>of 30 seconds without stepping (ie only slowly slewing to correct the
>>time difference)?
>
>
> Any large correction is an extreme error condition under which normal
> operation has broken down and there is a presumption that the world
> is falling to pieces. I think you can safely assume that it is not designed
> to to cope with phase errors that cause the frequency to hit the end stop,
> which, assuming an accurate crystal, means rather less than 1/2000th of
> the time to the first zero crossing (in the linear region, the slew will
> accelerate and then slow again). RFC 1305 suggests 39 minutes to the first
> zero crossing for a 100ms error. Assuming that behaviour is linear,
> 1/2000 of 39 minutes is just over a second, so I would suggest that it is
> probably undesirable to set the clock out by more than about half a second,
> and certainly no more than one second.
>
> Bigger errors will cause the maximum root distance to be exceeded if
> all the upstream servers are unbroken. You should be able to ignore
> the variations between different reference clocks. That means that
> the dynamic range is adequate for valid use. Obviously, if you don't have
> real reference clocks, you will be advertising false accuracy information
> about clocks that could move by more than this, but that isn't a scenario
> it is designed for.
>
>
>>In addition to that, can the ntp daemon handle the time being changed on
>>the local system (ie via the date command) while the daemon is running?
>
>
> There is no requirement to be able to support that, as it will never happen
> on a system that is capable of operating NTP properly. In practice, it will
> be perceived as a serious problem with the upstream time sources.
More information about the questions
mailing list