On Fri, 24 Nov 2017 15:36:22 -0700 Ian Lepore <i...@freebsd.org> wrote:
> On Fri, 2017-11-24 at 14:57 -0700, Warner Losh wrote: > > On Fri, Nov 24, 2017 at 2:14 PM, Rodney W. Grimes < > > free...@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > > > > > > > > > > > > > > > > > > We are not talking about removing ntpdate in this thread. > > > > Well, after Ian said that it was deprecated I ask if we should remove > > > > it to be honest. > > > And I think we have come to the agreement not to do that until the > > > official distribution does it as well, is that also correct? > > > > > I think we should do whatever Ian suggests. I did time things with atomic > > clocks and ntpd for about 8 years. He's done them for the same company I > > have and knows the current set of quirks better than anybody else in this > > thread. These days, it's generally better to use the freebsd ntp pool, like > > we have in ntp.conf, and in that scenario, an invocation of ntpd with the > > appropriate flags can give you almost identical behavior to ntpdate. The > > 'almost' here has a lot of quibbles that aren't relevant to the installer. > > And if you don't like the freebsd ntpd pool, then the installer should be > > writing an appropriate ntpd.conf file anyway, which has the host. It can > > all be done w/o using ntpdate (note: I didn't say remove it), and once > > that's in place, and we know there's something not unforeseen, we'll be > > ready if the ntpd folks ever make good on their threat to kill ntpdate. So > > remove the use of ntpdate here, but keep the utility around. > > > > tl;dr: Do what ever Ian says, if he doesn't do it himself. He's the expert > > with a decade of daily experience making products with ntpd work and > > shipping those to customers that have... somewhat diverse environments... > > > > Warner > > And yet, even with all that experience, I still neglected to consider > the case where ntpd_sync_on_start=YES can cause a time-step on a > running system if ntpd is restarted. (Not that that's a common > scenario, but it's still a Bad Thing for people with strict auditing > requirements or timing-critical software running.) > > What the ntpd developers currently say[1] is: > > The combination of ntpd and sntp now implements the functions of > ntpdate. As soon as a few remaining issues with sntp are resolved > the ntpdate program will be retired. > > If you look at what they link to for the "sntp issues"[2] it hasn't > been updated since 2011. So that leads me to the conclusions: > > - They have not yet provided a complete path away from ntpdate. > - They don't seem to be in a big hurry to eliminate ntpdate. > > All in all, I think what Manu committed is Good Enough For Now(tm). Thank you Ian for your time one this, I'll leave the tree as is right now and when there is anything new in the ntp world we will see what we will do. Case closed, mail thread closed too. Cheers, > [1] https://support.ntp.org/bin/view/Dev/DeprecatingNtpdate > [2] https://support.ntp.org/bin/view/Dev/SntpIssues > > -- Ian -- Emmanuel Vadot <m...@bidouilliste.com> <m...@freebsd.org> _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
