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

Why not try to find the actual cause for the regression? If there is any.

Default from vendor is no 160 MHz AX/AC at all and adding it breaks 80 MHz AX. The focus should be making sure the supported 80 MHz AX works and enable 160 MHz AC if it works with no side effects. I mean 160 MHz AX/AC was removed in snapshot and only later added back after a few users missed it and reported LGTM.

Would be nice to find the actual cause and fix that of course but that could be done with 160 MHz AC for mt7915!dbdbc chips disabled in the mean time.

EDIT: Looking through mt76 issues on Github I saw that rany2 is testing new firmware blobs which could be interesting to try if there's a fix for this issue in there https://github.com/rany2/mt76/tree/master/firmware
Issue https://github.com/openwrt/mt76/issues/776

1 Like

Your comment made me test again and compare Linux with Windows on the same machine.

I compared the AX to AC 80 MHz performance, with Linux, Windows and on Apple iPadOS, to see if my AX performance issue may be Linux wi-fi driver or firmware related. The iperf3 server now runs on a local Linux machine connected to the E8450 via LAN. The E8450 is now only tested for network performance.

Test environment:

  • Linksys E8450 (UBI), OpenWrt 23.05-SNAPSHOT r23042-3a1cb63336
  • Linux:
    • Debian11, kernel 5.10.0-23-amd64, up to date Intel AX201 firmware-iwlwifi 20210818-1
    • test command: iperf3 -c "iperf3-server" -t 60 -P 4 -i 10 [-R]
  • Windows:
    • Windows 11 22H2, up to date Intel AX201 WiFi driver 22.220.0.4 March 2023
    • Docker Desktop with WSL2 installed
    • test command: docker run -it --rm networkstatic/iperf3 -c "iperf3-server" -t 60 -P 4 -i 10 [-R]
  • Apple:

iperf3 test settings copied from Best practices and tools for measuring wifi performance

OpenWrt mode: AC 80 MHz

Linux client: Connection: 650.0 Mbit/s, 80 MHz, VHT-MCS 7, VHT-NSS 2, Short GI
Upload: [SUM] 0.00-60.00 sec 3.23 GBytes 463 Mbits/sec 135 sender
Download: [SUM] 0.00-60.01 sec 2.10 GBytes 300 Mbits/sec 180 sender

Windows client: connection: 650.0 Mbit/s, 80 MHz, VHT-MCS 7, VHT-NSS 2, Short GI
Upload: [SUM] 0.00-60.00 sec 3.33 GBytes 477 Mbits/sec 1187 sender
Download: [SUM] 0.00-60.01 sec 2.78 GBytes 398 Mbits/sec 45 sender

iPad client: connection: 650.0 Mbit/s, 80 MHz, VHT-MCS 7, VHT-NSS 2, Short GI
Upload: 254 Mbit/s
Download: 387 Mbit/s

OpenWrt mode: AX 80 MHz

Linux client: connection: 720.6 Mbit/s, 80 MHz, HE-MCS 7, HE-NSS 2
Upload: [SUM] 0.00-60.00 sec 1.40 GBytes 201 Mbits/sec 808 sender
Download: [SUM] 0.00-60.01 sec 1.38 GBytes 198 Mbits/sec 717 sender

Windows client: connection: 720.6 Mbit/s, 80 MHz, HE-MCS 7, HE-NSS 2
Upload: [SUM] 0.00-60.00 sec 3.27 GBytes 469 Mbits/sec 1372 sender
Download: [SUM] 0.00-60.01 sec 2.81 GBytes 402 Mbits/sec 0 sender

iPad client: connection: :melting_face:
34.0 Mbit/s, 80 MHz, HE-MCS 0, HE-NSS 1, HE-GI 1
612.5 Mbit/s, 80 MHz, HE-MCS 6, HE-NSS 2, HE-GI 1
Upload: 13 Mbit/s :skull:
Download: 316 Mbit/s

