We currently have a redundant pair of X20 controllers configured as NTP time server, using their internal clocks as the time source and with the stratum level set to 3.
Our redundant APROL runtime PCs are configured as NTP clients to these controllers. However, we’re experiencing significant delays in time synchronization — in some cases, it can take several hours for the clients to update. During the synchronization process, we’ve also observed instances where the system clock on the APROL runtime appears to freeze, which in turn leads to further issues within the system.
Has anyone encountered similar behaviour with this setup? I’d appreciate any guidance or recommendations on how to troubleshoot and fine-tune the NTP client configuration on the APROL side to achieve more reliable and timely synchronization.
hi，Dale
I remember it seems that the configuration of NTP can be manually configured in YAST, but I really can’t remember clearly. Maybe you can check it out.
Thanks for your response. I’m a bit unclear about which NTP service the APROL system actually uses — does it rely on standard Linux services like chronyd or ntpd, or does it have its own built-in mechanism for handling time synchronization?
Of course, by default, NTP refuses synchronization if the time difference exceeds 1000s. You can add parameters to adjust this limit, such as the straightforward tinker panic 0
Or, after detecting that NTP has stopped, directly use ntpdate to force synchronization and then start ntp again. If you can accept the risk of time jumps or time repetitions.
As far as I’m concerned the only configuration we have implemented for the NTP Client is in APROL config as shown below. Our NTP server is 172.16.1.20.
This is the configuration setup we currently have for the Controller acting as the NTP server. The controllers configured as NTP clients synchronize relatively quickly and without issue. However, we are experiencing delays with the redundant runtime PCs and operator station, which take significantly longer to synchronize.
Noticed some improvement in the Synchronisation speed, now looks to be less than 10 minutes which is much better, So thank you for that.
However this only seems to work when going forward in time, when going back in time the APROL system time seems to freeze. Once frozen the only way to restart the APROL time is by stopping and starting Runtimes using Start manager, which is not ideal.
I feel like this may be another issue that I may have to raise as a support ticket.
You can check the NTP status of your APROL server in command line with “ntpq -p”.
No additional configuration in Yast should be necessary for NTP configuration if you have configured NTP in AprolConfig.
For redundant Runtime Servers it is recommended that they are configured to each other (additionally to another time source) . Means the Master has configured the Client Server as NTP Server and vice versa.
Thanks for the response. I have updated the configuration and the two runtime servers are now pointing at each other as well as the NTP server. Unfortunately still seeing the APROL system time freezing when trying to go backwards in time.
