dhcpcd-discuss

On Tue, 21 Jan 2020 22:49:26 +0000
Roy Marples <roy@xxxxxxxxxxxx> wrote:

> 	Hi
> 
> On 21/01/2020 09:23, Stefano Cappa wrote:
> > Hi Roy,
> > I'm not an expert about this topic and I have a question about NTP via DHCP as 
> > described in RFC 2132.
> > Basically, my device with dhcpcd 8.1.x (or later when released) must use a NTP 
> > server via DHCP if provided, otherwise it must use an external server as a fallback.
> > This behaviour is an external requirement and I have to check if it's currently 
> > working in this way, but I really don't know how.
> > 
> > How can I check if this behaviour is right? How can I specify a working NTP 
> > server via dhcpcd and check if it will have higher priority than external servers.
> > 
> > I'm sorry for the bad explanation, but I don't have other information, because 
> > for me this topic is totally new.  
> 
> OK
> 
> All dhcpcd does is take a DHCP message, parse it's options and pass that to the 
> hooks.
> dhcpcd supplies a NTP hook which adds any NTP server given to the system 
> ntp.conf file. If a following message no longer supplies this then it is removed.
> 
> NTP decides the *best* server itself by measuring data from NTP servers in the 
> config.
> 
> You might be able to achieve what you want by supplying no NTP servers in the 
> default ntp.conf and in /etc/dhcpcd.enter-hook set the variable new_ntp_servers 
> if it's not already set - something like this
> 
> # Default NTP servers if non supplied
> # This ensures that if DHCP supplies some, only they are used
> if [ -z "$new_ntp_servers" ]; then
> 	new_ntp_servers="192.168.0.1 10.0.0.1"
> fi
> 
> But this means the servers can't be used as a fallback if the ones given by NTP 
> don't work. If that's critical then you have to convince NTP in ntp.conf, which 
> is outside the scope of dhcpcd.

To expand on this, a bit of history is needed. This is outside this list's purpose, but may help Stefano to better understand NTP in general.

In the 'early' days of NTP, the daemon would get the time from some upstream server and set its system clock to it. It might even check that server from time to time and adjust the local clock as needed. But eventually it was determined that this wasn't good enough, largely for two reasons. One reason was that this operation could cause large jumps in the local clock, including backward jumps; such erratic clock behavior could cause undesired system operations. Another reason is that nearly all system oscillator chips are either slow or fast; slow chips could result in significant forward jumps in time, and fast chips could cause significant backward jumps in time. So Linux was changed to allow the system to control 'ticks per second' in order to better synchronize the system clock with 'real' time. And ntpd operation was changed to make it happen.

Today's NTP daemons rely on several upstream servers to find and use the 'best' reference. They will then either slow down or speed up the clock so that it will eventually align with the chosen upstream server. Once the system clock is synchronized, the daemon periodically check to ensure the clock has remained synched. The result is that the system clock is usually around 12 microseconds of correctly following the passage of time and having the correct time, and there are no large jumps in time. For most Linux systems, 12µs is close enough. The clock rate adjustments (faster or slower) are usually down around 50ppb (parts per billion, or 50 nanoseconds).

When I finally understood this, I modified Smoothwall Express to (1) hard set the system clock early during bootup, (2) to run the NTP daemon using four upstream server: {0,1,2,3}.pool.ntp.org; their DNS server chooses these servers to be near (on a planetary internet scale) the system using them, and (3) to allow the admin to specify a local server if the location has one for the facility (the assumption being that the local NTP server will be more, mmm, consistent than external servers). Almost immediately, internal system clocks became much more stable and consistent.

Returning to Stefano's problem, he could use the server provided via DHCP in addition to at least four external servers. (It's akin to the GPS system where the more satellites you see, the more accurate your position report will be.) As to verification, Stefano should be able to
  grep -i ntp /var/log/messages
to see which servers are valid or invalid, and how much the clock rate is adjusted. (But check the syslog config; NTP logs might be directed somewhere else.)

I would suggest hard-configuring the local server and four pool servers rather than relying on DHCP. Neither daemon (openntpd or ntpd) seems to have an easy way to change the configured servers without restarting the daemon, and restarting means going through the synchronization process again which can take more than several minutes (up to 20 minutes, IIRC). The daemons are usually fairly smart in handling communications with upstream servers.

In short, use not fewer than four servers all the time; the daemon will determine the best one to use. The system will have a clock that is stable to around 50µs which is good enough for most Linux purposes.

N