Re: [RFC PATCH 0/1] timekeeping: Don't charge NTP frequency changes to ntp_error

[Wang, Yuan1]

On 11/6/2026 12:29 AM, David Woodhouse wrote:
>> Yeah, timekeeping_set_reference() doesn't care. It's going to reset
>> ntp_error *after* changing the tick_length anyway.
>>
>> I think your patch is functionally identical to the one I've already
>> posted in 
>> https://lore.kernel.org/all/20261001202134.33929-2-dwmw2@xxxxxxxxxxxxx/ ;?
> Not *quite* functionally identical; I think your version misses the
> ntp_error updates that we *should* be doing, when tick_length changes
> while a skew is active? Mine compensates only for the tick_length part,
> which I think is correct?
Yes, you're right. When tick_length and the skew change in the same
update, mine skips charging the skew change as well, but it should
still be accounted. Yours only compensates for the tick_length part,
which is correct. Please drop my RFC.
> I'm due to send v2 of that series; please could you test that, and I'll
> add the appropriate Fixes: and Cc: stable with your Tested-by:.
Sure, I'll test v2 when it's out and reply there.

In the meantime, here are the results for patch 1 of v1 on its own, on
top of v7.3 (Intel mainline-tracking v7.3; kernel/time is identical to
upstream v7.3). The setup is the same as in my RFC: two Intel i226
NICs back to back with gPTP (ptp4l + phc2sys on each end),
PREEMPT_RT, HZ=1000, TSC. The grandmaster's PHC is stepped by +1s three
times, 400s apart. The numbers are the time until the phc2sys offset
stays below 100ns:

                                        GM phc2sys          slave phc2sys     slave ptp4l
  v7.3                              207/>361/>413s  114/79/293s      34-35s
  v7.3 + my RFC             32/32/32s             41/40/40s          34-35s
  v7.3 + your v1 1/5     32/32/32s             40/41/41s           34-35s

">" means it had not settled before the next step.

Before the steps, phc2sys holds about 8ns rms on both ends, the same

as without the patch.

Thanks

Yuan