Determining when NTP is active

Question

I have a Python script that runs at startup and needs the correct time in order to function properly. I have setup the raspi-config to wait for a network connection before continuing so the code won't run until there is an internet connection (I think!). However, I have noticed that after a reboot it may take several seconds after the Python code gets started before the system gets around to running the NTP process that updates the system clock.

Is there some way to test to see when the internal clock gets updated by the NTP process? Is there some resource that keeps track of the last NTP time sync event? And how often does the RPi resync its clock using the NTP (daily, hourly weekly)?

Answer 1

1. ntpstat Show network time synchronisation status

pi@Pi3-01:~ $ ntpstat synchronised to NTP server (193.228.143.24) at stratum 3 time correct to within 84 ms polling server every 1024 s

And with pythons ntplib you can get the NTP status.

2. The poll time (in seconds) is shown in the column poll when you type the command ntpq -p

pi@Pi3-01:~ $ ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *ntp8.flashdance 193.11.166.20 2 u 162 1024 373 28.540 0.994 4.545 +195.78.244.34 62.149.0.30 2 u 106 1024 375 87.132 -1.339 5.561 +tethys.hot-chil 193.67.79.202 2 u 759 1024 377 58.820 -1.213 3.116 +sundown.speedwe 87.242.168.84 2 u 59 1024 377 59.788 0.605 3.521

3. How often does it sync the time?

Initially every 64th second, if the time is stable, the poll time will increase, and vice versa if it differ to much.

From: http://doc.ntp.org/4.1.0/ntpd.htm

How NTP Operates

The ntpd program operates by exchanging messages with one or more configured servers at designated poll intervals. When started, whether for the first or subsequent times, the program requires several exahanges from the majority of these servers so the signal processing and mitigation algorithms can accumulate and groom the data and set the clock. In order to protect the network from bursts, the initial poll interval for each server is delayed an interval randomized over 0-16s. At the default initial poll interval of 64s, several minutes can elapse before the clock is set. The initial delay to set the clock can be reduced using the iburst keyword with the server configuration command, as described on the Configuration Options page.