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. -- Miroslav Lichvar
