Am trying to debug a connectivity problem on our raspberry pizero device running OS 2.46 rev1. Finally realized that the system’s date is wrong. On both the Host OS and container:
root@1e46499:~# date
Tue Apr 7 22:19:03 UTC 2020
whereas on another device:
bash-5.0# date
Wed Apr 8 23:38:56 UTC 2020
That is, it’s off by almost 80 minutes. This should be set via synchronization to NTP servers somewhere I imagine. Thoughts on how to address?
Hi
resinio.pool.ntp.orgchrony to manage time. See our docs here for more info on how that workschronyc tracking, chronyc ntpdata. This should help us debug why it isn’t tracking time correctly.Thanks Anuj - the documentation is very good. Sorry I missed it before posting.
We were for a long time unable to connect to the device. Finally we connected and I see:
root@1e46499:~# chronyc sources
210 Number of sources = 4
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^? static-186-155-28-147.st> 0 14 0 - +0ns[ +0ns] +/- 0ns
^? ntp1.trans-ix.nl 0 14 0 - +0ns[ +0ns] +/- 0ns
^* t1.time.gq1.yahoo.com 2 14 17 501 -721us[-1190us] +/- 100ms
^? 200.118.21.37 0 14 0 - +0ns[ +0ns] +/- 0ns
root@1e46499:~# chronyc tracking
Reference ID : 4A06A848 (t1.time.gq1.yahoo.com)
Stratum : 3
Ref time (UTC) : Thu Apr 09 17:28:22 2020
System time : 0.000000057 seconds fast of NTP time
Last offset : -0.000469467 seconds
RMS offset : 0.000469467 seconds
Frequency : 3.976 ppm fast
Residual freq : -171.720 ppm
Skew : 0.353 ppm
Root delay : 0.167469308 seconds
Root dispersion : 0.116974130 seconds
Update interval : 2.2 seconds
Leap status : Normal
root@1e46499:~# chronyc ntpdata
Remote address : [UNSPEC] (00000000)
Remote port : 0
Local address : [UNSPEC] (00000000)
Leap status : Normal
Version : 0
Mode : Invalid
Stratum : 0
Poll interval : 0 (1 seconds)
Precision : 0 (1.000000000 seconds)
Root delay : 0.000000 seconds
Root dispersion : 0.000000 seconds
Reference ID : 00000000 ()
Reference time : Thu Jan 01 00:00:00 1970
Offset : +0.000000000 seconds
Peer delay : 0.000000000 seconds
Peer dispersion : 0.000000000 seconds
Response time : 0.000000000 seconds
Jitter asymmetry: +0.00
NTP tests : 000 000 0000
Interleaved : No
Authenticated : No
TX timestamping : Invalid
RX timestamping : Invalid
Total TX : 8
Total RX : 0
Total valid RX : 0
Remote address : [UNSPEC] (00000000)
Remote port : 0
Local address : [UNSPEC] (00000000)
Leap status : Normal
Version : 0
Mode : Invalid
Stratum : 0
Poll interval : 0 (1 seconds)
Precision : 0 (1.000000000 seconds)
Root delay : 0.000000 seconds
Root dispersion : 0.000000 seconds
Reference ID : 00000000 ()
Reference time : Thu Jan 01 00:00:00 1970
Offset : +0.000000000 seconds
Peer delay : 0.000000000 seconds
Peer dispersion : 0.000000000 seconds
Response time : 0.000000000 seconds
Jitter asymmetry: +0.00
NTP tests : 000 000 0000
Interleaved : No
Authenticated : No
TX timestamping : Invalid
RX timestamping : Invalid
Total TX : 8
Total RX : 0
Total valid RX : 0
Remote address : 74.6.168.72 (4A06A848)
Remote port : 123
Local address : 192.168.1.102 (C0A80166)
Leap status : Normal
Version : 4
Mode : Server
Stratum : 2
Poll interval : 14 (16384 seconds)
Precision : -24 (0.000000060 seconds)
Root delay : 0.000107 seconds
Root dispersion : 0.015945 seconds
Reference ID : D0472E21 ()
Reference time : Thu Apr 09 17:11:44 2020
Offset : +0.001190473 seconds
Peer delay : 0.167362496 seconds
Peer dispersion : 0.000335826 seconds
Response time : 0.000020845 seconds
Jitter asymmetry: +0.00
NTP tests : 111 111 1111
Interleaved : No
Authenticated : No
TX timestamping : Kernel
RX timestamping : Kernel
Total TX : 4
Total RX : 4
Total valid RX : 4
Remote address : [UNSPEC] (00000000)
Remote port : 0
Local address : [UNSPEC] (00000000)
Leap status : Normal
Version : 0
Mode : Invalid
Stratum : 0
Poll interval : 0 (1 seconds)
Precision : 0 (1.000000000 seconds)
Root delay : 0.000000 seconds
Root dispersion : 0.000000 seconds
Reference ID : 00000000 ()
Reference time : Thu Jan 01 00:00:00 1970
Offset : +0.000000000 seconds
Peer delay : 0.000000000 seconds
Peer dispersion : 0.000000000 seconds
Response time : 0.000000000 seconds
Jitter asymmetry: +0.00
NTP tests : 000 000 0000
Interleaved : No
Authenticated : No
TX timestamping : Invalid
RX timestamping : Invalid
Total TX : 8
Total RX : 0
Total valid RX : 0
Is my interpretation correct that it managed to connect to one of the time servers - perhaps previously it had not been able to connect to any? When I look at our different systems, the response to chronyc sources seems different for all of them, i.e. different servers. For example, another one shows:
root@79a8b85:~# chronyc sources
210 Number of sources = 4
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^? dynamic-186-30-58-181.dy> 0 10 0 - +0ns[ +0ns] +/- 0ns
^? 0.co.ntp.edgeuno.com 0 10 0 - +0ns[ +0ns] +/- 0ns
^+ ntp03.plutex.de 2 10 363 446 +23ms[ +21ms] +/- 137ms
^* atlas.linocomm.net 2 10 371 62 -419ms[ -421ms] +/- 751msHi,
It sounds very probable that the device had not been able to synchronise with any relevant time sources, which is why you were seeing a skewed clock. Once chrony has synced with a time source, it will try and use those, but should for some reason no sources be available it will attempt to use the last modification time of its skew file, which could be what you were seeing.
chronyc sources shows the ‘final’ address of the sources it’s currently using for time syncing, and again these will be different depending on which sources in the pool have been allocated to the client when it makes a request.
Hopefully this clarifies things!
Best regards,
Heds