I just upgraded one of my access points from an Archer C6 v3.2 to a Redmi AX6S.
Since the new device has support to 802.11ax on the 5Ghz band, I`ve decided to do some tests.
While in the same room 802.11ax has a higher throughput than 802.11ac (tested with iPerf3 on a wired Linux machine and and iPhone 13Pro), the performance of 802.11ax in another room across one brick wall is much worse than 802.11ac (see results below).
I had the assumption that 802.11ax would always have a superior performance than 802.11ac in any situation. Is my understanding wrong or may this be an issue of the m76 driver support to 802.11ax?
Unfortunately I did not test with the stock firmware to be able to compare results.
I repeated the test multiple times, and the results were consistent.
Test Environment: iperf3 server running on a wired Linux machine (1Gbps), iperf3 client running on an iPhone 13 Pro at a distance of about 5 meters from the access point with a brick wall in the way. Test performed with 5Ghz radio @80MHz, channel 149.
I just tested with a master snapshot build, and the performance in this situation was even worse.
So I believe it might be an issue with the m76 driver and 802.11ax support, but I cannot be certain of that.
Since 802.11x performance on the same room is excellent, and the issue only appears in an adjacent
room with a brick wall in the middle, my hypothesis is that is may have something related to beamforming that might be kicking in in this situation but for some reason is not working well with the m76 driver.
I will wait for another AX6S I've purchased to be delivered (possibly in the upcoming weeks0, and before flashing OpenWrt on it I will do the same test with the stock firmware in order to make sure it is indeed a firmware/driver issue. I will post here again when I have this data.
I suppose it is possible, as VHT beamforming may go down the implicit beamforming path when the calibration data is there (Did we have factory calibration data on this device? I never checked.), but HE beamforming does not have that option and only does explicit beamforming (aka normal beamforming).
However, there are a million and one other things else that could be broken.
Here you go. From the first test I did now I've changed channel from 149 to 100 since it was less busy in this range (and temporarily changed country to PA for testing purposes). But results did not change. I've also reverted from master to back to 23.03 snapshot.
iw list
root@ap3:~# iw list
Wiphy phy1
wiphy index: 1
max # scan SSIDs: 4
max scan IEs length: 2190 bytes
max # sched scan SSIDs: 0
max # match sets: 0
Retry short limit: 7
Retry long limit: 4
Coverage class: 0 (up to 0m)
Device supports AP-side u-APSD.
Device supports T-DLS.
Available Antennas: TX 0xf RX 0xf
Configured Antennas: TX 0xf RX 0xf
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* mesh point
* P2P-client
* P2P-GO
Band 2:
Capabilities: 0x9ff
RX LDPC
HT20/HT40
SM Power Save disabled
RX Greenfield
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 7935 bytes
No DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: No restriction (0x00)
HT TX/RX MCS rate indexes supported: 0-31
VHT Capabilities (0x339b79f9):
Max MPDU length: 7991
Supported Channel Width: 160 MHz, 80+80 MHz
RX LDPC
short GI (80 MHz)
short GI (160/80+80 MHz)
TX STBC
SU Beamformer
SU Beamformee
MU Beamformer
MU Beamformee
RX antenna pattern consistency
TX antenna pattern consistency
VHT RX MCS set:
1 streams: MCS 0-9
2 streams: MCS 0-9
3 streams: MCS 0-9
4 streams: MCS 0-9
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
VHT RX highest supported: 0 Mbps
VHT TX MCS set:
1 streams: MCS 0-9
2 streams: MCS 0-9
3 streams: MCS 0-9
4 streams: MCS 0-9
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
VHT TX highest supported: 0 Mbps
HE Iftypes: managed
HE MAC Capabilities (0x08011a000040):
+HTC HE Supported
Trigger Frame MAC Padding Duration: 2
OM Control
Maximum A-MPDU Length Exponent: 3
A-MSDU in A-MPDU
HE PHY Capabilities: (0x5c70ce126d00f3164e3f00):
HE40/HE80/5GHz
HE160/5GHz
HE160/HE80+80/5GHz
242 tone RUs/5GHz
Device Class: 1
LDPC Coding in Payload
HE SU PPDU with 1x HE-LTF and 0.8us GI
NDP with 4x HE-LTF and 3.2us GI
STBC Tx <= 80MHz
STBC Rx <= 80MHz
Full Bandwidth UL MU-MIMO
Partial Bandwidth UL MU-MIMO
DCM Max Constellation: 2
DCM Max Constellation Rx: 2
SU Beamformee
Beamformee STS <= 80Mhz: 3
Beamformee STS > 80Mhz: 3
Codebook Size SU Feedback
Codebook Size MU Feedback
Triggered CQI Feedback
Partial Bandwidth Extended Range
Partial Bandwidth DL MU-MIMO
PPE Threshold Present
Power Boost Factor ar
HE SU PPDU & HE PPDU 4x HE-LTF 0.8us GI
Max NC: 2
20MHz in 40MHz HE PPDU 2.4GHz
20MHz in 160/80+80MHz HE PPDU
80MHz in 160/80+80MHz HE PPDU
DCM Max BW: 1
Longer Than 16HE SIG-B OFDM Symbols
Non-Triggered CQI Feedback
TX 1024-QAM
RX 1024-QAM
RX Full BW SU Using HE MU PPDU with Compression SIGB
RX Full BW SU Using HE MU PPDU with Non-Compression SIGB
HE RX MCS and NSS set <= 80 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: MCS 0-11
4 streams: MCS 0-11
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
HE TX MCS and NSS set <= 80 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: MCS 0-11
4 streams: MCS 0-11
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
HE RX MCS and NSS set 160 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
HE TX MCS and NSS set 160 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
HE Iftypes: AP
HE MAC Capabilities (0x00051a081044):
+HTC HE Supported
TWT Responder
BSR
OM Control
Maximum A-MPDU Length Exponent: 3
BQR
A-MSDU in A-MPDU
OM Control UL MU Data Disable RX
HE PHY Capabilities: (0x1c20ce926f0baf10000c00):
HE40/HE80/5GHz
HE160/5GHz
HE160/HE80+80/5GHz
LDPC Coding in Payload
NDP with 4x HE-LTF and 3.2us GI
STBC Tx <= 80MHz
STBC Rx <= 80MHz
Full Bandwidth UL MU-MIMO
Partial Bandwidth UL MU-MIMO
DCM Max Constellation: 2
DCM Max Constellation Rx: 2
SU Beamformer
SU Beamformee
MU Beamformer
Beamformee STS <= 80Mhz: 3
Beamformee STS > 80Mhz: 3
Sounding Dimensions <= 80Mhz: 3
Sounding Dimensions > 80Mhz: 1
Codebook Size SU Feedback
Codebook Size MU Feedback
Triggered SU Beamforming Feedback
Triggered MU Beamforming Feedback
Partial Bandwidth Extended Range
PPE Threshold Present
Max NC: 2
TX 1024-QAM
RX 1024-QAM
HE RX MCS and NSS set <= 80 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: MCS 0-11
4 streams: MCS 0-11
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
HE TX MCS and NSS set <= 80 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: MCS 0-11
4 streams: MCS 0-11
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
HE RX MCS and NSS set 160 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
HE TX MCS and NSS set 160 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
HE Iftypes: mesh point
HE MAC Capabilities (0x00011a000040):
+HTC HE Supported
OM Control
Maximum A-MPDU Length Exponent: 3
A-MSDU in A-MPDU
HE PHY Capabilities: (0x1c200c0000000000008000):
HE40/HE80/5GHz
HE160/5GHz
HE160/HE80+80/5GHz
LDPC Coding in Payload
STBC Tx <= 80MHz
STBC Rx <= 80MHz
HE RX MCS and NSS set <= 80 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: MCS 0-11
4 streams: MCS 0-11
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
HE TX MCS and NSS set <= 80 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: MCS 0-11
4 streams: MCS 0-11
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
HE RX MCS and NSS set 160 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
HE TX MCS and NSS set 160 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
Frequencies:
* 5180 MHz [36] (27.0 dBm)
* 5200 MHz [40] (27.0 dBm)
* 5220 MHz [44] (27.0 dBm)
* 5240 MHz [48] (27.0 dBm)
* 5260 MHz [52] (27.0 dBm)
* 5280 MHz [56] (27.0 dBm)
* 5300 MHz [60] (27.0 dBm)
* 5320 MHz [64] (27.0 dBm)
* 5500 MHz [100] (27.0 dBm)
* 5520 MHz [104] (27.0 dBm)
* 5540 MHz [108] (27.0 dBm)
* 5560 MHz [112] (27.0 dBm)
* 5580 MHz [116] (27.0 dBm)
* 5600 MHz [120] (27.0 dBm)
* 5620 MHz [124] (27.0 dBm)
* 5640 MHz [128] (27.0 dBm)
* 5660 MHz [132] (27.0 dBm)
* 5680 MHz [136] (27.0 dBm)
* 5700 MHz [140] (27.0 dBm)
* 5720 MHz [144] (27.0 dBm)
* 5745 MHz [149] (27.0 dBm)
* 5765 MHz [153] (27.0 dBm)
* 5785 MHz [157] (27.0 dBm)
* 5805 MHz [161] (27.0 dBm)
* 5825 MHz [165] (27.0 dBm)
* 5845 MHz [169] (disabled)
* 5865 MHz [173] (disabled)
valid interface combinations:
* #{ IBSS } <= 1, #{ AP, mesh point } <= 16, #{ managed } <= 19,
total <= 19, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz, 80+80 MHz, 160 MHz }
HT Capability overrides:
* MCS: ff ff ff ff ff ff ff ff ff ff
* maximum A-MSDU length
* supported channel width
* short GI for 40 MHz
* max A-MPDU length exponent
* min MPDU start spacing
max # scan plans: 1
max scan plan interval: -1
max scan plan iterations: 0
Supported extended features:
* [ VHT_IBSS ]: VHT-IBSS
* [ RRM ]: RRM
* [ BEACON_RATE_LEGACY ]: legacy beacon rate setting
* [ BEACON_RATE_HT ]: HT beacon rate setting
* [ BEACON_RATE_VHT ]: VHT beacon rate setting
* [ FILS_STA ]: STA FILS (Fast Initial Link Setup)
* [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
* [ CONTROL_PORT_OVER_NL80211 ]: control port over nl80211
* [ TXQS ]: FQ-CoDel-enabled intermediate TXQs
* [ AIRTIME_FAIRNESS ]: airtime fairness scheduling
* [ AQL ]: Airtime Queue Limits (AQL)
* [ SCAN_RANDOM_SN ]: use random sequence numbers in scans
* [ SCAN_MIN_PREQ_CONTENT ]: use probe request with only rate IEs in scans
* [ CONTROL_PORT_NO_PREAUTH ]: disable pre-auth over nl80211 control port support
* [ DEL_IBSS_STA ]: deletion of IBSS station support
* [ SCAN_FREQ_KHZ ]: scan on kHz frequency support
* [ CONTROL_PORT_OVER_NL80211_TX_STATUS ]: tx status for nl80211 control port support
* [ BSS_COLOR ]: BSS coloring support
Wiphy phy0
wiphy index: 0
max # scan SSIDs: 4
max scan IEs length: 2304 bytes
max # sched scan SSIDs: 0
max # match sets: 0
Retry short limit: 7
Retry long limit: 4
Coverage class: 0 (up to 0m)
Device supports AP-side u-APSD.
Device supports T-DLS.
Available Antennas: TX 0xf RX 0xf
Configured Antennas: TX 0xf RX 0xf
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* mesh point
* P2P-client
* P2P-GO
Band 1:
Capabilities: 0x1ff
RX LDPC
HT20/HT40
SM Power Save disabled
RX Greenfield
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 3839 bytes
No DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: No restriction (0x00)
HT TX/RX MCS rate indexes supported: 0-31
Frequencies:
* 2412 MHz [1] (27.0 dBm)
* 2417 MHz [2] (27.0 dBm)
* 2422 MHz [3] (27.0 dBm)
* 2427 MHz [4] (27.0 dBm)
* 2432 MHz [5] (27.0 dBm)
* 2437 MHz [6] (27.0 dBm)
* 2442 MHz [7] (27.0 dBm)
* 2447 MHz [8] (27.0 dBm)
* 2452 MHz [9] (27.0 dBm)
* 2457 MHz [10] (27.0 dBm)
* 2462 MHz [11] (27.0 dBm)
* 2467 MHz [12] (27.0 dBm)
* 2472 MHz [13] (27.0 dBm)
* 2484 MHz [14] (disabled)
valid interface combinations:
* #{ IBSS } <= 1, #{ managed, AP, mesh point, P2P-client, P2P-GO } <= 16,
total <= 16, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz, 80+80 MHz, 160 MHz }
HT Capability overrides:
* MCS: ff ff ff ff ff ff ff ff ff ff
* maximum A-MSDU length
* supported channel width
* short GI for 40 MHz
* max A-MPDU length exponent
* min MPDU start spacing
max # scan plans: 1
max scan plan interval: 0
max scan plan iterations: 0
Supported extended features:
* [ VHT_IBSS ]: VHT-IBSS
* [ RRM ]: RRM
* [ SET_SCAN_DWELL ]: scan dwell setting
* [ FILS_STA ]: STA FILS (Fast Initial Link Setup)
* [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
* [ CONTROL_PORT_OVER_NL80211 ]: control port over nl80211
* [ TXQS ]: FQ-CoDel-enabled intermediate TXQs
* [ AIRTIME_FAIRNESS ]: airtime fairness scheduling
* [ AQL ]: Airtime Queue Limits (AQL)
* [ CONTROL_PORT_NO_PREAUTH ]: disable pre-auth over nl80211 control port support
* [ DEL_IBSS_STA ]: deletion of IBSS station support
* [ SCAN_FREQ_KHZ ]: scan on kHz frequency support
* [ CONTROL_PORT_OVER_NL80211_TX_STATUS ]: tx status for nl80211 control port support
root@ap3:~#
I did another test with a Windows laptop (Intel AX210) and the results are even more confusing (same place and location as the iPhone). AC has a better performance when downstreaming, and AX has a better performance when upstreaming (iPhone is struggling upstreaming with AX).
I've added option he_bss_color '8' to the radio config and rebooted to be sure. Unfortunately iPhone 13 is still struggling when upstreaming in AX. With AC everything works fine (as well as with AX in the same room).
For now I will keep AC on this access point. When I receive the new AX6S I will do the same test with the stock firmware to have a baseline.
It is possible to use a flent.org rrul_be string of tests in your scenarios, so as to acquire more detail, but there is no iphone support for flent. You can get netperf running on the iphone and treat it as a client from the server.
There could be many reasons for the differences in throughput at this distance that cannot be boiled down to a single number. A stall, overbuffering leading to excessive retransmits, packet loss, minstrel choising the wrong rates, or some other bugs, etc could all be at fault.
This is why I love flent for debugging problems so much, in that you can see into this detail and get comparison plots. Here's an oldie but a goodie, and probably not relevant to this problem, directly, but illustrative of something you would not be seeing in a summary stat:
From your iw list output... if your transmit power really is at 27 dBm (~500 mW) that is insane. Try reducing it (option txpower) and re-test.
I have a Ubiquiti U6 LR which is also mt76 with 802,11ax, and I run my 5GHz radio at 13dBm. Taking into account the 5.5 dBi antennas used by the 5GHz radio, that provides what I believe is an effective transmit power of 18.5 dBm (~71 mW)
The most distant station I have is an Apple TV in the master bedroom. The distance from the ceiling-mounted AP is about 50 ft and through two walls. Using an Android phone in the exact same spot as the Apple TV, fast.com reports throughput as 200 Mbps down and 190Mbps up. May be worth noting the Apple TV is the first gen 4k (supports ac but not ax).
If I raise transmit power at the AP, I get stronger "signal strength" rating at the station, but actually end up with lower throughput.
Well, I can confirm that in fact OpenWrt performance in 802.11ax with the AX6S seems to be problematic with an iPhone 13 Pro.
I received today a new AX6S, and before flashing OpenWrt I did the same test I did before. The stock firmware has a much better performance than OpenWrt.
Just remembering that this scenario is with one brick wall between the router and an iPhone 13 Pro. In the same room and with the phone in the router's line of sight everything works as expected. Across the brick wall a Windows laptop (with an 802.11ax cart) has a slower but consistent performance both with the stock and OpenWrt firmware.
So at this moment it seems an specific problem with iPhone. Before flashing OpenWrt I will test if an M1 MacBook Air to check the results.
Very weird performance for your upload test at "110Mbps" ish
Maybe you should borrow your friend's android 5G supported phone and test it out.
On another topic, not the same hardware, my totolink X5000R with Mediatek chipset with
OpenWrt 22.03-SNAPSHOT r19235-d0965dc174 / LuCI openwrt-22.03 branch git-22.083.69105-af8e91c firmware loaded. I am having an intermittent drop connection problem with my old Atheros 802.11N wireless NIC running on my laptop.
I ask very simple. The MTK driver is binary or available as source in hard to get SDK? Its years just unreliable MT76xxx... Now the ar9331 are out of production, why not write the driver by reversing or from a clečan table from source? I wasted so much for almost every outers and only ar9331 run years
TBH the performnace of AX6S (mt7622) in 802.11ac is excellent. So good to the point that for now I disabled 802.11ax (to prevent this specific problem with iPhone) and with 802.11ac it is rock solid.
802.11ax is a new development for OpenWrt, and some issues like this one are expected as the open source driver matures.
Maybe i wasnt absolutely correct. The first mt7620/21 were plafgued with issues. ar9331 too but it was found usb related. Little OT: the at79 move made a mess in two port 9331 devbices like famous glinet 150. Xiaomi are cheap, hopefully soon get a solution, but why use with almost certainity use pepe2k webrecovery based on gpl uboot stripped by some "hackpasckal " who blatantly broke GPL. ANd almost no reaction, even if the first binaries had just encrypted/scrambled strings....
