PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time

[Henri Hennebert]

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 at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>