From owner-freebsd-arm@freebsd.org Tue May 4 13:58:51 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7F597632E4F for ; Tue, 4 May 2021 13:58:51 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.70]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FZLzZ0GXKz3J9Q for ; Tue, 4 May 2021 13:58:49 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from smtpclient.apple (unknown [73.99.214.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 0499936B; Tue, 4 May 2021 09:58:42 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Subject: Re: Timezone problems on -current From: Paul Mather In-Reply-To: <20210504042024.GA42279@www.zefox.net> Date: Tue, 4 May 2021 09:58:41 -0400 Cc: tech-lists , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20210503153442.GB37236@www.zefox.net> <20210504015222.GE37236@www.zefox.net> <20210504042024.GA42279@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Rspamd-Queue-Id: 4FZLzZ0GXKz3J9Q X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=vt.edu (policy=none); spf=none (mx1.freebsd.org: domain of paul@gromit.dlib.vt.edu has no SPF policy when checking 128.173.49.70) smtp.mailfrom=paul@gromit.dlib.vt.edu X-Spamd-Result: default: False [-2.50 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[paul]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; SPAMHAUS_ZRD(0.00)[128.173.49.70:from:127.0.2.255]; RECEIVED_SPAMHAUS_PBL(0.00)[73.99.214.146:received]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[128.173.49.70:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1312, ipnet:128.173.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm]; DMARC_POLICY_SOFTFAIL(0.10)[vt.edu : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to ARM processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 13:58:51 -0000 On May 4, 2021, at 12:20 AM, bob prohaska wrote: > On Tue, May 04, 2021 at 04:38:56AM +0100, tech-lists wrote: >> On Mon, May 03, 2021 at 06:52:22PM -0700, bob prohaska wrote: >>=20 >>> Up to now I've used only the line >>> ntpdate_enable=3D"YES" >>=20 >> Seems ntpdate isn't required if these are set in /etc/rc.conf >>=20 >> ntpd_enable=3D"YES" >> ntpd_sync_on_start=3D"YES" >>=20 >> even on boards with no RTC. >=20 > Indeed it looks as if ntpdate is going away, replaced by > enhancements to ntpd.=20 >=20 > Still, I think the timekeeping errors are caused by a somewhat > unconventional network setup on the machine having problems. > The rest of the hosts in my "data center" use ntpdate and=20 > have no trouble keeping their clocks right, but those hosts > all have wired ethernet. The host with the wrong clock setting > uses an ethernet-to-wifi adapter. Can't be sure until more=20 > testing is done. And, I might be wrong again..... The problem with ntpdate is that it is a one-time clock adjustment = whereas ntpd is a continuous time monitoring/adjustment. So, if your = system has problems with clock drift or just keeping accurate time, = ntpdate run on boot will not help in the long term. Ntpd, on the other = hand, will. Note also that 'ntpd_sync_on_start=3D"YES"' is effectively the same as = running ntpddate. The 'ntpd_sync_on_start=3D"YES"' setting lets ntpd = perform a one-time large step time adjustment (via the "-g" option), = which is essentially what you are achieving when running ntpdate. = Normally, ntpd will baulk if the clock is off by 1000s, which can easily = happen with systems that have no RTC, hence the need for the = 'ntpd_sync_on_start=3D"YES"' flag. When I ran FreeBSD/arm, I used the net/ntimed port to maintain time, = which is a simple, low-resource alternative to ntpd for keeping time on = FreeBSD/arm clients. Cheers, Paul.