4

I have bought three raspberry pi's with the intention of using them as temperature sensors throughout the building. I have bought the following models:

  • 1 raspberry pi 4 model b 2gb
  • 2 raspberry pi 4 model b 4gb (due to chip shortage 2gb were no longer available)

All of these are running the default Pi OS. however I noticed that the clocks on all of them cannot be synchronized with an NTP server. Which is kind of crucial or this to work.

I have tried the following:

  • turning on the ntp within timedatectl with sudo timedatectl set-ntp true after which I have restarted the systemd-timedated and systemd-timesyncd services.

  • specifying the same time server that all other machines sync to within our network as the NTP server

  • installed and enabled chrony and tried it that way (when this didn't work I purged it from the system)

  • installed ntp and ntpdate and tried forcing the sync.

  • reinstalled the Pi OS

When I ping 0.nl.pool.ntp.org it responds just fine.

None of these things can get the synchronization to work. Is there an alley which I have not yet tried. Or maybe some overaching reasons they can't sync?

EDIT: running timedatectl timesync-status gives me the following result:


Server: 84.31.172.97 (3.debian.pool.ntp.org)  
Poll interval: 1min 4s (min: 32s; max 34min 8s)  
Packet count: 0

result of ip a && ip r:


1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether e4:5f:01:4a:33:cf brd ff:ff:ff:ff:ff:ff
    inet 192.168.42.35/22 brd 192.168.43.255 scope global dynamic noprefixroute eth0
       valid_lft 687607sec preferred_lft 601207sec
    inet6 fe80::f2d5:f228:3c7b:86aa/64 scope link
       valid_lft forever preferred_lft forever
3: wlan0:  mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether e4:5f:01:4a:33:d1 brd ff:ff:ff:ff:ff:ff

default via 192.168.42.254 dev eth0 proto dhcp src 192.168.42.35 metric 202
192.168.40.0/22 dev eth0 proto dhcp scope link src 192.168.42.35 metric 202

The output of systemctl status systemd-timesyncd.service


 systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
  Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d
           └─disable-with-time-daemon.conf
   Active: active (running) since Thu 2021-09-23 13:58:24 CEST; 1h 22min ago
     Docs: man:systemd-timesyncd.service(8)
 Main PID: 1154 (systemd-timesyn)
   Status: "Idle."
    Tasks: 2 (limit: 4915)
   CGroup: /system.slice/systemd-timesyncd.service
           └─1154 /lib/systemd/systemd-timesyncd

Sep 23 13:58:24 raspberrypi systemd[1]: Starting Network Time Synchronization...
Sep 23 13:58:24 raspberrypi systemd[1]: Started Network Time Synchronization.

Running nc -z -v -u 3.debian.pool.ntp.org gave the following result:

Connection to 3.debian.pool.ntp.org 123 port [udp/ntp] succeeded!

However when I connected it via WiFi to a mobile hotspot it took only 2 seconds and was instantly synchronized. So it seems like it is indeed an issue with the network.

Solution: After digging a little more into the network, I was able to find out that the problem lies in the packets being dropped because the time server didn't respond in time. By increasing the RootDistanceMaxSec to 15 seconds I was able to get it to synchronize

Improve this question
7
  • What do you mean exactly when you say synchronization doesn't work? Your Pi boards never get the correct time unless you set it manually? The time difference between the two boards is too large? (how large?) Something else?
    – Dmitry Grigoryev
    Sep 22, 2021 at 15:07
  • Well for example when the pi has been off for some time and it boots up the time will be exactly where it was when it shutdown. Same goes for when I reinstalled the OS, when it boots up the first time it will attempt to synchronize the clock when it installs the recommended software, this gives an error saying 'synchronizing clock failed'. So yeah indeed they never get the correct time unless set manually
    – treskilion
    Sep 22, 2021 at 15:11
  • 1
    If you don't fiddle with it it works out of the box (provided you have internet access). What does timedatectl timesync-status show? NOTE do not reply in Comments, add to your post.
    – Milliways
    Sep 23, 2021 at 1:55
  • Flash an SD card with a vanilla system image (don't change any configuration, especially related to network and systemd) and see if that system gets the time.
    – Dmitry Grigoryev
    Sep 23, 2021 at 6:05
  • OK it doesn't appear to work, although the service seems to be trying. systemctl status systemd-timesyncd.service should show errors, but your problem is probably networking. Post iip a && ip r but it is likely external networking.
    – Milliways
    Sep 23, 2021 at 6:55

6 Answers 6

Reset to default
1

After digging a little more into the network, I was able to find out that the problem lies in the packets being dropped because the time server didn't respond in time. By increasing the RootDistanceMaxSec to 15 seconds I was able to get it to synchronize

Improve this answer
1

I think this is a locale problem. I had the same and I set the language back to English and it started to work again. When I have the language set to Swedish it does not sync. I checked the staus and it said it was in sync but "Recommended software" tried to sync and failed, despite the fact it actually did not.

Improve this answer
1
1

As @treskilion mention, it is because of "root distance". solved here

/etc/systemd/timesyncd.conf:

[Time]
NTP=10.10.1.30
#FallbackNTP=
RootDistanceMaxSec=30
Improve this answer
0

This almost certainly has nothing to do with the Pi.

Your /22 network is unusual (at least for a home network).

While everything appears to be working on the Pi you could try the netcat command suggested, but it may be more productive to contact your network administrator (some limit access to services).

You could try to connect to another network (e.g. a hotspot on your phone) which should work.

Improve this answer
1
  • This indeed looks like it's the right call to try another network. Connecting it to a mobile hotspot almost instantly solved the issue. Thanks!
    – treskilion
    Sep 24, 2021 at 6:25
0

Perhaps getting a RTC HAT and then MQTT the time to all otherboards? Only an alternative if no Network is available.

Improve this answer
1
  • The OP has edit the question with a solution: Solution: After digging a little more into the network, I was able to find out that the problem lies in the packets being dropped because the time server didn't respond in time. By increasing the RootDistanceMaxSec to 15 seconds I was able to get it to synchronize
    – MatsK
    Sep 27, 2021 at 11:02
0

I have the same problem related with sycronization. I'm new in Rasp Pie as well Please informe how can i type the following commands:

As @treskilion mention, it is because of "root distance". solved here

/etc/systemd/timesyncd.conf:

[Time] NTP=10.10.1.30 #FallbackNTP= RootDistanceMaxSec=30

Improve this answer
2
  • As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.
    – Community Bot
    Feb 27 at 8:34
  • The solution that I highlighted can be executed by simply opening the file in nano. nano /etc/systemd/timesyncd.conf should open the file in nano. You can then make the changes and save (Ctrl + S) and close the file (Ctrl + X). Afterwards be sure to restart the service again by running sudo systemctl restart systemd-timesyncd.service and the new configuration should be loaded.
    – treskilion
    Feb 27 at 14:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.