During the 5 minute download testing most of the time the AX iPad Luci RX rate display stays at 34 Mbit/s HE-MCS 0, but some short spikes of higher upload connection rates occur:
408.3 Mbit/s, 80 MHz, HE-MCS 4, HE-NSS 2, HE-GI 1
612.5 Mbit/s, 80 MHz, HE-MCS 6, HE-NSS 2, HE-GI 1

Sometimes during the test the AX iPad RX rate even drops to 24.0 Mbit/s, 20 MHz.

Summary:
Linux: my Debian11 Intel AX201 performance numbers in AX 80 MHz mode are still consistently lower than AC 80 MHz. But that may be a result from the older Linux kernel version or the iwlwifi-firmware from 2021, since the performance in Windows with the up to date Intel driver is on par for AX and AC.

Apple: the very low AX upload performance with my iPad seems to be related to a drop of the RX connection rate to MCS0 NSS1. I think this performance problem could be analyzed more by logging the RX connection from iOS and iPad devices from OpenWrt side during more iperf3 testing.

Is it known why the AX connection E8450 to iPadOS devices drops to HE-MCS0 NSS1 under significant packet load?

3 Likes

In February this issue was “magically” solved:

One month later the issue was back again:

The current hypothesis is that enabling 160Mhz in the driver is causing the issue:

2 Likes

How can we get the commit that removes IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ into 23.05 branch?

Would be great to test this in 23.05-snapshot builds before 23.05-RC1 will be released.

I think Netgear WAX206 users might be interested to test 23.05-snapshot builds with the patch to fix AX performance. @frollic

There was an interesting cfg80211/mac80211 related patchset sent to the wireless mailing list, which, if merged (and does not cause other bugs), possibly also might fix some of the issues here: https://lore.kernel.org/linux-wireless/20230604091128.609335-1-gregory.greenman@intel.com/T/#t

In particular following commits contain explanations that can be understood also by laymen:

  • [PATCH 08/16] wifi: mac80211: recalc min chandef for new STA links

    When adding a new link to a station, this needs to cause a
    recalculation of the minimum chandef since otherwise we can
    have a higher bandwidth station connected on that link than
    the link is operating at. Do the appropriate recalc.

  • [PATCH 10/16] wifi: mac80211: batch recalc during STA flush

    When we flush stations, we first take them off the list
    and then destroy them one by one. If we do the different
    mode recalculations while destroying them, we cause the
    following scenario:

    • STA 1 has 80 MHz - min chanctx width is now 80 MHz
    • STA 2 has 80 MHz
    • empty STA list
    • destroy STA 2
    • recalc min chanctx width -> results in 20 MHz as
      the STA list is already empty

    This is broken, since as far as the driver is concerned
    STA 1 still exists at this point, and this causes issues
    at least with iwlwifi.

    Fix - and also optimize - this by doing the recalc of
    min chanctx width (and also P2P PS) only after all the
    stations were removed.

4 Likes

Will this patch go into master with kernel 6.1 only or also into 23.05 with kernel 5.15?

I don't know. For the record: For now, this is just a proposal in the mailing list. I don't know the exact procedures. It might get merged into linux-next first, before it gets merged into the linux kernel and then backported to OpenWrt with kernel 6.1 or 5.15. Usually, not everything gets backported, as it requires dedicated people with time and willingness to do this job. There are simply too many changes upstream to backport them all. Sometimes there are also compatibility issues with older kernels. Any backport can cause new bugs to pop up.

Interesting find.
Latest commit in the linux repo from three weeks ago is also from the same guy with a similar fix from the month before.

wifi: mac80211: recalc chanctx mindef before assigning
When we allocate a new channel context, or find an existing one
that is compatible, we currently assign it to a link before its
mindef is updated. This leads to strange situations, especially
in link switching where you switch to an 80 MHz link and expect
it to be active immediately, but the mindef is still configured
to 20 MHz while assigning. Also, it's strange that the chandef
passed to the assign method's argument is wider than the one in
the context.
Fix this by calculating the mindef with the new link considered
before calling the driver.
In particular, this fixes an iwlwifi problem during link switch
where the firmware would assert because the (link) station that
was added for the AP is configured to transmit at a bandwidth
that's wider than the channel context that it's configured on.

