dhcpcd-discuss

Thank u all to both Roy and Neal for the very detailed explanation about
this topic. Really appreciated.

Stefano

Il mer 22 gen 2020, 01:15 Neal P. Murphy <neal.p.murphy@xxxxxxxxxxxx> ha
scritto:

> 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
>