On Thu Aug 21 2025, Miroslav Lichvar wrote: > On Thu, Aug 21, 2025 at 01:38:44PM +0200, Kurt Kanzenbach wrote: >> On Wed Aug 20 2025, Jacob Keller wrote: >> > On 8/20/2025 12:56 AM, Miroslav Lichvar wrote: >> >> But when I increase the rate to 200000, I get this: >> >> >> >> 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 > >> Miroslav, can you test the following patch? Does this help? > > It seems better than with the original patch, but not as good as > before, at least in the tests I'm doing. The maximum packet rate the > server can handle is now only about 5% worse (instead of 40%), but the > the number of missing timestamps on the server still seems high. > > With the new patch at 200000 requests per second: > NTP daemon TX timestamps : 192404 > NTP kernel TX timestamps : 1318971 > NTP hardware TX timestamps : 418805 > > I didn't try to adjust the aux worker priority.
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. Thanks, Kurt
signature.asc
Description: PGP signature
