[ntp:questions] stepping and slewing
stenn at ntp.isc.org
Sat May 5 16:53:33 UTC 2007
>>> In article <T1178373802 at djwhome.demon.co.uk>, david at djwhome.demon.co.uk (David Woolley) writes:
David> In article <slrnf3ka5n.9rf.kostecke at stasis.kostecke.net>,
David> Steve Kostecke <kostecke at ntp.isc.org> wrote:
>> If your clock is less than 128ms off ntpd slews it. The slew will take
>> the same amount of time regardless of how ntpd is running (e.g. as a
>> daemon or via a cron-job w/ -gq).
David> My impression is that -gq will be faster. ntpdate is certainly
David> faster. That's because it will slew at the maximum rate all the
David> time, whereas the filtering in daemon mode ntpd will cause the rate
David> to ramp up slowly and to ramp down as it gets close to the nominal
I think you and Steve are talking about different things here.
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.
Ditto for a step.
Old ntpdate made an attempt to check with a bunch of servers and "choose
well". One of the reasons it was faster than ntpd -gq was because it was
broken. To paraphrase a famous CS guy, "Yes, your program is faster but
gives the wrong answer. My program gives the correct answer. If you are OK
with a wrong answer I can easily speed up my program."
David> This, I think is, the cause of one of the concerns that people have
David> about ntpd startup time. If the initial offset error, for a warm
David> start, is >~ 1 standard deviation, but < 128ms, an optimum approach
David> would be to slew at maximum rate until one either crosses the
David> estimated zero error, or, possibly about 1 SD from it, but ntpd
David> doesn't do this and has no carry over of the SD to allow it to do so.
If you want the time set once very quickly, use sntp.
If you want the time set once well, use 'ntpd -g'.
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.
David> It probably should not report a valid state until the initial slew
David> completes, which may make some people unhappy. I don't think
David> stability considerations arise during the inial slew, so a faster
David> slew, if supported, should be acceptable. If it does start reporting
David> valid times earlier, I think the extended period of high tolerance
David> estimates will be worse than any instability due to downstream
David> systems tracking a target that isn't apply the NTP loop filter.
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.
More information about the questions