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 trueafter 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
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?
timedatectl timesync-status gives me the following result:
Server: 126.96.36.199 (3.debian.pool.ntp.org) Poll interval: 1min 4s (min: 32s; max 34min 8s) Packet count: 0
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: Starting Network Time Synchronization... Sep 23 13:58:24 raspberrypi systemd: Started Network Time Synchronization.
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