Maybe try latest upstream master commit:
Just tried it quickly, didn't help and didn't have time to test more.
I do not trust myself in my tired state to capture and sanitize my configuration as requested by @ThiloteE, but I note that I did not change any aspect of my configuration when moving from r22191-f6a7ce2501 to r22000-6bc675c0be.
I will leave the following notes about my config:
- Build: r22191-f6a7ce2501
- Channel: 153
- Width: 80 Mhz
- Screenshot from LUCI:
How this bug is observed:
My wife's 2021 MacBook Pro, across multiple runs of the macOS application Speedtest by Ookla, will not breach above 15 Mbps upload speed in a room without line of sight of the router.
I realize Speedtest by Ookla is not the perfect testing methodology, but it is how I first observed the issue in June 2022 so it is my current frame of reference.
On a table in a room with line of sight to the router, I get 30 - 38 Mbps upload speeds, the same as my other devices.
(When I observed in June 2022, I had internet supporting 1 Gbps up, and would get 15 Mbps max without line of sight and up to 680 Mbps with line of sight.)
The following notes are relevant:
- This issue is not observable on my other devices, such as my 2019 MBP and OnePlus 9 Pro, which get 30 - 38 Mbps at the same location the 2021 MBP drops to 15 Mbps. In addition to not being affected by location within the house, these other devices get the same upload speed whether on build
r22000-6bc675c0beor buildr22191-f6a7ce2501 - Interestingly, as
r22191-f6a7ce2501re-enables 120 Mhz channel widths, this bug does not occur on the 2021 MacBook Pro if Channel is set to 100 and Width is set to 160 Mhz. - But this bug does occur if Channel is set to 100 and Width is set to 80 Mhz, so it is not the change of Channel that removes the issue.
This behavior is not observable on build r22000-6bc675c0be which I was running previously (and I just switched back to and confirmed for about the 3rd time).
I know that this was not all of the information that was requested, but I hope that this can be valuable.
1 Like
iperf3-wise, I observe the following on the 2021 MacBook Pro:
| Release | Channel Width | Bitrate |
|---|---|---|
r22191-f6a7ce2501 |
80 Mhz | 11 - 12 Mbit/sec |
22.03.3 |
80 Mhz | 11 - 12 Mbit/sec |
r22191-f6a7ce2501 |
120 Mhz | 105 - 112 Mbit/sec |
22.03.3 |
120 Mhz |
Curiously, unlike r22191-f6a7ce2501, bitrate is still ~14 Mbit/sec when on 120 Mhz Channel Width instead of going up to 100+ Mbit/sec |
r22000-6bc675c0be (build between 22.03.3 and r22191-f6a7ce2501 when this bug was not appearing) |
80 Mhz | Bitrate: 86 - 89 Mbit/sec |
(PS I have tried running iperf3 -s on both the router itself and on a RPI 4 wired to the router - exact same ranges)
1 Like
OnePlus 9 Pro Specs: 2×2 MIMO, Support 2.4G/5G, Support WiFi 802.11 a/b/g/n/ac/ax → works
Iphone 13 Pro Specs: Wi‑Fi 6 (802.11ax) with 2x2 MIMO → does not work
I was having a suspicion the slow speed might be related to the mt76 driver not correctly responding to 2x2 devices (since the mt7915 is 4x4 with 80MHz, but falls back to 2x2 with 160 MHz and in dbdc mode also is 2x2), but alas, I guess we can rule that one out?
Updated to SNAPSHOT r22235-a03076cc39, switched to a 160MHz width channel on 5GHz, and now my Speedtest is even better — nearly what I get over ethernet!
This device (and OpenWrt) continues to impress and please me.
(Yes, sadly, 40Mbps is my max upstream speed, thanks Comcast; I hear there's talk we'll be upgraded to something like 200Mbps this year, through something called mid-split tiers.)
1 Like
Nice result, which device are you using?
Belkin RT3200
2 Likes
On the flipside, with my particular physical layout, I'm try to deal with the E8450/RT3200 having a noticeably worse WiFi signal than my old WRT-1900AC (with upgraded antennas), so everyone's experiences may be unique.
1 Like
Sad to found that latest snapshot brought back this annoying ax upload issue and I lost my previous working build. Any dev here know how to fix it?
1 Like
Finding the exact regression window or alternatively the exact commit that fixed it would help tremendously.
See here roughly how to do it: 802.11ax worse than 802.11ac with mt76 driver? - #266 by dsouza
The process is complex, because commits from the mt76 repository were not merged one by one into the OpenWrt master branch, but rather multiple commits altogether at once, which leaves us with a mess for debugging.
1 Like
I was thinking of doing like git bisect / binary search on the mt76 commits from the version bump
´https://github.com/openwrt/openwrt/commit/4dd0eaffc142e9782681353a53748e68cd731d49
Bad perf: https://github.com/openwrt/mt76/commit/c32d6d8
21 commits between
Good perf: https://github.com/openwrt/mt76/commit/b2360d5
Compile with the mt76 commit in the middle and test:
´https://github.com/openwrt/mt76/commit/1b602db9c235db36707a2dadd6430d72986b4894
Good/bad and go the next half, test and repeat.
Edit: tired and looked at the older commit
1 Like
Something that may be affecting the speed for some of you is this:
Basically, certain parameters cause my wifi speed to drop from ~800Mbps to ~150Mbps.
1 Like
Got to testing and it's the 160MHz commit (f9ca70d6367a) which makes 80MHz slow through some obstacles on the rt3200.
2 Likes
I don't know what they did at X-WRT but i was surprised by speed performance in WiFi with the mt76 drivers
With OpenWrt 650 / 450
With x-wrt 725 / 700
anyway to build openwrt without that one specific commit?
Here is the patch:
diff --git a/drivers/net/wireless/mediatek/mt76/mt7915/init.c b/drivers/net/wireless/mediatek/mt76/mt7915/init.c
index a7ff78b8697c..71ccefd39cb2 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7915/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7915/init.c
@@ -384,7 +384,6 @@ mt7915_init_wiphy(struct mt7915_phy *phy)
ieee80211_hw_set(hw, SUPPORTS_RX_DECAP_OFFLOAD);
ieee80211_hw_set(hw, SUPPORTS_MULTI_BSSID);
ieee80211_hw_set(hw, WANT_MONITOR_VIF);
- ieee80211_hw_set(hw, SUPPORTS_VHT_EXT_NSS_BW);
hw->max_tx_fragments = 4;
@@ -397,6 +396,9 @@ mt7915_init_wiphy(struct mt7915_phy *phy)
}
if (phy->mt76->cap.has_5ghz) {
+ struct ieee80211_sta_vht_cap *vht_cap;
+
+ vht_cap = &phy->mt76->sband_5g.sband.vht_cap;
phy->mt76->sband_5g.sband.ht_cap.cap |=
IEEE80211_HT_CAP_LDPC_CODING |
IEEE80211_HT_CAP_MAX_AMSDU;
@@ -404,19 +406,28 @@ mt7915_init_wiphy(struct mt7915_phy *phy)
IEEE80211_HT_MPDU_DENSITY_4;
if (is_mt7915(&dev->mt76)) {
- phy->mt76->sband_5g.sband.vht_cap.cap |=
+ vht_cap->cap |=
IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_7991 |
IEEE80211_VHT_CAP_MAX_A_MPDU_LENGTH_EXPONENT_MASK;
+
+ if (!dev->dbdc_support)
+ vht_cap->cap |=
+ IEEE80211_VHT_CAP_SHORT_GI_160 |
+ IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ |
+ FIELD_PREP(IEEE80211_VHT_CAP_EXT_NSS_BW_MASK, 1);
} else {
- phy->mt76->sband_5g.sband.vht_cap.cap |=
+ vht_cap->cap |=
IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_11454 |
IEEE80211_VHT_CAP_MAX_A_MPDU_LENGTH_EXPONENT_MASK;
/* mt7916 dbdc with 2g 2x2 bw40 and 5g 2x2 bw160c */
- phy->mt76->sband_5g.sband.vht_cap.cap |=
+ vht_cap->cap |=
IEEE80211_VHT_CAP_SHORT_GI_160 |
IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ;
}
+
+ if (!is_mt7915(&dev->mt76) || !dev->dbdc_support)
+ ieee80211_hw_set(hw, SUPPORTS_VHT_EXT_NSS_BW);
}
mt76_set_stream_caps(phy->mt76, true);
@@ -842,9 +853,13 @@ mt7915_set_stream_he_txbf_caps(struct mt7915_phy *phy,
int sts = hweight8(phy->mt76->chainmask);
u8 c, sts_160 = sts;
- /* mt7915 doesn't support bw160 */
- if (is_mt7915(&dev->mt76))
- sts_160 = 0;
+ /* Can do 1/2 of STS in 160Mhz mode for mt7915 */
+ if (is_mt7915(&dev->mt76)) {
+ if (!dev->dbdc_support)
+ sts_160 /= 2;
+ else
+ sts_160 = 0;
+ }
#ifdef CONFIG_MAC80211_MESH
if (vif == NL80211_IFTYPE_MESH_POINT)
@@ -945,10 +960,15 @@ mt7915_init_he_caps(struct mt7915_phy *phy, enum nl80211_band band,
int i, idx = 0, nss = hweight8(phy->mt76->antenna_mask);
u16 mcs_map = 0;
u16 mcs_map_160 = 0;
- u8 nss_160 = nss;
+ u8 nss_160;
- /* Can't do 160MHz with mt7915 */
- if (is_mt7915(&dev->mt76))
+ if (!is_mt7915(&dev->mt76))
+ nss_160 = nss;
+ else if (!dev->dbdc_support)
+ /* Can do 1/2 of NSS streams in 160Mhz mode for mt7915 */
+ nss_160 = nss / 2;
+ else
+ /* Can't do 160MHz with mt7915 dbdc */
nss_160 = 0;
for (i = 0; i < 8; i++) {
My guess is that the MT7986 devices require SUPPORTS_VHT_EXT_NSS_BW based on the original commit patch, you could try adding back ieee80211_hw_set(hw, SUPPORTS_VHT_EXT_NSS_BW); to /drivers/net/wireless/mediatek/mt76/mt7915/init.c.
I created a PR here for testing: https://github.com/openwrt/mt76/pull/760
I'm not sure of the intent of this change (seems like an accident), or if reverting it will negatively impact other devices.
3 Likes
I just edited the file package/kernel/mt76/Makefile with the commit before 160MHz got added back.
❯ git diff package/kernel/mt76/Makefile
diff --git a/package/kernel/mt76/Makefile b/package/kernel/mt76/Makefile
index 34930d7693..d0692e78fc 100644
--- a/package/kernel/mt76/Makefile
+++ b/package/kernel/mt76/Makefile
@@ -9,7 +9,7 @@ PKG_LICENSE_FILES:=
PKG_SOURCE_URL:=https://github.com/openwrt/mt76
PKG_SOURCE_PROTO:=git
PKG_SOURCE_DATE:=2023-03-01
-PKG_SOURCE_VERSION:=c32d6d849c43792abd8007e13e468b12d6d6e0b7
+PKG_SOURCE_VERSION:=39079b5e44a723e00aeb739e714aedc5f2e9705b
PKG_MIRROR_HASH:=b7004bc920ba44cef2f7868d94beb2d288ff9d399af624ce5dad972f953723c8
PKG_MAINTAINER:=Felix Fietkau <nbd@nbd.name>
I've forked mt76 repository just to do some testing.
I tried just adding back the following line (without any other change, details here) but it did NOT work:
ieee80211_hw_set(hw, SUPPORTS_VHT_EXT_NSS_BW);
However fully reverting the commit "add back 160Mhz channel" did fix the very slow upstream speed (see here).
So definitively the regression was the " wifi: mt76: mt7915: add back 160MHz channel width support for MT7915" commit in the main mt76 repo, and it will require a more in depth look by the mt76 developers.
Anyway, even with this fix that makes 802.11ax usable, 802.11ac performance is still superior when with obstacles in the wifi path.
2 Likes
Thanks for testing, after looking at the patch again it looks like SUPPORTS_VHT_EXT_NSS_BW is actually enabled on line 433 in an if block.
Another culprit could be the else block from 421-430, you may try reverting that and retesting. That seems to be the only part of that commit that doesn't deal directly with the MT7915 specifically.
Open PR here for testing: https://github.com/openwrt/mt76/pull/761
2 Likes