The iperf3 process requires a lot of CPU cycles while actively running a test. This is particularly true if iperf3 is the sender. So as the bandwidth coming in, or going out, of iperf3 increases (which one would want for a bandwidth test), it begins contending for CPU.
There becomes a "choke point" where it competes for CPU (more noticeable on lower-spec hardware) that is otherwise needed to handle IRQs for the wireless transmissions. In that case, you've created a bottleneck where either iperf3 will suffer or wireless throughput will suffer. In either case, the throughput test becomes inaccurate.
It's a valid question, for sure. Personally, I have never seen AX wireless even hit 900mbps. But I suppose if someone really wants to test the limits, perhaps an AX-to-AX client test across the same AP would be valid. (??)
Yes, for most devices nowadays 1000 Mbit/s would be limit, but if you really have the need, devices with 2.5GBase-T, 5 GBase-T or even 10 Gigabit are out there. OpenWRT supports some of these devices, but they are hard to find in the table of hardware, because a specific column is lacking.
Anyway, we digress.
@jkdf2 If you want to have a theoretical discussion about how to properly test your wifi throughput / latency, you can do it in the following thread: Best practices and tools for measuring wifi performance. There also are some further pointers where to run your testing tool in this comment over there.
These options are no longer needed in snapshot, because it is already fixed and enabled by default and now when you don't add the "he_bss_color" option, it forces a random BSS color number during the execution time.
The 802.11ax upload problem is back in the current master builds (I just did my build from master).
It seems that the mt76 update to last version (commited today March 2, 2023) somehow reverted the fix that had solved this issue, and the problem is back again in current master builds.
@nbd I'm wondering if this commit may have caused this regression:
The official snapshot builds starting tomorrow (2023-03-02) will likely re-introduce this issue.
What upload speed are you seeing on your latest build? I just updated my 3x RT3200s from @nbd's commits from today and I'm still getting 700+ Mbps down and 500+ Mbps up on my iPhone 12 (802.11ax 2x2).
The he_bss_color should be unique for each 5Ghz radio, right? So if you have multiple APs, you would not want to rely on the fixed value (default) in the commit you referenced. That would guarantee collision on the BSS color between the APs, thus defeating the purpose of BSS color to begin with.
Do you have a different understanding of BSS color and could you share details if so?
Is someone meshing between 802.11ax and 802.11ac? For example if I have two ax routers and one ac router joins, the mesh completely breaks because of the ac router. Not sure what's happening.
Also more than two APs (or even multiple SSIDs?) per frequency presumably significantly increase the odds of collision. Relying on non-collision also seems a bit unsatisfactory to me. So I'll be setting mine too I think.