On Thu, Aug 21, 2025 at 04:08:02PM +0200, Kurt Kanzenbach wrote: > On Thu Aug 21 2025, Miroslav Lichvar wrote: > >> >> Without the patch: > >> >> NTP daemon TX timestamps : 35835 > >> >> NTP kernel TX timestamps : 1410956 > >> >> NTP hardware TX timestamps : 581575 > >> >> > >> >> With the patch: > >> >> NTP daemon TX timestamps : 476908 > >> >> NTP kernel TX timestamps : 646146 > >> >> NTP hardware TX timestamps : 412095
> > With the new patch at 200000 requests per second: > > NTP daemon TX timestamps : 192404 > > NTP kernel TX timestamps : 1318971 > > NTP hardware TX timestamps : 418805 > Here's what I can see in the traces: In the current implementation, the > kworker runs directly after the IRQ on the *same* CPU. With the AUX > worker approach the kthread can be freely distributed to any other > CPU. This in turn involves remote wakeups etc. > > You could try to pin the PTP AUX worker (e.g. called ptp0) with taskset > to the same CPU where the TS IRQs are processed. That might help to get > the old behavior back. Adjusting the priority is not necessary, both the > kworker and AUX thread run with 120 (SCHED_OTHER, nice value 0) by > default. Yes, that helps! The server timestamping stats now show: NTP daemon TX timestamps : 32902 NTP kernel TX timestamps : 1479293 NTP hardware TX timestamps : 520146 And the maximum response rate is only about 2-3% lower, so that looks good to me. Thanks, -- Miroslav Lichvar
