4

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?

  • 1
    How does your /etc/ntp.conf look like? You may want to add that to your question. Check if you have the iburst option in the lines starting with server or pool which should speed up the initial time sync. – Thomas Jan 13 '18 at 9:25
  • You need to edit the question to provide that, and to also give answerers actual numbers. State how far adrift your clock is at bootstrap. Show them the logs of your ntpd service over the service restart. – JdeBP Jan 13 '18 at 10:19
  • @JdeBP If it a rpi, it will be very adrift, as it does not have a RTC. See my answer. – Rui F Ribeiro Jan 15 '18 at 14:19
  • It is a PiFace brick with a CR1220 battery – Susanne Jan 15 '18 at 16:37
  • The questioner has just told you that it does have an RTC. (-: – JdeBP Jan 15 '18 at 17:08
3

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

  • Thanks a lot for the fast answer Okay, I bought already a RTC, sorry I forgot to tell. And I tried it with the „tinker panic 0 option“ and it doesn’t make it faster. – Susanne Jan 15 '18 at 16:08
1

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

0

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.

  • More complicated, as you have to make sure ntpdate runs before ntpd goes up. – Rui F Ribeiro Jan 15 '18 at 14:17
  • Okay, I‘m not sure if I understand it clearly. What is the RPM package and how can I get sure that the ntpdate runs before ntpd? And for testing I made just a drift of 20 min to the current time. – Susanne Jan 15 '18 at 16:02
  • You don't really need ntpdate. There's the fake-hwclock package already installed as a standard part of RPi distributions to get the clock correct to a reasonable approximation prior to NTP kicking in. – roaima Jan 15 '18 at 16:05
  • My fake-hwclock is really close to the real time. Because when I put on the write access the fake-hwclock is updated before the Pi shuts down. So now is approx. a 2h drift – Susanne Jan 15 '18 at 16:34

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.