From owner-freebsd-questions@freebsd.org Thu Oct 12 20:45:18 2017 Return-Path: Delivered-To: freebsd-questions@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 EB308E34549 for ; Thu, 12 Oct 2017 20:45:18 +0000 (UTC) (envelope-from prvs=145167c601=vogelke@pobox.com) Received: from SCOTT-MAIL6.AFNOC.AF.MIL (scott-mail6.afnoc.af.mil [131.9.253.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "SCOTT-MAIL6.AFNOC.AF.MIL", Issuer "SCOTT-MAIL6.AFNOC.AF.MIL" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E79166952 for ; Thu, 12 Oct 2017 20:45:17 +0000 (UTC) (envelope-from prvs=145167c601=vogelke@pobox.com) Received: from us.af.mil (unknown [131.9.254.140]) by SCOTT-MAIL6.AFNOC.AF.MIL with smtp (TLS: TLSv1/SSLv3,256bits,DHE-RSA-AES256-SHA) id 1315_3787_2dcc584c_52c8_4256_8074_ff1992109ead; Thu, 12 Oct 2017 20:45:02 +0000 Received: from ([131.9.40.227]) by 52vejx-mr-006.us.af.mil with SMTP id 2X21FN1.319850813; Thu, 12 Oct 2017 15:44:56 -0500 Received: (qmail 11820 invoked by uid 100); 12 Oct 2017 20:44:55 -0000 From: "Karl Vogel" Date: Thu, 12 Oct 2017 16:44:55 -0400 To: freebsd-questions@freebsd.org Subject: Re: Another 11.1-RELEASE install minor annoyance (ntpd) Message-ID: <20171012204455.GA10740@bsd118.wpafb.af.mil> Reply-To: vogelke@pobox.com References: <3967.1507825257@segfault.tristatelogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 20:45:19 -0000 Some NTP observations: ntpdate can be a lifesaver. Sometimes after installing a new system, I'll see tons of crap dumped in the system logs: ntpd[743]: frequency error -512 PPM exceeds tolerance 500 PPM The only workaround I've found is to run ntpdate every 30/60 minutes via cron. I'm pretty sure the clock chip is just too cheap to work and play nicely with ntpd. Setting the tolerance higher using (say) "ntptime -f 520" hasn't worked. Also, you may shoot yourself in the foot if you use a lot of servers: http://lists.centos.org/pipermail/centos/2010-August/098092.html Date drift and ntpd Warren Young Thu Aug 12 17:41:17 EDT 2010 Some HOWTOs tell you that more time servers is better, on a standard knee-jerk redundancy theory, but they're ignoring two things. First, you already have a fallback: the system's built-in clock. It's perfectly fine to run on that while you ride out your time server's downtime. Second, ntpd, internally, is built on a phase-locked loop, which is supposed to stabilize its time corrections in the face of jitter and other bad things out in the real world. Like anything based on a negative feedback loop, however, it can be destablized with certain inputs. Giving ntpd two or more servers is a pretty good way to destabilize its PLL in the real, non-ideal world we find on the modern Internet. To anyone considering flaming me, please read this first: http://queue.acm.org/detail.cfm?id=1773943 At minimum, read the section "One server is enough". The bit on PLLs about halfway down is also directly relevant. In the "One server is enough" section: So far we have discussed synchronizing to a single server. Surely one could connect to multiple servers and select among them to obtain even better results? In principle this is true; in Internet practice, at least with the current state of the art, it is most definitely not, for two reasons. Most fundamentally, switching servers implies a change in path asymmetry and hence a jump in the clock. Imagine a server-selection algorithm that is moving around among candidate servers of similar quality. The result is constant jumping?a classic case of asymmetry jitter. Such jitter is not hard to observe in ntpd, where a connection to multiple peers is in fact recommended. Second, once performance is tuned to close to system and network noise limits, any disruption at all will downgrade it. Ceasing to query a server for a time and then returning to it, for example, qualifies as a moderate to large disruption. The take-home message for administrators is this: if you want to improve your system clock performance, just make sure the configuration points only to a single (nearby) server. -- Karl Vogel I don't speak for the USAF or my company Teenage girl creates sustainable, renewable algae biofuel under her bed --Extreme Tech headline, 19 March 2013