[ntp:questions] "ntpd -q" is slow compared to ntpdate

David Woolley david at ex.djwhome.demon.co.uk.invalid
Sat Oct 18 09:23:35 UTC 2008


Harlan Stenn wrote:
>>>> In article <48f7b877$0$501$5a6aecb4 at news.aaisp.net.uk>, David Woolley <david at ex.djwhome.demon.co.uk.invalid> writes:
> 
>> * any slew adjustment in-process is under X (where X is configurable)
> 
> David> I'm not sure that is a meaningful concept for ntpd.  If ntpd does
> David> have an explicit concept of slewing, it would only be when correcting
> David> an error greater than 128ms, with stepping forbidden.  If it does
> David> have such a state, I don't think being in the state would be enough
> David> to disqualify the time.
> 
> I don't see your point.
> 
> Regardless of the original reason, a given instance of ntpd may be applying
> a slew that will take "noticeable time" to complete.

NTPv4 can do one of two things to the local clock:

- step the time (and possibly the frequency);
- apply the normal phase lock loop algorithm.

When doing the latter, it has no idea whether a large offset is a 
statistical fluke or a real error.  (There is a limit on the frequency 
correction applied, and it could be argued, that exceeding that puts the 
time in question.)

There is no concept of a distinct slewing state.

NTPv3 had a third option, a sub class of stepping, in which the time 
seen by clients stepped, but the time seen by the system on which it was 
running was slewed at 500ppm. The option that enabled that mode, simply 
sets the value of offset which will trigger a step very high (10 
minutes, I think) on NTPv4.

NTPv4 does ignore large offsets for about 15 minutes, before initiating 
a step (that's in addition to the delay imposed by the best of 8 
filter).  However, the presumption is that the clock is right and there 
is a temporary disturbance in the measurements.




More information about the questions mailing list