-
-
Notifications
You must be signed in to change notification settings - Fork 9.9k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
mac80211: add AQL support for broadcast/multicast packets
Should improve performance/reliability with lots of mcast packets Signed-off-by: Felix Fietkau <nbd@nbd.name>
- Loading branch information
Showing
1 changed file
with
226 additions
and
0 deletions.
There are no files selected for viewing
226 changes: 226 additions & 0 deletions
226
...e/kernel/mac80211/patches/subsys/330-mac80211-add-AQL-support-for-broadcast-packets.patch
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,226 @@ | ||
From: Felix Fietkau <nbd@nbd.name> | ||
Date: Fri, 9 Feb 2024 19:43:40 +0100 | ||
Subject: [PATCH] mac80211: add AQL support for broadcast packets | ||
|
||
Excessive broadcast traffic with little competing unicast traffic can easily | ||
flood hardware queues, leading to throughput issues. Additionally, filling | ||
the hardware queues with too many packets breaks FQ for broadcast data. | ||
Fix this by enabling AQL for broadcast packets. | ||
|
||
Signed-off-by: Felix Fietkau <nbd@nbd.name> | ||
--- | ||
|
||
--- a/include/net/cfg80211.h | ||
+++ b/include/net/cfg80211.h | ||
@@ -3324,6 +3324,7 @@ enum wiphy_params_flags { | ||
/* The per TXQ device queue limit in airtime */ | ||
#define IEEE80211_DEFAULT_AQL_TXQ_LIMIT_L 5000 | ||
#define IEEE80211_DEFAULT_AQL_TXQ_LIMIT_H 12000 | ||
+#define IEEE80211_DEFAULT_AQL_TXQ_LIMIT_BC 50000 | ||
|
||
/* The per interface airtime threshold to switch to lower queue limit */ | ||
#define IEEE80211_AQL_THRESHOLD 24000 | ||
--- a/net/mac80211/debugfs.c | ||
+++ b/net/mac80211/debugfs.c | ||
@@ -215,11 +215,13 @@ static ssize_t aql_pending_read(struct f | ||
"VI %u us\n" | ||
"BE %u us\n" | ||
"BK %u us\n" | ||
+ "BC/MC %u us\n" | ||
"total %u us\n", | ||
atomic_read(&local->aql_ac_pending_airtime[IEEE80211_AC_VO]), | ||
atomic_read(&local->aql_ac_pending_airtime[IEEE80211_AC_VI]), | ||
atomic_read(&local->aql_ac_pending_airtime[IEEE80211_AC_BE]), | ||
atomic_read(&local->aql_ac_pending_airtime[IEEE80211_AC_BK]), | ||
+ atomic_read(&local->aql_bc_pending_airtime), | ||
atomic_read(&local->aql_total_pending_airtime)); | ||
return simple_read_from_buffer(user_buf, count, ppos, | ||
buf, len); | ||
@@ -245,7 +247,8 @@ static ssize_t aql_txq_limit_read(struct | ||
"VO %u %u\n" | ||
"VI %u %u\n" | ||
"BE %u %u\n" | ||
- "BK %u %u\n", | ||
+ "BK %u %u\n" | ||
+ "BC/MC %u\n", | ||
local->aql_txq_limit_low[IEEE80211_AC_VO], | ||
local->aql_txq_limit_high[IEEE80211_AC_VO], | ||
local->aql_txq_limit_low[IEEE80211_AC_VI], | ||
@@ -253,7 +256,8 @@ static ssize_t aql_txq_limit_read(struct | ||
local->aql_txq_limit_low[IEEE80211_AC_BE], | ||
local->aql_txq_limit_high[IEEE80211_AC_BE], | ||
local->aql_txq_limit_low[IEEE80211_AC_BK], | ||
- local->aql_txq_limit_high[IEEE80211_AC_BK]); | ||
+ local->aql_txq_limit_high[IEEE80211_AC_BK], | ||
+ local->aql_txq_limit_bc); | ||
return simple_read_from_buffer(user_buf, count, ppos, | ||
buf, len); | ||
} | ||
@@ -279,6 +283,11 @@ static ssize_t aql_txq_limit_write(struc | ||
else | ||
buf[count] = '\0'; | ||
|
||
+ if (sscanf(buf, "mcast %u", &q_limit_low) == 1) { | ||
+ local->aql_txq_limit_bc = q_limit_low; | ||
+ return count; | ||
+ } | ||
+ | ||
if (sscanf(buf, "%u %u %u", &ac, &q_limit_low, &q_limit_high) != 3) | ||
return -EINVAL; | ||
|
||
--- a/net/mac80211/ieee80211_i.h | ||
+++ b/net/mac80211/ieee80211_i.h | ||
@@ -1328,10 +1328,12 @@ struct ieee80211_local { | ||
spinlock_t handle_wake_tx_queue_lock; | ||
|
||
u16 airtime_flags; | ||
+ u32 aql_txq_limit_bc; | ||
u32 aql_txq_limit_low[IEEE80211_NUM_ACS]; | ||
u32 aql_txq_limit_high[IEEE80211_NUM_ACS]; | ||
u32 aql_threshold; | ||
atomic_t aql_total_pending_airtime; | ||
+ atomic_t aql_bc_pending_airtime; | ||
atomic_t aql_ac_pending_airtime[IEEE80211_NUM_ACS]; | ||
|
||
const struct ieee80211_ops *ops; | ||
--- a/net/mac80211/main.c | ||
+++ b/net/mac80211/main.c | ||
@@ -788,6 +788,7 @@ struct ieee80211_hw *ieee80211_alloc_hw_ | ||
spin_lock_init(&local->rx_path_lock); | ||
spin_lock_init(&local->queue_stop_reason_lock); | ||
|
||
+ local->aql_txq_limit_bc = IEEE80211_DEFAULT_AQL_TXQ_LIMIT_BC; | ||
for (i = 0; i < IEEE80211_NUM_ACS; i++) { | ||
INIT_LIST_HEAD(&local->active_txqs[i]); | ||
spin_lock_init(&local->active_txq_lock[i]); | ||
--- a/net/mac80211/sta_info.c | ||
+++ b/net/mac80211/sta_info.c | ||
@@ -2341,28 +2341,27 @@ void ieee80211_sta_update_pending_airtim | ||
struct sta_info *sta, u8 ac, | ||
u16 tx_airtime, bool tx_completed) | ||
{ | ||
+ atomic_t *counter; | ||
int tx_pending; | ||
|
||
if (!wiphy_ext_feature_isset(local->hw.wiphy, NL80211_EXT_FEATURE_AQL)) | ||
return; | ||
|
||
- if (!tx_completed) { | ||
- if (sta) | ||
- atomic_add(tx_airtime, | ||
- &sta->airtime[ac].aql_tx_pending); | ||
+ if (sta) | ||
+ counter = &sta->airtime[ac].aql_tx_pending; | ||
+ else | ||
+ counter = &local->aql_bc_pending_airtime; | ||
|
||
+ if (!tx_completed) { | ||
+ atomic_add(tx_airtime, counter); | ||
atomic_add(tx_airtime, &local->aql_total_pending_airtime); | ||
atomic_add(tx_airtime, &local->aql_ac_pending_airtime[ac]); | ||
return; | ||
} | ||
|
||
- if (sta) { | ||
- tx_pending = atomic_sub_return(tx_airtime, | ||
- &sta->airtime[ac].aql_tx_pending); | ||
- if (tx_pending < 0) | ||
- atomic_cmpxchg(&sta->airtime[ac].aql_tx_pending, | ||
- tx_pending, 0); | ||
- } | ||
+ tx_pending = atomic_sub_return(tx_airtime, counter); | ||
+ if (tx_pending < 0) | ||
+ atomic_cmpxchg(counter, tx_pending, 0); | ||
|
||
atomic_sub(tx_airtime, &local->aql_total_pending_airtime); | ||
tx_pending = atomic_sub_return(tx_airtime, | ||
--- a/net/mac80211/tx.c | ||
+++ b/net/mac80211/tx.c | ||
@@ -3958,9 +3958,8 @@ begin: | ||
encap_out: | ||
IEEE80211_SKB_CB(skb)->control.vif = vif; | ||
|
||
- if (tx.sta && | ||
- wiphy_ext_feature_isset(local->hw.wiphy, NL80211_EXT_FEATURE_AQL)) { | ||
- bool ampdu = txq->ac != IEEE80211_AC_VO; | ||
+ if (wiphy_ext_feature_isset(local->hw.wiphy, NL80211_EXT_FEATURE_AQL)) { | ||
+ bool ampdu = txq->sta && txq->ac != IEEE80211_AC_VO; | ||
u32 airtime; | ||
|
||
airtime = ieee80211_calc_expected_tx_airtime(hw, vif, txq->sta, | ||
@@ -4026,6 +4025,7 @@ struct ieee80211_txq *ieee80211_next_txq | ||
struct ieee80211_txq *ret = NULL; | ||
struct txq_info *txqi = NULL, *head = NULL; | ||
bool found_eligible_txq = false; | ||
+ bool aql_check; | ||
|
||
spin_lock_bh(&local->active_txq_lock[ac]); | ||
|
||
@@ -4049,26 +4049,26 @@ struct ieee80211_txq *ieee80211_next_txq | ||
if (!head) | ||
head = txqi; | ||
|
||
+ aql_check = ieee80211_txq_airtime_check(hw, &txqi->txq); | ||
+ if (aql_check) | ||
+ found_eligible_txq = true; | ||
+ | ||
if (txqi->txq.sta) { | ||
struct sta_info *sta = container_of(txqi->txq.sta, | ||
struct sta_info, sta); | ||
- bool aql_check = ieee80211_txq_airtime_check(hw, &txqi->txq); | ||
- s32 deficit = ieee80211_sta_deficit(sta, txqi->txq.ac); | ||
- | ||
- if (aql_check) | ||
- found_eligible_txq = true; | ||
- | ||
- if (deficit < 0) | ||
+ if (ieee80211_sta_deficit(sta, txqi->txq.ac) < 0) { | ||
sta->airtime[txqi->txq.ac].deficit += | ||
sta->airtime_weight << AIRTIME_QUANTUM_SHIFT; | ||
- | ||
- if (deficit < 0 || !aql_check) { | ||
- list_move_tail(&txqi->schedule_order, | ||
- &local->active_txqs[txqi->txq.ac]); | ||
- goto begin; | ||
+ aql_check = false; | ||
} | ||
} | ||
|
||
+ if (!aql_check) { | ||
+ list_move_tail(&txqi->schedule_order, | ||
+ &local->active_txqs[txqi->txq.ac]); | ||
+ goto begin; | ||
+ } | ||
+ | ||
if (txqi->schedule_round == local->schedule_round[ac]) | ||
goto out; | ||
|
||
@@ -4133,7 +4133,8 @@ bool ieee80211_txq_airtime_check(struct | ||
return true; | ||
|
||
if (!txq->sta) | ||
- return true; | ||
+ return atomic_read(&local->aql_bc_pending_airtime) < | ||
+ local->aql_txq_limit_bc; | ||
|
||
if (unlikely(txq->tid == IEEE80211_NUM_TIDS)) | ||
return true; | ||
@@ -4182,15 +4183,15 @@ bool ieee80211_txq_may_transmit(struct i | ||
|
||
spin_lock_bh(&local->active_txq_lock[ac]); | ||
|
||
- if (!txqi->txq.sta) | ||
- goto out; | ||
- | ||
if (list_empty(&txqi->schedule_order)) | ||
goto out; | ||
|
||
if (!ieee80211_txq_schedule_airtime_check(local, ac)) | ||
goto out; | ||
|
||
+ if (!txqi->txq.sta) | ||
+ goto out; | ||
+ | ||
list_for_each_entry_safe(iter, tmp, &local->active_txqs[ac], | ||
schedule_order) { | ||
if (iter == txqi) |
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately, after applying this patch, the same issue occurred.
95e633e#commitcomment-139794215
GL-MT6000 MT7986AV
I went out with my iPhone and when I came back, the value increased. For the sake of experimentation, I went out again in the same way, turned off the iPhone's Wi-Fi on the way back, and when I returned home, the values increased again. It seems possible that this behavior occurs when the iPhone goes out of range with the Wi-Fi connected.
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Continuation of the experiment. iPhoen was placed in a shielded case to prevent radio waves from reaching it. The values changed as expected.
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nbd168 well, those patches did nothing; I guess it was just a coincidence that it lasted for this long. For context about all those
wlX-apY.Z
, I haveper_sta_vif
enabled.95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nbd168 No idea if this is helpful, but it takes minimal effort on my part
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like the line numbers don't make much sense, should I compile with
-O0
so they make sense?95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rany2 the line numbers make perfect sense and this helped me a lot to get some context for this bug.
Please test if this mac80211 patch fixes the crash: https://nbd.name/p/f42fb22e
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nbd168 I will test now, thank you so much for your patience with me :)
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Likewise. Without the help I'm getting from you guys, this would take much longer to resolve.
@rany2, @Fail-Safe, @nxhack - here's another attempt at resolving the pending tx airtime issue (mac80211 patch): https://nbd.name/p/5b0b4a4a
It's based on the theory that maybe packets aren't getting stuck in hardware at all, but there might be a race condition on counting completed airtime vs deleting stations.
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nbd168 Always happy to help out! I'm grabbing the new pending tx airtime patch and will get to testing it in a few minutes. Thanks!
Just to confirm, you want us to also keep yesterday's patch (https://nbd.name/p/005d44af) in place in addition to this new one, yes?
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nbd168 I'll give it a spin now and will give a status update after a day or so if all goes well (or sooner if it just didn't help). Thanks again for the effort you're putting into this; I'm more than happy to help you out with testing :)
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/package/kernel/mt76/patches/
? I believe the build system will just apply them when it compilesmt76
right?95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, I am running all three patches at this point. This one (https://nbd.name/p/005d44af) I placed in
package/kernel/mt76/patches/
and the other two I placed intopackage/kernel/mac80211/patches/subsys/
.95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @Fail-Safe - I see now that the last two needed to be applied to
mac80211
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nbd168 I'm seeing much better behavior overall with the latest patch (5b0b4a4a) in place. However, something is still going on where phy1 on both MT6000s seems to be hanging on to 50k+ for BC/MC for some amount of seconds before clearing out and heading back to 0. Then the behavior repeats--back upwards of 50k for several seconds before dropping back to 0.
Is this due to 5ghz devices and power saving modes on the STAs?
Just to level-set on where I stand, especially for those just coming into the thread:
Device: 2x GL-MT6000 (MT7986)
Running snapshot build: r25541-af860c4dbf
Patches:
With this current combination of patches, the major latency spikes I was seeing 300+ ms (upwards of multiple seconds) are no longer occurring and generally (other than my notes above regarding BC/MC on phy1) there are no longer stuck packets in aql_pending.
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Fail-Safe Thanks for reporting back. I'm pretty sure that the stuck broadcast airtime (which I can also reproduce myself) is a pre-existing bug that was simply hidden. Before my AQL changes, it simply wasn't counted as pending airtime at all. There were quite a few reports over time that could be explained by broadcast packets not getting transmitted properly anymore (showing up as things like ARP failure, or failure to ping wifi clients from LAN).
I've figured out that the issues are triggered by beacon updates after client connect/disconnect, but so far wasn't able to figure out a solution yet. I probably need to contact MTK about this. If I skip beacon updates, the issue disappears.
@graysky2 You can skip the mt76 patch - I don't think it makes any difference based on reports so far.
By the way, I've pushed some more fixes from the MTK tree to mt76 master. I will update the mt76 package in OpenWrt soon.
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @nbd168 - I am currently running the latest HEAD plus the 5 patches @Fail-Safe called out several posts above. I will post back in the OpenWrt thread with the result to keep this conversation cleaner since I do not know if the bug reported here is the same one affecting me.
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nbd168
Once you update the OpenWrt tree, which, if any, of the aforementioned patches do you recommend I apply?
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@graysky2 I know I'm not @nbd168, but FWIW I'll share what I've done.
I upgraded my snapshot build to pick up the mt76 repo updates that Felix pushed, up through openwrt/mt76@b4a9174.
From what I can tell, his updates include the 0016 and 0017 patches that Bo Jiao introduced, so I've removed them. I also removed the additional mt76 patch (005d44af) that Felix said could be dropped per:
I am still running the two mac80211 patches, f42fb22e and 5b0b4a4a.
So, to summarize what I am running right now, and is working well:
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you share your firmware so I can test it on my MT6000?
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent. @nbd168
I put my iPhone in the radio shield and tested it. No problem.
Thank you.
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So far it seems promising on my end. I think the (unrelated) per_sta_vif kernel panic is solved (https://nbd.name/p/f42fb22e) and I haven't had any issues with stuck packets after applying https://nbd.name/p/5b0b4a4a.
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for testing. Both mac80211 fixes are in OpenWrt now.
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it now possible to just recompile the firmware? Or do I need to wait a little longer for your tests? 🤔
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@PussAzuki I would tend to say with Felix’s commits in tree now, it would be a good time to recompile an image:
163c87d
dea42f6
I don’t see a commit yet for syncing up to HEAD on the mt76 repo. But I’m sure that will be coming in due time.
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nbd168
Sorry for hijacking but just to inform you thet I had to revert mt76 b4a917417c856307fe19fb6a1a2819e3270df22e commit.
Gives a mt798-mac: probe of 18000000.wifi failed with error -2 on my Asus filogic mt7986 device.
Thank you for your support.
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you seeing any bad behavior from that error, or just noting the presence of it?
I also see these messages on my both of my MT6000s (mt7986) a little after a reboot, but have found them to be benign to this point:
AP1:
AP2:
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nbd168 In looking at my kernel log for the prior message I sent, I did happen to just notice this sitting in one of my AP's logs:
However, the AP seems to be up and functional still, so it doesn't seem to have been an unrecoverable error. If this is unrelated to any of the changes from this current issue, and if it warrants an mt76 repo issue, please let me know and I will open one there. Thanks!
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting—as I mentioned this is not the case for me.
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nor I so far on flogic/xiaomi_redmi-router-ax6000-ubootmod. I patched
mt76
with the latest from that repo, and builtopenwrt
master branch from the latest commit.. So far, I do not see any problems.95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Strange then.
I'll need to test again but openwrt master and mt76 with commit e5fb6995e7eb99763a98e687376315281f47b220 as tip works.
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Gingernut1978 what's the model name of your device?
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nbd168 Asus tuf-ax4200
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Gingernut1978 the reason for the probe failure is the fact that the .dts for your device is missing the pre-calibration data. I've added a graceful fallback in this patch: https://nbd.name/p/79b39778
Please try it on top of mt76 master and show me the warning that it will print at boot regarding the missing precal data.
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nbd168 are these few lines enough?
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Gingernut1978 yes, thanks. Does mt76 work properly for you now?
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes it does.
Thank you once again.
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still have some problem with packets stuck in AQL que while using build with the patches and also latest mt76 driver. Device: GL-MT6000
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@peterbarta please show me the stats while the issue occurs
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@graysky2 yes, this is the case. I thought it might be connected with the problem that I have trouble loading pages on Wifi. Sometimes Github, Facebook pics, Insta feed and sometimes even Reddit feed. The symptoms felt like the issue described above. Also I have problems in online games (LoL) when lots of packets being exchanged, some of them dropped causing lag. 5 GHz AX, 160 mhz. Channels in use are not congested.
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@peterbarta please try 80 MHz to see if it improves things.
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For reference.
I use 80MHz regularly. (Because DFS is too slow for AP to be enabled and throughput is no different than 80MHz.)
The previous problem has been resolved at 80MHz.
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just so I am understanding. When I do a speed test, I am finding the following. Is it normal or abnormal?
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@graysky2 while doing the test, it's normal. When idle, counters should return to 0.
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @nbd168 - I am seeing this behavior on both my MT6000 and AX6000. Great job with the drivers!
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nbd168 This data result is from my GL-MT6000, using the latest mainline code and the latest mt76 driver, the only adjustment I made was to use the latest mt7986 firmware from mtk-openwrt-feeds, I will roll the mt7986 firmware and continue Test and report results.
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mean redmi ax6000 doesn't have the high ping latency problem anymore?
🤔 Do I have to wait a little longer?
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the latest value of my gl-mt6000. I have been observing it for a while and it seems to have remained unchanged. The current running time is less than 24 hours. Is it normal or abnormal?
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JiaY-shi - are your results from a busy network or an idle network? As I understand it, positive values are normal when traffic is flowing but they should return to 0 when no traffic is flowing:
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From the idle time, there were less than 3 wireless devices connected to the router. I observed the same value for more than an hour. Later, when I paid attention to it, it had become 0.
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My redmi ax6000 mesh look like work well now☺️
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What release are you running?
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The compiled version is this f84ed09
This is the latest value I've seen, and it's also a low load. There seems to be no problem with it so far, I will continue to test it.
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JiaY-shi
I'm just guessing and not sure.
Do you have disassoc_low_ack '0' set?
If so, try this: what happens if you try to explicitly disconnect any remaining unconnected clients?
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reflecting to my earlier issue: WED was causing the problem.
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have wed on snapshot and don't have any problem.
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have lots of retransmitted TCP packets and TCP ACKed unseen segment messages when WED was enabled. When I disabled all the issues went away and never came back since.
95e633e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Open a new issue with logs and additional info, perhaps?