[Solved] 802.11ax worse than 802.11ac with mt76 driver?

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.

I see. However, if the server is connected to the router wired, we cannot test the full performance, no? Since wired is limited to 1000 Mbit/s?

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.


"Unsolving" the topic.

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

I saw between 7-45 Mbit/s on a iPhone 13 Mini with a wall and floor between and get around 200 something before the latest mt76 update today.


Ouch :frowning: FWIW I just tested to one of my APs that was ~25 feet away with two walls and a heavy wooden door in-between. Got 407 Mbps down and 345 Mbps up.

@Anteus Are you sure your device was connected via 5ghz (specifically ax) and not 2.4ghz?

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?

Additional context for the interested:


1 Like

Thanks. If possible test with tomorrow's (3/3) snapshot to confirm my results.

Yes as I have the phone to not even auto connect to 2.4.

Regarding BSS color only 1-63 is valid and anything outside of that should trigger it to randomly pick one between 1-63.

Understood. But what mechanism is built in to ensure two (or more) APs don't randomly get assigned the same BSS color?

Maybe I'm old-school, but it just seems like such an easy thing to manually set on each AP to ensure no collision.

I think it would be 1/63 * 1/63 = 0,00025 about 0,025%

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.

Works fine here with a RT-AX53u and an Archer C50v1.

And it takes < 10 seconds to completely eliminate even those odds. I think we'll have to agree to disagree on this one. :slight_smile:

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.

It's been available since this afternoon.

I can confirm that my wife's 2021 MBP went back to slow upload speed.

1 Like

@jkdf2 @Anteus have you changed anything in your configuration after the upgrade? Is it completely similar to before the upgrade?

Please copy the output of the following commands and post it here using the "Preformatted text </> " button.

Remember to redact passwords, MAC addresses and any public IP addresses you may have:

cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall

Also please provide detailed info about your clients that experience slow speed (e.g. link to vendor website).