On 2008-02-09, Tom Smith <[EMAIL PROTECTED]> wrote: > He means be done with it, including hard-setting the clock, within a > second. The accuracy expected, based on "ntpdate -b" as the benchmark > you are trying to replace, is within a small number of milliseconds of > the specified servers. > > Sorry, "ntpd -q" doesn't meet the requirements.
You need to be realistic about your requirements. In the case of systems which run time sensitive services, or are rarely rebooted, an ~11 second pause, which is _is_ about the amount of time it takes for 'ntpq -gq' to do a quick sanity check on your configured time servers and set the clock, is not unreasonable. In the case of systems which do not run time critical services there is no reason why ntpd can not be started with -g and be allowed to set the clock as the boot progresses. In most cases the clock will be set before, or very shortly after, the boot sequence is completed. The big issue in the "ntpdate vs ntpd -gq" debate is the fact that the former may be used over unprivileged ports while the latter can not. This gives ntpdate the advantage in situtations where a firewall is blocking port 123/UDP. That's what you should be complaining about, not some trivial 11 second delay. -- Steve Kostecke <[EMAIL PROTECTED]> NTP Public Services Project - http://support.ntp.org/ _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
