Synchronization issue after a server redate

Client Configuration and Development
1

Hello everyone,

I have been trying for several days to set up an NTP daemon that is capable of:

  1. Perform the 1st synchronization with the server, regardless of the time difference between the server and the client.
  2. Remain synchronized with the server even if the latter is updated with a new time (not exceeding the limits set by the NTP standard that could cause a daemon panic).

For the 1st synchronization, I configured the daemon with the “-g” option, which allows the 1st jump to be made without sanity check. And it works, quite well.

My problem concerns the second point. The behavior I expect, and which seems to me to be the nominal behavior, is as follows:

If the client is more than 0.128s behind the server, synchronization stops for a period of time defined by the stepout parameter (default: 300s). After this time, the new time sent by the server is taken into account.

Behavior I’ve observed :
The client does stop synchronization with the server. However, after 300s, synchronization has still not resumed (the reference timestamp is not updated). After about 10 minutes, the reference timestamp is updated, but not with the server’s time. In addition, we observe that the root dispersion is equal to 300s. If we look at the evolution of root dispersion over time, we can see that it is gradually decreasing…
I’ve read that excessive root dispersion (>1s) leads to a loss of “reliability” on the part of the client towards the server. So I can understand why the synchronization stopped. On the other hand, I find it hard to understand why the client didn’t simply take this new time into account directly after the stepout, as the standard explains…

NTP_Troubleshooting
NTP_Troubleshooting1514×418 165 KB

I’m also sharing the configuration (ntp.conf) I use. You’ll see that I don’t do anything specific …

#This is ntp server config

driftfile /ram/ntp.drift

# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.
restrict default nomodify notrap nopeer noquery

server X.X.X.X iburst minpoll 6 maxpoll 7 prefer
disable auth

My questions are as follows:

  1.   Does the behavior I'm observing correspond to the NTP's nominal behavior?

  2.   Is it possible to modify the NTP client configuration to obtain the "nominal behavior" described above?

Many thanks for any help you are able to provide.

2

Maybe something like timesyncd would be less critical and more blindly trusting of its time source? Or do you need a full NTP daemon?

3

Thank you for your answer. Indeed, time synchronization must be done through an NTP daemon.

What I’m having trouble understanding is that the behavior I’m expecting seems to be the nominal behavior … Am I wrong?