>>> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (David Woolley) writes:
David> In article <[EMAIL PROTECTED]>, David> Steve Kostecke <[EMAIL PROTECTED]> 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 David> time. 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. H _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
