On Jul 17, 2011, at 1:57 PM, Harlan Stenn wrote: > Dave Hart wrote: >> After many years of deprecation while still shipping, ntpdate's days >> as a separate C program are numbered. I want to review alternatives >> and suggest next steps. >> >> First, though, a quick review of why ntpdate is deprecated and will be >> removed. ntpdate serves two primary purposes today: >> >> 1) A diagnostic tool, particularly to help troubleshoot connectivity >> problems such as those introduced by firewalls. In this role, 4.2.7's >> sntp provides equivalent capability, including the ability to send >> queries from the reserved NTP UDP port 123. >> >> 2) One-shot clock synchronization, such as before starting >> step-phobic daemons. In this role, there are a plethora of >> alternatives, which I will cover below. > > Just to be clear, there *used* to be some reasons to set the clock > before starting ntpd. In general, there is no need to do this anymore > and I have not heard any good reasons it should still be needed. > > If anybody knows of any *good* reasons to set the clock before starting > ntpd, please speak up.
ntpdate was used to get sub-second synchronization at the cost of about a second of delay in startup. ntpd would take a lot longer to do this, and would have problems with steps. Most daemons hate it when time jumps too much, so this was a good compromise. Does ntpd still dial in the frequency error before doing the phase shift that's patently obvious at startup? If so, then there's still a need for ntpdate. ntpd would also used to start asynchronously, meaning that it was a crap shoot if your daemons would see a a big time-step or not after they started. If these problems have been corrected completely, then maybe ntpdate can be killed. Otherwise, there's still a need for it. Warner _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
