From owner-svn-src-all@freebsd.org Fri Nov 24 15:56:48 2017 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CAF12DEABDC for ; Fri, 24 Nov 2017 15:56:48 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AABC379D70 for ; Fri, 24 Nov 2017 15:56:48 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 000f7915-d130-11e7-b1c3-712f93d8ba90 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 000f7915-d130-11e7-b1c3-712f93d8ba90; Fri, 24 Nov 2017 15:56:15 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id vAOFuebJ001241; Fri, 24 Nov 2017 08:56:40 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1511539000.94268.17.camel@freebsd.org> Subject: Re: svn commit: r326095 - head/usr.sbin/bsdinstall/scripts From: Ian Lepore To: Bruce Evans , Devin Teske Cc: rgrimes@freebsd.org, cem@freebsd.org, Emmanuel Vadot , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Date: Fri, 24 Nov 2017 08:56:40 -0700 In-Reply-To: <20171124201621.K980@besplex.bde.org> References: <201711231729.vANHTVmo092083@pdx.rh.CN85.dnsmgr.net> <20171124201621.K980@besplex.bde.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Nov 2017 15:56:48 -0000 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 . 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