6 Likes

Are there any news? What's next. Does the patch help? Has anyone been able to test it yet? or is the 160Mhz support finally kicked out?

Barely any news. At least not in official repositories and forums. One user reported that in newest snapshot sometimes it works, if you just restart the device often enough. Like 1/10.

Tried with these two and no luck still slow speed compared to when VHT160 is removed. https://lore.kernel.org/linux-wireless/20230604120651.377adf3c789a.I91bf28f399e16e6ac1f83bacd1029a698b4e6685@changeid/
https://github.com/torvalds/linux/commit/04312de4ced4b152749614e8179f3978a20a992f

Haven't gotten this patch to apply and compile on the current backport but might give it another shot soon.
https://lore.kernel.org/linux-wireless/20230604120651.48d262b6b42d.Ia15532657c17535c28ec0c5df263b65f0f80663c@changeid/

2 Likes

The AX upload performance bug for Apple AX devices is still present in 23.05.0-rc1.

Test on 23.05.0-rc1:
AX 80 MHz

34.0 Mbit/s, 80 MHz, HE-MCS 0, HE-NSS 1, HE-GI 1
680.6 Mbit/s, 80 MHz, HE-MCS 7, HE-NSS 2, HE-GI 1

iperf3 Upload: 14 Mbit/s

AC 80 MHz

390.0 Mbit/s, 80 MHz, VHT-MCS 4, VHT-NSS 2, Short GI
585.1 Mbit/s, 80 MHz, VHT-MCS 6, VHT-NSS 2, Short GI

iperf3 Upload: 289 Mbit/s

This seems to be a low level wifi OSI layer 1 bug since only the upstream connection drops to HE-MCS 0 and HE-NSS 1, while the downstream connection stays at higher connection rates.

4 Likes

Is this only Apple device specific? Because I tested with Chromebook (Intel AX211 WiFi) with my WAX206 on 23.05 RC1, a rough speed test gave me ~1.3Gbps throughput. Now I am trying to get an iPad mini to test with it.

Haven't done iperf because I was borrowing iPad Air 4 from someone just for a quick test.
I only used Ookla speedtest, with my WAX206 on 23.05-RC

Download: 650Mbps
Upload: 600Mbps

Luci is showing HE-NSS 2,HE-MCS10 for both TX/RX (while there is also HE-GI 1 at the end) for corresponding iPad Air 4 device.

To me it doesn't really doing bad on AX.

P.S. My WAX206 was set to 160MHz 802.11ax mode.

1 Like

This is specific to AX Apple iOS/iPadOS devices with the MT7915 device operating in AX mode, 80 MHz channel.

The upstream connection drops to HE-MCS0 (zero) NSS1 single stream during upload test.

160 MHz channels are not useful in dense city environments with a lot of other 5 GHz networks around, as you will both receive a lot of interference from other 5 GHz network and also produce interference for others. Also the more wide the channel is the more noise you will collect as a receiver.

In the EU regulatory domain there is only one 160 MHz channel available that is not shared with weather radar. 160 MHz channels could be useful for green field rural use cases here.

160 MHz channels are out of specification for MT7915, Mediatek has dropped support for these channels.

2 Likes

But in my case, I am also using iPad OS but there seems to be no issue, though I set my channel width to 160MHz but Apple devices can only support 80MHz so AP side will continue to use 80MHz to connect, right? I am trying to understand why I don't see the performance degrade with iPad mini 4 + WAX206 combination.

iPad Mini 4 is an AC device, not AX capable.

1 Like

The one I used to test was iPad Air 4, not iPad Mini 4, which is 802.11ax standard, and from Luci, or other routers I can see it connecting with link rate > 1000Mbps which definitely not 2x2 AC.

WAX206 seems to be using MT7975AN and not MT7915 like on eg Belkin RT3200 which is one of device that has this problem.

Also how far away from the router are you testing? The performance just a few meter away from the router is fine also on MT7915, it's when you move a little bit further away and/or have some obstacles in the way that it gets very slow.