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

Harlan Stenn stenn at ntp.org
Sat Oct 18 06:03:05 UTC 2008


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

In the old days, I recall (and I could be mistaken) that ntpd would report
its idea of the time that included any pending slew correction.  I believe
Dave fixed this, saying something like "now, ntpd does not lie about the
time".

If this is incorrect, please let me know and Ill be sure to document it.

But the bottom line is that if ntpd is reporting the time on the machine and
a slew is in progress, I think it is important *in the context of this
thread* to be able to have ntpd say "I think the time is X and any
correction I may be applying is under X".

If this is not needed because the pending correction is included in some
other statistic, that's fine too (and should be documented).

-- 
Harlan Stenn <stenn at ntp.org>
http://ntpforum.isc.org  - be a member!




More information about the questions mailing list