PINE64 - 12.0-CURRENT r324563 - ntpd can't keep time
Henri Hennebert
hlh at restart.be
Tue Nov 14 07:06:34 UTC 2017
On 11/13/2017 21:03, Mark Millard wrote:
>
> On 2017-Nov-13, at 9:01 AM, Henri Hennebert <hlh at restart.be> wrote:
>
>> On 11/08/2017 22:03, Andreas Schwarz wrote:
>>> On 08.11.17, Henri Hennebert wrote:
>>>> I upgrade to r324743 and ntpd can't keep time. Maybe of importance, I
>>>> was upgrading the ports after this switch to r324743. Moreover the
>>>> problem with pf occurs really frequently (see
>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222126)
>>> I'm running a PINE A64 2G without any problems.
>>> dump at pinelot:~ $ uname -a
>>> FreeBSD pinelot.schwarzes.net 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r325464: Mon Nov 6 17:44:44 CET 2017 root at pinelot.schwarzes.net:/usr/obj/usr/src/arm64.aarch64/sys/PINE64-ASC arm64
>>> dump at pinelot:~ $ ntpq -p
>>> remote refid st t when poll reach delay offset jitter
>>> ==============================================================================
>>> 0.freebsd.pool. .POOL. 16 p - 64 0 0.000 0.000 0.001
>>> +25000-014.cloud 131.188.3.221 2 u 58 64 377 16.366 5.450 6.000
>>> *epsilon.h6g-ser 192.53.103.103 2 u 50 64 377 14.943 5.812 5.511
>>> -y.ns.gin.ntt.ne 249.224.99.213 2 u 55 64 377 11.358 6.847 5.514
>>> +static.132.14.7 131.188.3.221 2 u 54 64 377 16.240 6.074 5.599
>>> 1b.ncomputers.o 129.187.254.32 2 u 58 64 37 19.479 -0.972 0.152
>>> What time sources are you using in you /etc/ntp.conf? When looking to your initial
>>> mail, it seems that one of the stratum 2 sources has a problem.
>>> Can you add the default freebsd pool (ntpd supporting pools now) for a test?
>>> pool 0.freebsd.pool.ntp.org iburst
>>
>> I upgrade to r324563 and I use this pool and monitor ntpd with 10 minutes interval:
>>
>> [root at norquay log]# less ntpmonitor.log
>> 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 287 1024 77 59.013 1.473 1.112
>> +ns2.telecom.lt 212.59.3.3 2 u 737 1024 37 43.029 0.513 0.988
>> -ntp.bserved.nl 193.67.79.202 2 u 440 1024 17 17.392 0.224 1.103
>> *178.32.44.208 ( 193.190.230.65 2 u 839 1024 37 14.399 0.527 0.490
>> +stratum2-1.NTP. 129.70.130.71 2 u 366 1024 37 28.377 1.706 0.361
>> -linode.ibendit. 199.102.46.77 2 u 307 1024 37 129.945 0.307 0.584
>> #ntp.kennisdelen 193.190.230.66 2 u 98 1024 37 15.019 0.942 0.777
>> #193.104.37.238 193.190.230.66 2 u 110 1024 37 14.186 0.730 0.424
>> 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 888 1024 77 59.013 1.473 1.112
>> +ns2.telecom.lt 212.59.3.3 2 u 288 1024 77 43.362 1.165 0.669
>> -ntp.bserved.nl 193.67.79.202 2 u 1041 1024 17 17.392 0.224 1.103
>> *178.32.44.208 ( 193.190.230.65 2 u 365 1024 77 14.399 0.527 0.520
>> +stratum2-1.NTP. 129.70.130.71 2 u 966 1024 37 28.377 1.706 0.361
>> -linode.ibendit. 199.102.46.77 2 u 907 1024 37 129.945 0.307 0.584
>> #ntp.kennisdelen 193.190.230.66 2 u 699 1024 37 15.019 0.942 0.777
>> #193.104.37.238 193.190.230.66 2 u 711 1024 37 14.186 0.730 0.424
>> 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 498 1024 177 58.815 1.451 0.932
>> +ns2.telecom.lt 212.59.3.3 2 u 979 1024 77 43.362 1.165 0.669
>> +ntp.bserved.nl 193.67.79.202 2 u 661 1024 37 17.664 0.980 0.379
>> -178.32.44.208 ( 193.190.230.65 2 u 1056 1024 77 14.399 0.527 0.520
>> *stratum2-1.NTP. 129.70.130.71 2 u 627 1024 77 28.135 1.998 0.570
>> -linode.ibendit. 199.102.46.77 2 u 1598 1024 76 129.945 0.307 0.584
>> #193.104.37.238 193.190.230.66 2 u 349 1024 77 14.977 1.321 0.821
>> 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
>>
>> And after a half hour the clock was 5 minutes in the future.
>
> Did you notice the huge offset and jitter in your listing:
> (last 2 numerals in the line below)
>
> +ns2.telecom.lt 212.59.3.3 2 u 13 1024 177 43.400 -357912 357913.
>
> And there is another huge jitter:
> (last numeral)
>
> -178.32.44.208 ( 193.190.230.65 2 u 81 1024 177 14.930 1.087 135278.
>
> (That last suggests a previous huge offset that still
> shows up as history via the jitter being large.)
>
> man ntpq indicates:
>
> offset offset of server relative to this host
>
> Jitter is not described in detail but I expect that
> it is based on the history of variations in offset.
> What is said is:
>
> The jitter and wander statistics are exponentially-weighted RMS averages.
> The system jitter is defined in the NTPv4 specification; the clock jitter
> statistic is computed by the clock discipline module.
>
> 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.
In a old version of Freebsd12, when dev.cpu.0.freq was accessible, the
problem appear when I force the frequency to 1200.
In the same network, other computers (amd64) get no problem with this
ntpd configuration.
>
> It looks to me like you need to avoid those 2 severs,
> substituting some others or some such. If some
> communication channel(s) involved are corrupting data
> then simply switching servers might not avoid the
> issue?
>
> I finally got a hold of the rpi3 and updated it to
> -r325700 from back a -r320123. it has been up 9 hr
> 40 min and date is still showing the correct time,
> no evidence of huge offsets or huge jitter.
>
> The Pine64+ 2GB is also at -r325700 now and has been
> up for 2 days. It also is working fine. Again no
> evidence of huge offsets or huge jitter.
Did you run heavy jobs running on this system? My Pine64+ is managing my
connection to internet (mpd5), named, dhcp, my mail (sendmail +
cyrus-imap) and dspam with postgres as db. The problem crops up when for
example I run a port upgrade.
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
>
More information about the freebsd-arm
mailing list