From owner-freebsd-arm@freebsd.org Thu Nov 16 16:58:42 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 1B62FDE2ED4 for ; Thu, 16 Nov 2017 16:58:42 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 56BD41B25 for ; Thu, 16 Nov 2017 16:58:40 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 62b3be82-caef-11e7-b805-f37e907b5733 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 62b3be82-caef-11e7-b805-f37e907b5733; Thu, 16 Nov 2017 16:58:37 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id vAGGwYRM001327; Thu, 16 Nov 2017 09:58:34 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1510851514.99235.378.camel@freebsd.org> Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time From: Ian Lepore To: Andreas Schwarz , freebsd-arm@FreeBSD.org Date: Thu, 16 Nov 2017 09:58:34 -0700 In-Reply-To: <4aff37249b6.70779c93@mail.schwarzes.net> 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> <4aff37249b6.70779c93@mail.schwarzes.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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: Thu, 16 Nov 2017 16:58:42 -0000 On Tue, 2017-11-14 at 23:03 +0100, Andreas Schwarz wrote: > On 14.11.17, Henri Hennebert wrote: > > > > On 11/13/2017 21:03, Mark Millard wrote: > > > > > > > > > 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. > But they step not simultaneous to this offset (which is ~300s), why should some  > servers have such offset and others not?. > Because not all peers are being polled at the same time, and the offset and jitter are updated only after a polling cycle.  In the last ntpq: >>      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 Notice that the two anomalous servers are the ones with a small "when" value, indicating they were polled within the last couple minutes. Also, the fact that some of the "when" values are larger than the polling interval is unusual... that would tend to indicate network trouble... some of the servers are only beeing reached intermitantly (which can be seen by the incomplete "reach" masks). The idea that two public stratum-2 servers are providing consistant bad time is not a viable theory. Also, the time is good and stable for several of the ten-minute intervals, and it was good for long enough that the polling interval ramped up from 64 to 1024 seconds (assuming there is no "minpoll" override forcing it to 1024 in ntp.conf).  That argues against any kind of constant clock-drift problem.  Either the clock is stepping due to a problem in the driver such as not handling rollover of a 32-bit register, or the clock goes wildly off-frequency, but only intermittantly.  The latter might happen if the cpu clock is being used as a timecounter and the cpu falls back to a low-power mode that cuts the clock frequency in half or something. -- Ian