On Thu, Mar 27, 2025 at 10:22:31AM +0100, Thomas Gleixner wrote:
On Tue, Mar 25 2025 at 12:32, Miroslav Lichvar wrote:
Resetting the NTP error causes a small time step. An NTP/PTP client can be setting the frequency very frequently, e.g. up to 128 times per second and the interval between updates can be random. If the timing
I never observed that behaviour, but I'm not a NTP/PTP wizard/power user.
On a machine that has a /dev/ptp device available, a simple test to observe such a high update rate is to run:
1) phc_ctl /dev/ptp0 set 2) phc2sys -m -q -O 0 -s /dev/ptp0 -R 128 or alternatively 2) chronyd -d 'refclock PHC /dev/ptp0 poll -7'
The original implementation respected this base period, but John's approach of forwarding, which cures the coarse time getter issue, violates it. As a consequence the previous error accumulation is not longer based on the base period because the period has been reset to the random point in time when adjtimex() was invoked, which makes the error accumulation a random number.
I see, so that value of the NTP error is already wrong at that point where it's reset to 0.
To clearly see the difference with the new code, I made an attempt to update the old linux-tktest simulation that was used back when the multiplier adjustment was reworked, but there are too many missing things now and I gave up.
Maybe I could simply patch the kernel to force a small clock multiplier to increase the rate at which the error accumulates.