Date: Fri, 24 Nov 2017 08:56:40 -0700 From: Ian Lepore <ian@freebsd.org> To: Bruce Evans <brde@optusnet.com.au>, Devin Teske <devin@shxd.cx> Cc: rgrimes@freebsd.org, cem@freebsd.org, Emmanuel Vadot <manu@bidouilliste.com>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r326095 - head/usr.sbin/bsdinstall/scripts Message-ID: <1511539000.94268.17.camel@freebsd.org> In-Reply-To: <20171124201621.K980@besplex.bde.org> References: <201711231729.vANHTVmo092083@pdx.rh.CN85.dnsmgr.net> <F94B65A7-D2AA-47FB-90C4-439DDFDD1AC7@shxd.cx> <20171124201621.K980@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2017-11-24 at 22:25 +1100, Bruce Evans wrote: > On Thu, 23 Nov 2017, Devin Teske wrote: > [...] > > ntpdate's man page claims this, but is wrong AFAIK. It says that the > functionality of ntpdate is now available in ntpd(8) using -q. However > ntpdate -q is far from having equivalent functionality. According to both > testing of the old version and its current man page, it does the same slow > syncing as normal ntpd startup, and just exits after this and doesn't > daemonize while doing this. With the old version, this step takes 35-40 > seconds starting with the time already synced to withing a few microseconds > (by a previous invocation of ntpd), while ntpdate syncs (perhaps not so > well) with a server half the world away in about 1 second. > Ahh, the good ol' days, when ntpdate was fast by default. Not anymore... unicorn# time ntpdate ntp.hippie.lan 24 Nov 15:21:31 ntpdate[734]: adjust time server [...] offset -0.000123 sec 0.013u 0.006s 0:06.13 0.1% 192+420k 0+0io 0pf+0w If you want the fast old sub-second behavior these days, you have to add -p1. Or, better yet, use sntp -r <server>. I'm not sure where you're coming up with numbers like "35 seconds" for ntpd to initially step the clock. The version we're currently distributing in base takes the same 6-7 seconds as ntpdate (assuming you've used 'iburst' in ntp.conf). That's true in the normal startup case, or when doing ntpd -qG to mimic ntpdate. If there is an ntpd.drift file, ntpd is essentially sync'd as soon as it steps. If there is not, it does a clock step, then does 300 seconds of frequency training during which the clock can drift pretty far off- time. It used to be possible to shorten the frequency training interval with the 'tinker stepout' command, but the ntpd folks decoupled that (always inapproriately overloaded) behavior between stepout interval and training interval. There is no longer any way to control the training interval at all, which IMO is a serious regression in ntpd (albeit noticed primarily by those of us who DO have an atomic clock and get a microsecond-accurate measurement of frequency drift in just 2 seconds). -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1511539000.94268.17.camel>