Date: Sat, 25 Nov 2017 22:09:06 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Ian Lepore <ian@freebsd.org> Cc: Bruce Evans <brde@optusnet.com.au>, Devin Teske <devin@shxd.cx>, 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: <20171125201623.J1236@besplex.bde.org> In-Reply-To: <1511539000.94268.17.camel@freebsd.org> References: <201711231729.vANHTVmo092083@pdx.rh.CN85.dnsmgr.net> <F94B65A7-D2AA-47FB-90C4-439DDFDD1AC7@shxd.cx> <20171124201621.K980@besplex.bde.org> <1511539000.94268.17.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 24 Nov 2017, Ian Lepore wrote: > 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.=A0 It says that the >> functionality of ntpdate is now available in ntpd(8) using -q.=A0 Howeve= r >> ntpdate -q is far from having equivalent functionality.=A0 According to = both >> testing of the old version and its current man page, it does the same sl= ow >> syncing as normal ntpd startup, and just exits after this and doesn't >> daemonize while doing this.=A0 With the old version, this step takes 35-= 40 >> seconds starting with the time already synced to withing a few microseco= nds >> (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. =A0Not > anymore... > > unicorn# time ntpdate ntp.hippie.lan > 24 Nov 15:21:31 ntpdate[734]: adjust time server [...] offset -0.000123 s= ec > 0.013u 0.006s 0:06.13 0.1%=A0=A0=A0=A0=A0=A0192+420k 0+0io 0pf+0w > > If you want the fast old sub-second behavior these days, you have to > add -p1. =A0Or, better yet, use sntp -r <server>. The default of -p4 hasn't changed, but its speed has. I get the following times for ntpdate -q -pN: - old ntpdate -p1 0.31 seconds (my system -> US server ping latency 18= 0ms) - -p2 0.52 - -p3 0.83 - -p4 0.95 (default for -p) - new ntpdate -p1 0.37 seconds (freefall -> same US server) - -p2 2.39 - -p3 4.36 - -p4 6.36 (default) - old ntpdate -p8 0.10 (max for -p) (my system -> localhost ping lat 0.014 = ms) - new ntpdate -p8 fail (freefall -> localhost ping lat 0.060 m= s) - old ntpdate -p8 0.10 (my LAN -> my system ping lat 0.120 ms) - new ntpdate -pN same as US server (freefall -> freebsd server ping lat 80= ms) - old ntpdate -p8 0.24 (my system -> ISP server ping lat 12 ms= ) This shows that old ntpdate -pN takes approximately the ping latency times = N. New ntpdate takes that for N =3D 1; otherwise it takes almost 2 seconds for each increment of N. ktrace shows many sleeps of 100 msec between sendto/recvfrom pairs. > I'm not sure where you're coming up with numbers like "35 seconds" for > ntpd to initially step the clock. =A0The version we're currently > distributing in base takes the same 6-7 seconds as ntpdate (assuming > you've used 'iburst' in ntp.conf). =A0That's true in the normal startup > case, or when doing ntpd -qG to mimic ntpdate. This is for old ntpd [-q] with iburst maxpoll 6, to the ISP server. To the LAN server, ntpd -q takes the same 35 seconds. Normal startup with ntpd -N high takes about the same time. The examples in /etc/defaults/rc.conf don't give a hint about the -p flag for ntpdate or the -N flag for ntpd. Low -p values are probably good enough for ntpdate before ntpd. > If there is an ntpd.drift file, ntpd is essentially sync'd as soon as > it steps. If the drift file is correct. I do have a correct drift file, and the above times are with it. With a correct driftfile and ntpdate before ntpd, ntpd is essentially synced as soon as it starts :-). When calibrating it manually, I verify this by killing it soon after it starts and observing drift using ntpdate -q. > 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. =A0It 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. =A0There 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). Is there any use for ntp as a client if you have an atomic clock? Just to validate both it and ntpd? Bruce From owner-svn-src-all@freebsd.org Sat Nov 25 14:47:26 2017 Return-Path: <owner-svn-src-all@freebsd.org> 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 319B8DE7456; Sat, 25 Nov 2017 14:47:26 +0000 (UTC) (envelope-from kib@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (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 F00603162; Sat, 25 Nov 2017 14:47:25 +0000 (UTC) (envelope-from kib@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id vAPElP0l068070; Sat, 25 Nov 2017 14:47:25 GMT (envelope-from kib@FreeBSD.org) Received: (from kib@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id vAPElPnd068069; Sat, 25 Nov 2017 14:47:25 GMT (envelope-from kib@FreeBSD.org) Message-Id: <201711251447.vAPElPnd068069@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: kib set sender to kib@FreeBSD.org using -f From: Konstantin Belousov <kib@FreeBSD.org> Date: Sat, 25 Nov 2017 14:47:25 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-11@freebsd.org Subject: svn commit: r326188 - stable/11/sys/vm X-SVN-Group: stable-11 X-SVN-Commit-Author: kib X-SVN-Commit-Paths: stable/11/sys/vm X-SVN-Commit-Revision: 326188 X-SVN-Commit-Repository: base MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 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" \)" <svn-src-all.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/svn-src-all>, <mailto:svn-src-all-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/svn-src-all/>; List-Post: <mailto:svn-src-all@freebsd.org> List-Help: <mailto:svn-src-all-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/svn-src-all>, <mailto:svn-src-all-request@freebsd.org?subject=subscribe> X-List-Received-Date: Sat, 25 Nov 2017 14:47:26 -0000 Author: kib Date: Sat Nov 25 14:47:24 2017 New Revision: 326188 URL: https://svnweb.freebsd.org/changeset/base/326188 Log: MFC r326098: Return different error code for the guard page layout violation. PR: 223732 Modified: stable/11/sys/vm/vm_map.c Directory Properties: stable/11/ (props changed) Modified: stable/11/sys/vm/vm_map.c ============================================================================== --- stable/11/sys/vm/vm_map.c Sat Nov 25 09:47:31 2017 (r326187) +++ stable/11/sys/vm/vm_map.c Sat Nov 25 14:47:24 2017 (r326188) @@ -3610,12 +3610,13 @@ vm_map_stack_locked(vm_map_t map, vm_offset_t addrbos, KASSERT(orient != (MAP_STACK_GROWS_DOWN | MAP_STACK_GROWS_UP), ("bi-dir stack")); - sgp = (vm_size_t)stack_guard_page * PAGE_SIZE; if (addrbos < vm_map_min(map) || - addrbos > vm_map_max(map) || - addrbos + max_ssize < addrbos || - sgp >= max_ssize) - return (KERN_NO_SPACE); + addrbos + max_ssize > vm_map_max(map) || + addrbos + max_ssize <= addrbos) + return (KERN_INVALID_ADDRESS); + sgp = (vm_size_t)stack_guard_page * PAGE_SIZE; + if (sgp >= max_ssize) + return (KERN_INVALID_ARGUMENT); init_ssize = growsize; if (max_ssize < init_ssize + sgp)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171125201623.J1236>