NTP time sync takes a long time
Clash Royale CLAN TAG#URR8PPP
up vote
3
down vote
favorite
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?
linux network-interface ntp
asked Jan 13 at 9:14
Susanne
162
add a comment |Â
up vote
3
down vote
favorite
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?
linux network-interface ntp
asked Jan 13 at 9:14
Susanne
162
1
How does your/etc/ntp.conflook like? You may want to add that to your question. Check if you have theiburstoption in the lines starting withserverorpoolwhich should speed up the initial time sync.
– Thomas
Jan 13 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 yourntpdservice over the service restart.
– JdeBP
Jan 13 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 at 14:19
It is a PiFace brick with a CR1220 battery
– Susanne
Jan 15 at 16:37
The questioner has just told you that it does have an RTC. (-:
– JdeBP
Jan 15 at 17:08
add a comment |Â
up vote
3
down vote
favorite
up vote
3
down vote
favorite
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?
linux network-interface ntp
asked Jan 13 at 9:14
Susanne
162
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?
linux network-interface ntp
asked Jan 13 at 9:14
Susanne
162
edited Feb 1 at 10:41
asked Jan 13 at 9:14
Susanne
162
asked Jan 13 at 9:14
Susanne
162
asked Jan 13 at 9:14
Susanne
162
162
1
How does your/etc/ntp.conflook like? You may want to add that to your question. Check if you have theiburstoption in the lines starting withserverorpoolwhich should speed up the initial time sync.
– Thomas
Jan 13 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 yourntpdservice over the service restart.
– JdeBP
Jan 13 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 at 14:19
It is a PiFace brick with a CR1220 battery
– Susanne
Jan 15 at 16:37
The questioner has just told you that it does have an RTC. (-:
– JdeBP
Jan 15 at 17:08
add a comment |Â
1
How does your/etc/ntp.conflook like? You may want to add that to your question. Check if you have theiburstoption in the lines starting withserverorpoolwhich should speed up the initial time sync.
– Thomas
Jan 13 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 yourntpdservice over the service restart.
– JdeBP
Jan 13 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 at 14:19
It is a PiFace brick with a CR1220 battery
– Susanne
Jan 15 at 16:37
The questioner has just told you that it does have an RTC. (-:
– JdeBP
Jan 15 at 17:08
1
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 at 9:25
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 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 at 10:19
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 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 at 14: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 at 14:19
It is a PiFace brick with a CR1220 battery
– Susanne
Jan 15 at 16:37
It is a PiFace brick with a CR1220 battery
– Susanne
Jan 15 at 16:37
The questioner has just told you that it does have an RTC. (-:
– JdeBP
Jan 15 at 17:08
The questioner has just told you that it does have an RTC. (-:
– JdeBP
Jan 15 at 17:08
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
2
down vote
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
answered Jan 13 at 11:25
Rui F Ribeiro
35.3k1270113
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 at 16:08
add a comment |Â
up vote
0
down vote
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.
answered Jan 14 at 16:37
Oldest Software Guy
1672
More complicated, as you have to make sure ntpdate runs before ntpd goes up.
– Rui F Ribeiro
Jan 15 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 at 16:02
You don't really needntpdate. There's thefake-hwclockpackage 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 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 at 16:34
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
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
answered Jan 13 at 11:25
Rui F Ribeiro
35.3k1270113
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 at 16:08
add a comment |Â
up vote
2
down vote
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
answered Jan 13 at 11:25
Rui F Ribeiro
35.3k1270113
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 at 16:08
add a comment |Â
up vote
2
down vote
up vote
2
down vote
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
answered Jan 13 at 11:25
Rui F Ribeiro
35.3k1270113
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
answered Jan 13 at 11:25
Rui F Ribeiro
35.3k1270113
edited Jan 13 at 12:56
answered Jan 13 at 11:25
Rui F Ribeiro
35.3k1270113
answered Jan 13 at 11:25
Rui F Ribeiro
35.3k1270113
answered Jan 13 at 11:25
Rui F Ribeiro
35.3k1270113
35.3k1270113
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 at 16:08
add a comment |Â
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 at 16:08
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 at 16:08
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 at 16:08
add a comment |Â
up vote
0
down vote
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.
answered Jan 14 at 16:37
Oldest Software Guy
1672
More complicated, as you have to make sure ntpdate runs before ntpd goes up.
– Rui F Ribeiro
Jan 15 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 at 16:02
You don't really needntpdate. There's thefake-hwclockpackage 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 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 at 16:34
add a comment |Â
up vote
0
down vote
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.
answered Jan 14 at 16:37
Oldest Software Guy
1672
More complicated, as you have to make sure ntpdate runs before ntpd goes up.
– Rui F Ribeiro
Jan 15 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 at 16:02
You don't really needntpdate. There's thefake-hwclockpackage 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 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 at 16:34
add a comment |Â
up vote
0
down vote
up vote
0
down vote
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.
answered Jan 14 at 16:37
Oldest Software Guy
1672
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.
answered Jan 14 at 16:37
Oldest Software Guy
1672
answered Jan 14 at 16:37
Oldest Software Guy
1672
answered Jan 14 at 16:37
Oldest Software Guy
1672
answered Jan 14 at 16:37
Oldest Software Guy
1672
1672
More complicated, as you have to make sure ntpdate runs before ntpd goes up.
– Rui F Ribeiro
Jan 15 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 at 16:02
You don't really needntpdate. There's thefake-hwclockpackage 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 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 at 16:34
add a comment |Â
More complicated, as you have to make sure ntpdate runs before ntpd goes up.
– Rui F Ribeiro
Jan 15 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 at 16:02
You don't really needntpdate. There's thefake-hwclockpackage 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 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 at 16:34
More complicated, as you have to make sure ntpdate runs before ntpd goes up.
– Rui F Ribeiro
Jan 15 at 14:17
More complicated, as you have to make sure ntpdate runs before ntpd goes up.
– Rui F Ribeiro
Jan 15 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 at 16:02
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 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 at 16:05
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 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 at 16:34
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 at 16:34
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f416774%2fntp-time-sync-takes-a-long-time%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
How does your
/etc/ntp.conflook like? You may want to add that to your question. Check if you have theiburstoption in the lines starting withserverorpoolwhich should speed up the initial time sync.– Thomas
Jan 13 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
ntpdservice over the service restart.– JdeBP
Jan 13 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 at 14:19
It is a PiFace brick with a CR1220 battery
– Susanne
Jan 15 at 16:37
The questioner has just told you that it does have an RTC. (-:
– JdeBP
Jan 15 at 17:08