On Tue, Feb 21, 2023 at 11:37:05AM -0800, Matt Corallo wrote: > Specifically, on a 1GHz amd64 AMD GX-412TC with a few PHC refclocks > being polled, a main loop iteration can take a millisecond or two, > depending on the time taken to read the PHC clocks. This easily > adds up to poll interval slippage, slipping the update interval and > leading to samples which are ignored due to missing their > maxlockage setting.
Is the occasional missing sample causing any issues? Have you tried increasing maxlockage? The slippage is intentional. It nicely avoids the "skipping poll window" issue you are handling in your code and gives the process time to do other things in case the refclock polling is too slow/too frequent. It doesn't seem right to me to be doing something periodically at exactly the same fraction of the second. There could be other things running on the system doing that, e.g. heavy network activity loading the PCIe bus, which could impact the PHC readings of chronyd, or just multiple instances of chronyd trying to read the PHC at the same time. If the alignment of the intervals was fixed, these collisions could be much more frequent than if one or both were randomly moving. This would be like NTP clients polling the server at the same second of a minute, causing spikes in the network and server load, impacting quality of their measurements. This is a common issue observed on public servers due to people starting ntpdate/chronyd -q from cron. -- Miroslav Lichvar -- To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
