Messages in this thread | | | Subject | Re: This is the fourth time I've tried to find what led to the regression of outgoing network speed and each time I find the merge commit 8c94ccc7cd691472461448f98e2372c75849406c | From | mikhail.v.gavrilov@gmail ... | Date | Tue, 27 Feb 2024 22:08:20 +0500 |
| |
On Mon, 2024-02-26 at 19:09 +0100, Thomas Gleixner wrote: > we don't have any information about the overall workload,
During measurements nothing was running except iperf3
> other interrupt sources on CPU0 and their frequency. That'd need to > be investigated with instrumentation and might unearth some > completely different underlying reason causing this behavior.
I made simple bash script for benchmark enp14s0 on each of CPU core.
#!/usr/bin/env bash for i in {0..31} do smp_affinity=$(echo 'obase=16; '$((2 ** i)) | bc) echo "echo $smp_affinity > /proc/irq/84/smp_affinity" echo $smp_affinity > /proc/irq/84/smp_affinity echo 'iperf3 -c primary-ws.local -t 5 -p 5000 -P 1' iperf3 -c primary-ws.local -t 5 -p 5000 -P 1 done
And attach here results of iperf3 for kernels 6.7.0 and 6.8.0-rc6. Which once again makes sure that CPU0 is a bad option in both cases. And any other CPU does not necessarily 23 allow the network interface to operate at the limit of the capabilities of the network cable.
I also attach /proc/interrupts I hope this helps clear things up.
I don't know how else to help you. What information to provide.
About repeatability my "unlucky" scenario. I have two MSI MPG B650I EDGE WIFI motherboards and this problem happened both at the same time.
It seems the problem has always been there, we just never noticed it.
-- Best Regards, Mike Gavrilov. [unhandled content-type:application/zip][unhandled content-type:application/zip][unhandled content-type:application/zip] | |