[ntp:questions] ntpdate works, but ntpd doesn't (reach = 0)
martin.burnicki at meinberg.de
Fri Feb 13 11:14:11 UTC 2009
Richard B. Gilbert wrote:
> If you start with the -g option, the time is set initially and the error
> should be very small. Setting the frequency correction to the correct
> value is what can take a great deal of time. Restarting with -g and a
> valid drift file should allow ntpd to converge fairly quickly.
It depends what you mean by "very quickly".
Obviously this is faster if the initial time offset is above 128 ms which
lets the system time be stepped very close to the right time. If the
initial time is offset is below 128 ms then it may take quirte a long time
to compensate this tiny offset.
> What seems to take a great deal of time is a cold start.
Why Harlan don't want -g as default is not related to cold starts, which I
could eventually understand, but to restarts of ntpd, and I don't
understand where the problem is in this case.
> The obvious solution is to keep the machine running. Some people
> believe that, for whatever reason, it's not practical for them to do
> this. Clearly they need a different tool to set and discipline the
> clock. Chrony has been suggested. AFAIK, chrony runs only on Linux.
> Perhaps those who need a chrony like tool for other operating systems
> could sponsor ports to other operating systems of interest.
IMHO the decision to reboot (if required), or not, should be left up to the
operator. If ntpd would converge faster after startup (which would clearly
be possible) this would not have to result in worse behaviour if you let
your machine run continuously.
More information about the questions