1

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.

7
  • At the point where you think it's synchronised but you don't see the *, what does the Reachable value show? It won't be considered truly synchronised (i.e. *) until you get 377, and this can take several cycles of Poll seconds Mar 7 at 13:12
  • Don't forget that you can use ntpq -np rather than ntpq -p so that you avoid getting caught on DNS lookups Mar 7 at 13:13
  • @ChrisDavies - When I believe it to be synchronized, reach equals 0. I wait a bit and then reach equals 1 (but still no star). I tried the ntpq -np option with no luck either. It appears that reach is incrementing by 1 every 20 seconds or so.
    – Izzo
    Mar 7 at 14:21
  • Please don't post pictures of text Mar 7 at 22:59
  • @ChrisDavies - i've removed the pictures.
    – Izzo
    Mar 7 at 23:15

2 Answers 2

2
+50

Does your system use an initramfs? If it does, have you updated it after modifying ntp.conf? If you haven't, the system might be starting ntpd early in the boot process using an old version of the ntp.conf stored in initramfs... which might explain why the iburst option seems to get ignored on boot.

When restarting ntpd, the up-to-date version of ntp.conf gets used, and so the iburst option will be honored.

If the initial sync always causes a very large change (refid = .STEP. as you said), see if your distribution allows you to run ntpdate at boot just before starting ntpd. The idea would be that ntpdate would take care of the large step, and then ntpd would get to start with a system clock that is already very close to the correct time, ideally allowing the iburst to succeed without a step change.

1

The NTP client won't consider itself synchronised until it has a server Reachable value of 377. This is an eight bit shift register, and on each Poll cycle a value of 0 or 1 indicating whether the remote server is reachable or not is shifted into the lowest bit. The octal value 377 represents 11111111 (eight consecutive successful reads of the remote server).

At the point this happens you'll get a * next to the selected "truechimer" (a server delivering plausible time), and + next to other "truechimers" that are also fully reachable but not currently selected.

Ideally, you should have an odd number of remote NTP servers, and more than one. Three is a good number, and for me using Pool servers they might look like these:

0.pool.ntp.org
1.pool.ntp.org
2.pool.ntp.org
2
  • I can see that my polling interval is 64 seconds and it transitions to * after 8 successful packets (i.e. Reach = 377). However, I am now confused why my iburst option is seemingly getting ignored on this machine. If I restart the ntpd daemon - it seems to work on subsequent startups. Are you aware of any oddities when using the iburst option?
    – Izzo
    Mar 7 at 21:55
  • I've updated my question with more information on the behavior I'm seeing. Specifically edit #2.
    – Izzo
    Mar 7 at 22:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .