I am currently experiencing incredibly long sync delays with ntpd and, after much Googling, have decided to start a fresh thread as all 'remedies' have failed to work.
The machine in question is a Raspberry Pi 3B running Raspi OS 'Buster' (the 5/7/21 lite/non-GUI image). As it is to be the head node for a small cluster, it has 2 NICs - eth0 (built-in NIC and inside interface) is set to 192.168.4.100/24 and eth1 (USB dongle and outside interface) is set to 192.168.1.220/24. I am currently using dhcpcd to configure the interfaces and have name servers defined in /etc/resolvconf.conf. ntpd will eventually sync up, but only after hours and when I reboot the Pi, despite the fake-hwclock saving the time in /etc/fake-hwclock.data, ntpd is back at square one and starts the hours-long sync process again. I should note that the time saved in /etc/fake-hwclock is UTC time, not time zone adjusted time, but I wouldn't think that that would affect ntpd's sync time.
Below is my /etc/ntp.conf file. Uncommenting the 'tinker panic 0' line does not seem to affect synchronization at all.
To summarize, my questions are:
How can I reduce the sync time delay?
If I reboot the Pi after ntpd has sync'ed, running the 'date' command will give me the proper time, BUT ntpd will have returned to square one and it will take hours for it to sync. How can this be avoided? (Logic says that it shouldn't take very long to reconcile the local and remote times when they are mere seconds apart)
systemd-timesyncd is disabled.
/etc/ntp.conf
# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help
#tinker panic 0
driftfile /var/lib/ntp/ntp.drift
# Leap seconds definition provided by tzdata
leapfile /usr/share/zoneinfo/leap-seconds.list
# Enable this if you want statistics to be logged.
#statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
# You do need to talk to an NTP server or two (or three).
server time-a-g.nist.gov iburst
server time-a-wwv.nist.gov iburst
server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details. The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>
# might also be helpful.
#
# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery limited
# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
# Needed for adding pool entries
restrict source notrap nomodify noquery
# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)
broadcast 192.168.4.255
Output of 'uptime' and 'ntpq -p' at 11:07 AM CDT (according to my MacBook Pro's clock):
charles@Chimera-Head-Node:~ $ uptime
10:12:52 up 34 min, 1 user, load average: 0.00, 0.00, 0.00
charles@Chimera-Head-Node:~ $ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
192.168.4.255 .XFAC. 16 B - 64 0 0.000 0.000 0.002
time-a-g.nist.g .INIT. 16 u - 1024 0 0.000 0.000 0.000
time-a-wwv.nist .INIT. 16 u - 1024 0 0.000 0.000 0.000
ec.sedley.net .INIT. 16 u - 1024 0 0.000 0.000 0.000
ntp1.doctor.com .INIT. 16 u - 1024 0 0.000 0.000 0.000
Note: Whenever I boot/reboot the Pi, the broadcast address always shows up as .XFAC. for the refid. If I do a simple 'sudo service ntp restart', the refid changes to .BCST. (what it needs to be). I've yet to fix that problem and while it is an issue for another thread, any suggestions are welcome :-)
Output of syslog on boot (non-ntpd/dhcpcd entries removed):
Sep 1 09:38:53 Chimera-Head-Node ntpd[546]: ntpd 4.2.8p12@1.3728-o (1): Starting
Sep 1 09:38:53 Chimera-Head-Node ntpd[546]: Command line: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 109:114
Sep 1 09:38:53 Chimera-Head-Node systemd[1]: Started Network Time Service.
Sep 1 09:38:53 Chimera-Head-Node ntpd[554]: proto: precision = 1.458 usec (-19)
Sep 1 09:38:53 Chimera-Head-Node ntpd[554]: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): good hash s
ignature
Sep 1 09:38:53 Chimera-Head-Node ntpd[554]: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): loaded, exp
ire=2021-12-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37
Sep 1 09:38:53 Chimera-Head-Node ntpd[554]: Listen and drop on 0 v6wildcard [::]:123
Sep 1 09:38:53 Chimera-Head-Node ntpd[554]: Listen and drop on 1 v4wildcard 0.0.0.0:123
Sep 1 09:38:53 Chimera-Head-Node ntpd[554]: Listen normally on 2 lo 127.0.0.1:123
Sep 1 09:38:53 Chimera-Head-Node ntpd[554]: Listen normally on 3 eth1 192.168.1.220:123
Sep 1 09:38:53 Chimera-Head-Node ntpd[554]: Listen normally on 4 lo [::1]:123
Sep 1 09:38:53 Chimera-Head-Node ntpd[554]: Listen normally on 5 eth0 [fe80::ba27:ebff:fed5:8e4d%2]:123
Sep 1 09:38:53 Chimera-Head-Node ntpd[554]: Listen normally on 6 eth1 [fe80::1f2d:3bb6:af44:5cbb%3]:123
Sep 1 09:38:53 Chimera-Head-Node ntpd[554]: Listening on routing socket on fd #23 for interface updates
Sep 1 09:38:53 Chimera-Head-Node ntpd[554]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Sep 1 09:38:53 Chimera-Head-Node ntpd[554]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Sep 1 09:38:54 Chimera-Head-Node dhcpcd[541]: eth0: using static address 192.168.4.100/24
Sep 1 09:38:54 Chimera-Head-Node dhcpcd[541]: eth0: adding route to 192.168.4.0/24
Sep 1 09:38:55 Chimera-Head-Node ntpd[554]: Listen normally on 7 eth0 192.168.4.100:123
Sep 1 09:38:55 Chimera-Head-Node ntpd[554]: 192.168.4.255 local addr 192.168.1.220 -> 192.168.4.100
Sep 1 09:38:55 Chimera-Head-Node ntpd[554]: new interface(s) found: waking up resolver
Sep 1 09:39:01 Chimera-Head-Node dhcpcd[541]: eth1: no IPv6 Routers available
Sep 1 09:39:03 Chimera-Head-Node dhcpcd[541]: eth0: no IPv6 Routers available
server ...pool... iburst, it'spool ...pool... iburst. You should not hardcode the nist servers, these should be listed aspool time.nist.gov iburst. The XFAC suggests your IP address changed, I wonder if both those IP addresses have equal cost routing to the internet?. I would also check your routers as to whether they are allowing 123UDP inward bound.