2

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:

  1. How can I reduce the sync time delay?

  2. 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
9
  • With all of the time servers reporting stratum 16, it seems unlikely to me that ntpd is actually succeeding in setting the time. Are you sure you have connectivity to those time servers?
    – Jeff Schaller
    Sep 1, 2021 at 17:09
  • @JeffSchaller - While I can't ping the NIST servers (I think they have ICMP blocked, which is understandable), I just pinged ec.sedley.net and ntp1.doctor.com. Sep 1, 2021 at 17:15
  • Do you have the ntpdate program, and can you (stop ntpd) and then run it manually against one of the time servers successfully?
    – Jeff Schaller
    Sep 1, 2021 at 17:16
  • 1
    You're not getting any NTP responses. It's not server ...pool... iburst, it's pool ...pool... iburst. You should not hardcode the nist servers, these should be listed as pool 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.
    – Bib
    Sep 1, 2021 at 18:22
  • @JeffSchaller - Pardon the delay - I've been doing quite a bit of testing :-) In regards to your question, I can stop ntpd, run 'sudo ntpdate -q time-a-wwv.nist.gov', and get back the server IP, stratum, offset, and delay info. When I try the same command w/o the -q flag, after several seconds, I get a message saying 'no server suitable for synchronization found' - something that makes no sense to me. How can a server report back such data and yet not be suitable for sync? Sep 3, 2021 at 17:50

1 Answer 1

0

(Moved here from originally having been part of the question text).

The problem has been resolved (I just haven't had a chance to post this until now). The solution was two part:

  1. While my Synology RT-2600ac router had the NTP service turned on and, in theory, port 123 was open, I turned off the service and then made a firewall rule that explicitly opened up udp port 123 from any IP address to any IP address.

  2. Below are the ntp.conf files that I am now using. While I don't know if the interface commands at the top of the head node's ntp.conf could be removed, I am pretty sure that the restrict line for the 192.168.4.0 network did the trick for NTP distribution on the 192.168.4.0 network.


Cluster head node ntp.conf

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

# default to listening to nothing
#
interface ignore all

# Listen on the inside interface
#
interface listen 192.168.4.100/24

# Listen on the outside interface
#
interface listen 192.168.1.220/24


driftfile /var/lib/ntp/ntp.drift

leapfile /usr/share/zoneinfo/leap-seconds.list

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


server time-a-g.nist.gov iburst
server time-a-wwv.nist.gov iburst

server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst

# 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

restrict 192.168.4.0 mask 255.255.255.0 nomodify

# Needed for adding pool entries
restrict source notrap nomodify noquery

Cluster compute node ntp.conf

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntp/ntp.drift

# Leap seconds definition provided by tzdata
leapfile /usr/share/zoneinfo/leap-seconds.list

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 192.168.4.100 iburst


# 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

Thus far, the above files seem to be working well.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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