From owner-freebsd-arm@freebsd.org Tue Nov 14 07:06:34 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 02272D7E49E for ; Tue, 14 Nov 2017 07:06:34 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [5.135.182.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A941C7296F; Tue, 14 Nov 2017 07:06:32 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=192.168.25.127; helo=restart.be; envelope-from=hlh@restart.be; receiver=markmi@dsl-only.net DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 3ybdpZ1gb5ztms Received: from restart.be (norquay.tunnel.bel [192.168.25.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3ybdpZ1gb5ztms; Tue, 14 Nov 2017 08:06:29 +0100 (CET) Received: from chamonix.restart.bel (chamonix.restart.bel [192.168.24.9]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id vAE76RC7008499 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 14 Nov 2017 08:06:27 +0100 (CET) (envelope-from hlh@restart.be) Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time To: Mark Millard Cc: freebsd-arm@FreeBSD.org, freebsd.asc@strcmp.org, ian@freebsd.org 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> From: Henri Hennebert Message-ID: Date: Tue, 14 Nov 2017 08:06:26 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Tue, 14 Nov 2017 07:06:34 -0000 On 11/13/2017 21:03, Mark Millard wrote: > > 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=222126) >>> 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 >>> ============================================================================== >>> 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 >> >> I upgrade to r324563 and I use this pool and monitor ntpd with 10 minutes interval: >> >> [root@norquay log]# less ntpmonitor.log >> remote refid st t when poll reach delay offset jitter >> ============================================================================== >> 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 >> ============================================================================== >> 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 >> ============================================================================== >> 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 >> ============================================================================== >> 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 >> >> 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. I believe that the clock of the Pine64+ is going too fast and that the 2 servers where polled and so show this offset/jitter. In an other occurrence of this problem, if I wait long enough, all servers display huge offset. In a old version of Freebsd12, when dev.cpu.0.freq was accessible, the problem appear when I force the frequency to 1200. In the same network, other computers (amd64) get no problem with this ntpd configuration. > > 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. Did you run heavy jobs running on this system? My Pine64+ is managing my connection to internet (mpd5), named, dhcp, my mail (sendmail + cyrus-imap) and dspam with postgres as db. The problem crops up when for example I run a port upgrade. > > === > Mark Millard > markmi at dsl-only.net > >