From owner-freebsd-arm@freebsd.org Mon Nov 13 20:30:17 2017 Return-Path: Delivered-To: freebsd-arm@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 0717ADD4EA0 for ; Mon, 13 Nov 2017 20:30:17 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-95.reflexion.net [208.70.210.95]) (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 C0CCE7CDE7 for ; Mon, 13 Nov 2017 20:30:15 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31525 invoked from network); 13 Nov 2017 20:03:29 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 13 Nov 2017 20:03:29 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Mon, 13 Nov 2017 15:03:29 -0500 (EST) Received: (qmail 5611 invoked from network); 13 Nov 2017 20:03:29 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Nov 2017 20:03:29 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id E545FEC8F04; Mon, 13 Nov 2017 12:03:28 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time From: Mark Millard In-Reply-To: <04b67007-a95a-9e40-28b4-764adf8b2ded@restart.be> Date: Mon, 13 Nov 2017 12:03:28 -0800 Cc: freebsd-arm@FreeBSD.org, freebsd.asc@strcmp.org, ian@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> <1509029871.56824.49.camel@freebsd.org> <4af740148ca.47a474e3@mail.schwarzes.net> <04b67007-a95a-9e40-28b4-764adf8b2ded@restart.be> To: Henri Hennebert X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 20:30:17 -0000 On 2017-Nov-13, at 9:01 AM, Henri Hennebert wrote: > On 11/08/2017 22:03, Andreas Schwarz wrote: >> On 08.11.17, Henri Hennebert wrote: >>> I upgrade to r324743 and ntpd can't keep time. Maybe of importance, = I >>> was upgrading the ports after this switch to r324743. Moreover the >>> problem with pf occurs really frequently (see >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222126) >> I'm running a PINE A64 2G without any problems. >> dump@pinelot:~ $ uname -a >> FreeBSD pinelot.schwarzes.net 12.0-CURRENT FreeBSD 12.0-CURRENT #0 = r325464: Mon Nov 6 17:44:44 CET 2017 = root@pinelot.schwarzes.net:/usr/obj/usr/src/arm64.aarch64/sys/PINE64-ASC = arm64 >> dump@pinelot:~ $ ntpq -p >> remote refid st t when poll reach delay = offset jitter >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> 0.freebsd.pool. .POOL. 16 p - 64 0 0.000 = 0.000 0.001 >> +25000-014.cloud 131.188.3.221 2 u 58 64 377 16.366 = 5.450 6.000 >> *epsilon.h6g-ser 192.53.103.103 2 u 50 64 377 14.943 = 5.812 5.511 >> -y.ns.gin.ntt.ne 249.224.99.213 2 u 55 64 377 11.358 = 6.847 5.514 >> +static.132.14.7 131.188.3.221 2 u 54 64 377 16.240 = 6.074 5.599 >> 1b.ncomputers.o 129.187.254.32 2 u 58 64 37 19.479 = -0.972 0.152 >> What time sources are you using in you /etc/ntp.conf? When looking to = your initial >> mail, it seems that one of the stratum 2 sources has a problem. >> Can you add the default freebsd pool (ntpd supporting pools now) for = a test? >> pool 0.freebsd.pool.ntp.org iburst >=20 > I upgrade to r324563 and I use this pool and monitor ntpd with 10 = minutes interval: >=20 > [root@norquay log]# less ntpmonitor.log > remote refid st t when poll reach delay offset = jitter > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 0.freebsd.pool. .POOL. 16 p - 64 0 0.000 0.000 = 0.000 > -webhost2.mitht. 193.67.79.202 2 u 287 1024 77 59.013 1.473 = 1.112 > +ns2.telecom.lt 212.59.3.3 2 u 737 1024 37 43.029 0.513 = 0.988 > -ntp.bserved.nl 193.67.79.202 2 u 440 1024 17 17.392 0.224 = 1.103 > *178.32.44.208 ( 193.190.230.65 2 u 839 1024 37 14.399 0.527 = 0.490 > +stratum2-1.NTP. 129.70.130.71 2 u 366 1024 37 28.377 1.706 = 0.361 > -linode.ibendit. 199.102.46.77 2 u 307 1024 37 129.945 0.307 = 0.584 > #ntp.kennisdelen 193.190.230.66 2 u 98 1024 37 15.019 0.942 = 0.777 > #193.104.37.238 193.190.230.66 2 u 110 1024 37 14.186 0.730 = 0.424 > remote refid st t when poll reach delay offset = jitter > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 0.freebsd.pool. .POOL. 16 p - 64 0 0.000 0.000 = 0.000 > -webhost2.mitht. 193.67.79.202 2 u 888 1024 77 59.013 1.473 = 1.112 > +ns2.telecom.lt 212.59.3.3 2 u 288 1024 77 43.362 1.165 = 0.669 > -ntp.bserved.nl 193.67.79.202 2 u 1041 1024 17 17.392 0.224 = 1.103 > *178.32.44.208 ( 193.190.230.65 2 u 365 1024 77 14.399 0.527 = 0.520 > +stratum2-1.NTP. 129.70.130.71 2 u 966 1024 37 28.377 1.706 = 0.361 > -linode.ibendit. 199.102.46.77 2 u 907 1024 37 129.945 0.307 = 0.584 > #ntp.kennisdelen 193.190.230.66 2 u 699 1024 37 15.019 0.942 = 0.777 > #193.104.37.238 193.190.230.66 2 u 711 1024 37 14.186 0.730 = 0.424 > remote refid st t when poll reach delay offset = jitter > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 0.freebsd.pool. .POOL. 16 p - 64 0 0.000 0.000 = 0.000 > -webhost2.mitht. 193.67.79.202 2 u 498 1024 177 58.815 1.451 = 0.932 > +ns2.telecom.lt 212.59.3.3 2 u 979 1024 77 43.362 1.165 = 0.669 > +ntp.bserved.nl 193.67.79.202 2 u 661 1024 37 17.664 0.980 = 0.379 > -178.32.44.208 ( 193.190.230.65 2 u 1056 1024 77 14.399 0.527 = 0.520 > *stratum2-1.NTP. 129.70.130.71 2 u 627 1024 77 28.135 1.998 = 0.570 > -linode.ibendit. 199.102.46.77 2 u 1598 1024 76 129.945 0.307 = 0.584 > #193.104.37.238 193.190.230.66 2 u 349 1024 77 14.977 1.321 = 0.821 > remote refid st t when poll reach delay offset = jitter > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 0.freebsd.pool. .POOL. 16 p - 64 0 0.000 0.000 = 0.000 > -webhost2.mitht. 193.67.79.202 2 u 948 1024 177 58.815 1.451 = 0.932 > +ns2.telecom.lt 212.59.3.3 2 u 13 1024 177 43.400 -357912 = 357913. > +ntp.bserved.nl 193.67.79.202 2 u 1111 1024 37 17.664 0.980 = 0.379 > -178.32.44.208 ( 193.190.230.65 2 u 81 1024 177 14.930 1.087 = 135278. > *stratum2-1.NTP. 129.70.130.71 2 u 1077 1024 77 28.135 1.998 = 0.570 > -linode.ibendit. 199.102.46.77 2 u 2048 1024 76 129.945 0.307 = 0.584 > #193.104.37.238 193.190.230.66 2 u 799 1024 77 14.977 1.321 = 0.821 >=20 > And after a half hour the clock was 5 minutes in the future. Did you notice the huge offset and jitter in your listing: (last 2 numerals in the line below) +ns2.telecom.lt 212.59.3.3 2 u 13 1024 177 43.400 -357912 = 357913. And there is another huge jitter: (last numeral) -178.32.44.208 ( 193.190.230.65 2 u 81 1024 177 14.930 1.087 = 135278. (That last suggests a previous huge offset that still shows up as history via the jitter being large.) man ntpq indicates: offset offset of server relative to this host Jitter is not described in detail but I expect that it is based on the history of variations in offset. What is said is: The jitter and wander statistics are exponentially-weighted RMS = averages. The system jitter is defined in the NTPv4 specification; the clock = jitter statistic is computed by the clock discipline module. So it looks like you are getting bad times from at least 2 servers. Note that the other servers seem fine as far as your e-mailed material goes. It looks to me like you need to avoid those 2 severs, substituting some others or some such. If some communication channel(s) involved are corrupting data then simply switching servers might not avoid the issue? I finally got a hold of the rpi3 and updated it to -r325700 from back a -r320123. it has been up 9 hr 40 min and date is still showing the correct time, no evidence of huge offsets or huge jitter. The Pine64+ 2GB is also at -r325700 now and has been up for 2 days. It also is working fine. Again no evidence of huge offsets or huge jitter. =3D=3D=3D Mark Millard markmi at dsl-only.net