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

[Henri Hennebert]

On 11/20/2017 13:44, Henri Hennebert wrote:
> 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

On a new pine64+ (bord + power + usb hub + another usb disk)

FreeBSD nakiska.restart.bel 12.0-CURRENT FreeBSD 12.0-CURRENT #0 
r325991M: Thu Nov 30 11:56:47 CET 2017 
root at nakiska.restart.bel:/usr/obj/usr/src/arm64.aarch64/sys/NORQUAY  arm64

Without ntpd running, I observe a drift of 3 minutes after 12 hours 
during the night with only the periodic jobs running.

Henri

> 
> 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"
>>
> _______________________________________________
> 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"