The ntpd man page says the following:
'ntpd will stay for a maximum of 15 seconds in the foreground
and make efforts to verify and correct the time
if constraints are configured and satisfied or
if trusted servers or sensors return results,
and if the clock is not being moved backwards.'.

I could be wrong, but I believe there's another condition
that isn't mentioned. 
As far as I can tell, if the clock is behind less than 60 seconds, 
ntpd will not update the clock. 
In /var/log/daemon, you will see the message:
'cancel settime because offset is negative or close enough'.
The key part being 'close enough'.

I believe the relevant file here is client.c. 
This file pulls the 'AUTO_THRESHOLD' value from ntpd.h.

My question is what's the logic here for having this threshold?
If you have a device that just booted and
it's behind the current time, regardless of the duration,
why not just update the clock to the time from the time server?

I realize this is probably very minuscule,
but it's something I've run into several times.
I've got some devices without real-time clocks. 
Therefore, when I reboot them, they reboot in less than 60 seconds. 
When they come back, the clock isn't synced,
so I manually update the clock to speed up the sync process.

To me, this isn't a functionality problem.
The time is close enough that it shouldn't cause any problems.
However, I see this as more of an administration problem. 
NTP is probably something you want to ensure is working correctly.
Some of the values you might validate are datetime, peers, and clock.
In this scenario, datetime is off by less than 60 seconds,
so you might not even notice it. 
All peers should be valid, so there shouldn't be a problem there.
However, the clock will show as unsynced.
Even with a less than 60 second difference, it can take quite a long
time for the clock to be synced, which would require investigation
from an administration standpoint if you're monitoring this. 

I'm not saying this should be changed, but I just don't understand
the reason for the threshold and given the threshold has required
intervention on my part on several occasions, I'm curious as to the
thought process of this value. Thanks.

Reply via email to