Linksys E8450 11ac faster than 11ax with 23.05-SNAPSHOT

environment:

ubus call system board
{
	"kernel": "5.15.112",
	"hostname": "OpenWrt",
	"system": "ARMv8 Processor rev 4",
	"model": "Linksys E8450 (UBI)",
	"board_name": "linksys,e8450-ubi",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "23.05-SNAPSHOT",
		"revision": "r23042-3a1cb63336",
		"target": "mediatek/mt7622",
		"description": "OpenWrt 23.05-SNAPSHOT r23042-3a1cb63336"
	}
}

I have installed and activated the irqbalance package. Client machine: Debian 11, iwlwifi, Intel(R) Wi-Fi 6 AX201, 2T2R.

11ax:

	signal: -64 dBm
	rx bitrate: 626.9 MBit/s 80MHz HE-MCS 6 HE-NSS 2 HE-GI 0 HE-DCM 0
	tx bitrate: 592.1 MBit/s 80MHz HE-MCS 6 HE-NSS 2 HE-GI 1 HE-DCM 0

	bss flags:	short-slot-time
	dtim period:	2
	beacon int:	100

iperf3 -c 192.168.1.1
Connecting to host 192.168.1.1, port 5201
[  5] local 192.168.1.150 port 55238 connected to 192.168.1.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  11.8 MBytes  99.1 Mbits/sec    0    481 KBytes       
[  5]   1.00-2.00   sec  14.8 MBytes   124 Mbits/sec    0    758 KBytes       
[  5]   2.00-3.00   sec  16.2 MBytes   136 Mbits/sec    0    933 KBytes       
[  5]   3.00-4.00   sec  13.8 MBytes   115 Mbits/sec    0   1.47 MBytes       
[  5]   4.00-5.00   sec  22.5 MBytes   189 Mbits/sec    0   1.77 MBytes       
[  5]   5.00-6.00   sec  25.0 MBytes   210 Mbits/sec    0   2.01 MBytes       
[  5]   6.00-7.00   sec  15.0 MBytes   126 Mbits/sec    0   2.01 MBytes       
[  5]   7.00-8.00   sec  13.8 MBytes   115 Mbits/sec    0   2.01 MBytes       
[  5]   8.00-9.00   sec  18.8 MBytes   157 Mbits/sec    0   2.01 MBytes       
[  5]   9.00-10.00  sec  13.8 MBytes   115 Mbits/sec    0   2.01 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   165 MBytes   139 Mbits/sec    0             sender
[  5]   0.00-10.05  sec   164 MBytes   137 Mbits/sec                  receiver

11ac:

	signal: -64 dBm
	rx bitrate: 650.0 MBit/s VHT-MCS 7 80MHz short GI VHT-NSS 2
	tx bitrate: 780.0 MBit/s VHT-MCS 8 80MHz short GI VHT-NSS 2

	bss flags:	short-slot-time
	dtim period:	2
	beacon int:	100

iperf3 -c 192.168.1.1 -t 20
Connecting to host 192.168.1.1, port 5201
[  5] local 192.168.1.150 port 38476 connected to 192.168.1.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  46.8 MBytes   393 Mbits/sec    0   1.93 MBytes       
[  5]   1.00-2.00   sec  51.2 MBytes   430 Mbits/sec    0   1.93 MBytes       
[  5]   2.00-3.00   sec  48.8 MBytes   409 Mbits/sec    0   1.93 MBytes       
[  5]   3.00-4.00   sec  52.5 MBytes   440 Mbits/sec    0   1.93 MBytes       
[  5]   4.00-5.00   sec  48.8 MBytes   409 Mbits/sec    0   1.93 MBytes       
[  5]   5.00-6.00   sec  28.8 MBytes   241 Mbits/sec    0   1.93 MBytes       
[  5]   6.00-7.00   sec  37.5 MBytes   315 Mbits/sec    0   1.93 MBytes       
[  5]   7.00-8.00   sec  38.8 MBytes   325 Mbits/sec    0   1.93 MBytes       
[  5]   8.00-9.00   sec  32.5 MBytes   273 Mbits/sec    0   1.93 MBytes       
[  5]   9.00-10.00  sec  37.5 MBytes   315 Mbits/sec    0   1.93 MBytes       
[  5]  10.00-11.00  sec  35.0 MBytes   294 Mbits/sec    0   1.93 MBytes       
[  5]  11.00-12.00  sec  36.2 MBytes   304 Mbits/sec    0   1.93 MBytes       
[  5]  12.00-13.00  sec  50.0 MBytes   419 Mbits/sec    0   1.93 MBytes       
[  5]  13.00-14.00  sec  50.0 MBytes   419 Mbits/sec    0   1.93 MBytes       
[  5]  14.00-15.00  sec  47.5 MBytes   398 Mbits/sec    0   1.93 MBytes       
[  5]  15.00-16.00  sec  47.5 MBytes   398 Mbits/sec    0   1.93 MBytes       
[  5]  16.00-17.00  sec  52.5 MBytes   440 Mbits/sec    0   1.93 MBytes       
[  5]  17.00-18.00  sec  50.0 MBytes   419 Mbits/sec    0   1.93 MBytes       
[  5]  18.00-19.00  sec  51.2 MBytes   430 Mbits/sec    0   1.93 MBytes       
[  5]  19.00-20.00  sec  48.8 MBytes   409 Mbits/sec    0   1.93 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-20.00  sec   892 MBytes   374 Mbits/sec    0             sender
[  5]   0.00-20.01  sec   891 MBytes   373 Mbits/sec                  receiver

