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.
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 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?
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.