Why is the * symbol taking a long time to show up in 'ntpq -p' output?
1
vote
2
answers
547
views
I'm working on a C application that requires NTP time to be synchronized on the host before proceeding. I've essentially written a wrapper C function that executes the command
ntpq -p
If the output contains the * character, I consider that be connected and ready to proceed. An example output where NTP is successfully synchronized :
remote refid st t when poll reach delay offset jitter
==============================================================================
*myserver.domain.com xxx.xxx.xxx.xxx 2 u 729 1024 377 1.120 -1.834 2.282
If the output **DOES NOT** contain the * character, my program goes to sleep for a second and then checks again. This process repeats until the * character is found.
However, I've noticed on one of my machines the * character takes a long time to finally show up (~5 minutes) after a reboot. Yet it seems to have been synchronized successfully much sooner. In other words, when I issue a datetime
, it shows a seemingly correct time that must have been grabbed from the NTP server yet the * character does not appear until minutes later.
This negatively affects my application because it essentially cannot run for 5 minutes after a system restart.
I use the 'iburst' option in my ntp.conf file hoping that it would synchronize things quickly.
# my NTP server config
server myserver.domain.com iburst
Again, IT DOES seem to synchronize fast, yet the ntp -q
output takes a while until it reports the * character.
Any idea on how I can resolve this behavior? Additionally - is there a better command for checking if the NTP synchronization has been completed?
**Edit #1: Adding some more info**
I've learned from Chris Davies response that ntpd requires 8 successful polls before it is considered synchronized. This explains why my clock is seemingly correct even though it isn't synchronized. What DOES NOT make sense is why its polling on start-up so slowly, even though I have the iburst option set.
I'm noticing that the refid = .STEP. on initial startup. I'm not sure if this relevant since it just means the initial synchronization was very large.
**Edit #2: Here is the full sequence**
1. Host boots up - it appears that initial NTP sync occurs and the change is very large hence refid = .STEP.
2. After a while, refid updates the IP address of my NTP server. However, it's still considered unsynchronized because 8 consecutive successes have not occurs. And it's only polling every 64 seconds hence the long sync time. NOTE: I DO HAVE IBURST ENABLED THOUGH!!!
3. If I restart the NTP daemon service, it comes back up and synchronizes immediately. As if iburst is now working fine.
4. It's almost as if the iburst option is failing when NTP daemon starts after a reboot. But then works fine if the service is restarted.
Asked by Izzo
(1013 rep)
Mar 4, 2024, 04:44 PM
Last activity: Mar 8, 2024, 06:51 AM
Last activity: Mar 8, 2024, 06:51 AM