What can I do to get better performance with my E8450 in 11ax mode?

This is mostly a duplicate of 802.11ax worse than 802.11ac with mt76 driver?

It is very interesting to see that you can reproduce this with intel ax200 as client, as most people with this problem had Apple devices.

The solutions that have been found to fix 802.11ax 80 MHz channel bandwidth so far are:

  1. Remove IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ | in mt7915/init.c as does this pull-request to the mt76 wifi: mt76: mt7915: disable VHT CAP SUPP CHAN WIDTH 160Mhz for mt7915. This will remove 160 MHz VHT (802.11ac) bandwidth capabilities, which may be undesired.
    There is also [MAC80211][mt76][remove mt7915 BW160 support]

  2. Some report switching to 160 MHz bandwidth solved their issue. To make this work, your client devices may have to support 160 MHz bandwidth. Not sure.

Maybe there are more solutions, which have not been published by Mediatek yet, but this is what is publicly known at the very moment about this problem.

2 Likes

Honestly, i think Mediatek employees have just given up, as they simply removed the 160 MHz support in the mtk driver. They probably don't know how to fix this right now. But this is speculation on my part.

1 Like

Yes, I understood the long thread as the mt76 11ax performance problems got resolved somewhere on master, after 22.03 was branched. So I installed 23.05-snapshot for testing.

Does this change also affect 80 MHz channel SSIDs?

I use 80 MHz channels, 160 MHz channels will get me into a lot more interference with other SSIDs.

Honestly, i think Mediatek employees have just given up, as they simply removed the 160 MHz support in the mtk driver. They probably don't know how to fix this right now. But this is speculation on my part.

160 MHz channels may be interesting for green field use cases in rural areas, but not in dense city environments where a lot of people live and where 11ax should give improvements over 11ac from what I understood.

Yes, removing the 160 MHz VHT channel support apparently fixed the 80 MHz channels (At least that is what some users report), but I don't know what happens if you have a 802.11ac client device, which is not ax capable.

There indeed was a time when 160 MHz was removed in snashots, but after some other users complained about lackign 160 MHz support and they showed that 160 MHz was working well for them, the removal of 160 MHz was reverted.

2 Likes

I think the majority of wifi installations and users are located in city environments where 160 MHz channels will produce a lot of interference. Not only interference for the own 11ax network that can be lowered with SSID coloring, but also unwanted interference for other not 11ax ready SSIDs and stations.

If as an exception to the rule a minority of users have a green field use case with no other 5 GHz SSIDs around where they see a lot of benefit of 160 MHz channels they could compile their own driver with 160 MHz support.

For now my choice seems to be to stay in 80 MHz 11ac mode from what I can read. Not what I bought this router for.

This sub forum is about installing and using OpenWrt. What's your offer to help about the MT7915 11ax performance issue?

1 Like

While it is very likely your issues are similar to what is happening in 802.11ax worse than 802.11ac with mt76 driver?, we cannot rule out your client device ax201 is responsible. I looked at kernel.org (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?h=v6.4-rc4&qt=grep&q=ax201) and found only low amount of commits, which either means a) this device receives support under a different name than ax201 or b) there is low amounts of support or c) most changes are done in firmware. Either way, debian 11 uses linux kernel 5.10, whereas OpenWrt is in the process of moving to 6.1 right now, so there could have been lots of updates in the meanwhile. Not only in the driver, but also in more general code, which is shared by multiple drivers.

Your argument that 160 MHz channel bandwidth leads to more interference is a good one, but i would expect from good code to ensure that throughput and latency is still good, even when there is interference. Furthermore, protocols like ax and ac that use both broader channel bandwidths and 5 GHz channels are theorized to have lower range than 802.11n protocol, so you will encounter less interference when compared to legacy devices, because they cannot reach as far.

In my opinion, to increase support for your call to removing 160 MHz capabilities, one thing would need to happen:

Proof that removing 160 MHz capabilities actually fixes your problem. Testing code and pull-requests is always welcome :slight_smile:

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.