Date: Thu, 16 Nov 2017 09:58:34 -0700 From: Ian Lepore <ian@freebsd.org> To: Andreas Schwarz <freebsd.asc@strcmp.org>, freebsd-arm@FreeBSD.org Subject: Re: PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time Message-ID: <1510851514.99235.378.camel@freebsd.org> In-Reply-To: <4aff37249b6.70779c93@mail.schwarzes.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1510851514.99235.378.camel>