NTP time sync takes a long time

Question

I use a Raspberry Pi 3 and need to update the time via ntp after reboot the system.

It should be updated via wifi with dhcp. Generally it works, but the synchronisation needs approx. a half an hour and I don’t understand why.

When I want to start the ntp service manually with

>>sudo /etc/init.d/ntp restart

It says „ok“, but the system does nothing - the wrong time is still on the RTC.

Do you have an idea, what could be the problem?

Another information is, that the Pi runs in the read only mode...but if its not working without write access it wouldn’t be updated after an half hour, isn’t it?

More details:

To complete my problem here is the ntp.conf:

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

Driftfile /var/lib/ntp/ntp.drift

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 0.de.pool.ntp.org iburst
Server 1.de.pool.ntp.org iburst
Server 2.de.pool.ntp.org iburst
Server 3.de.pool.ntp.org iburst

Server 127.127.1.0 #local clock
Fudge 127.127.1.0 stratum 10

...

To expand my explanation about my project. I want to use the Pi as a NTP server. The first problem was that the RTC „runs away“ after a reboot or when the Pi is turning off - especially for a longer time. That’s why I had the idea, that the Pi should be a NTP client at the first time to set the RTC and after that the Pi needs to be a NTP server for the device, which is connected via ethernert with the Pi. So I connected the Pi via Wifi to get the current time. As I told already generally it works, but it takes too much time.

Then I wanted to make the synchronisation manually with this command I posted before. My idea was to do this as a cronjob, but there is the next problem: 1. the Pi ignored the command; 2. the cronjob is ignored, too, or deleted after a reboot.

But I want to go step by step and the first problem I want to solve is to decrease the sync time.

I hope you have a better overview now about my situation....

Do you need more details?

NEW INFORMATION: 01.02.2018

Okay, so I have now the solution I want, BUT there is a behavior, which I don’t understand. The configurations were correct. However, I use the onboard WiFi to synchronize the system time via a NTP server, which I configured in the ntp.conf. I use the ethernet (wired LAN) to be the NTP server for the wired device to the RPi. Here the IP settings:

WLAN (DHCP): 192.168.1.x
Ethernet (static): 192.168.10.10

I put both interfaces in different networks, because otherwise just one connection would be work - But why actually? And this is the main problem, why the synchronization had taken so long time. When I comment out the line with the local clock

Server 127.127.1.0

Then the synchronization over the network works immediately... Why it is happens?

Answer 1

The rpi does not have an RTC, and so it boots always in 1 Jan 1970 - the time to put the server and NTP synchronised slowly and incrementally is bigger; so by default NTP does not start operating normally until the difference between NTP and the system is corrected.

I would add to your ntp.conf file as the first line (it has to be the first line):

tinker panic 0

This setup is advised for VMs and iOTs devices.

tinker panic - Specifies the panic threshold in seconds with default 1000 s. If set to zero, the panic sanity check is disabled and a clock offset of any value will be accepted.

I would also consider buying an RTC, as it is cheap, especially if you intend to have projects without Internet connectivity. see hwclock can't open rtc file

Answer 2

This problem was solved for me by adding "flag1 1" to the fudge lines in /etc/ntp.conf. We are using GPS to set the time. If the system clock battery gets run down the system will not start up with the right time. We need NTP to quickly fix it. Here is our /etc/ntp.conf file:

# "flag1 1" means skip the difference limit check and fix the time even if it is far off.
# If the battery for the system clock fails the system clock will start with a default time.
# The date will be years off, more than the sanity check limit, we need for ntp to correct the time anyway.
#
# GPS Serial data reference
server 127.127.28.0 minpoll 4 maxpoll 4 true
fudge 127.127.28.0 time1 0.0 refid GPS flag1 1

# GPS PPS reference 
server 127.127.28.1 minpoll 4 maxpoll 4 prefer true
fudge 127.127.28.1 refid PPS flag1 1

driftfile /var/lib/ntp/drift

# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery limited
restrict -6 default kod notrap nomodify nopeer noquery limited

# Allow unrestricted acces from the localhost
restrict 127.0.0.1 mask 255.255.255.0
restrict -6 ::1

# 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 disable
filegen clockstats file clockstats type day enable

I found this solution here: NTP Documentation

Answer 3

Use the ntpdate utility as a once-a-boot utility to get the clocks close enough for ntpd to manage.

If your distro has it, check the chrony RPM package; it is easier to manage than classic NTP.