Date: Mon, 20 Nov 2017 13:44:07 +0100 From: Henri Hennebert <hlh@restart.be> To: Ian Lepore <ian@freebsd.org>, Andreas Schwarz <freebsd.asc@strcmp.org>, freebsd-arm@FreeBSD.org Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time Message-ID: <55dd038f-4d82-4fca-bd57-8315bb99c38b@restart.be> In-Reply-To: <1510851514.99235.378.camel@freebsd.org> References: <d85f883f-84c2-5051-1996-2a0e73a2c1e7@restart.be> <4BF75B1E-318C-414A-B5D4-4BA7D6578316@dsl-only.net> <1509029871.56824.49.camel@freebsd.org> <c2bff518-89ce-4956-2548-e56afab5d83d@restart.be> <4af740148ca.47a474e3@mail.schwarzes.net> <04b67007-a95a-9e40-28b4-764adf8b2ded@restart.be> <FCA144E8-121A-48A5-8CDB-101FBDE6E84C@dsl-only.net> <dceb4702-8ede-aadd-17d8-ed41436955ad@restart.be> <4aff37249b6.70779c93@mail.schwarzes.net> <1510851514.99235.378.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/16/2017 17:58, Ian Lepore wrote: > 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. Thank you for those illuminating informations I will try another Pine64+ and a new power supply Henri > -- Ian > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55dd038f-4d82-4fca-bd57-8315bb99c38b>