Just upgrade your router to 22.03 RC5. It should fix your WIFI issue.
1 Like
Yeah, it does for me too, I thought about it.
@vochong Hmm, are you sure? The problem lies in the airtime scheduler, is that fixed now?
EDIT: I guess so... maybe it's this fix: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=6d49a25804d78d639e08a67c86b26991ce6485d8
And another fix today for multicast-induced latency bug:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=ec9f82fa18c7c8deb4875152d7907855d186f4c6
3 Likes
Initial impression is that Wi-Fi is behaving nicely after those changes. Feels more responsive too.
Let's hope the uptime will be as good as the last bulld I had.
@shelterx Good to hear.
I hope someone can persuade @nbd to commit the fixes to 21.02 branch as well, so the WIFI in the next 21.02.04 release will be good again. As of now, 21.02.1 WIFI is the only good one in the 21.02 series, because the 21.02.2 / 21.0.2.3 releases had this VTBA scheduler commit:
still didn't test... it's that good for real?
WiFi does indeed ”feel” better, snappier, more responsive. I’m now back to a previous NSS build I made from 22.03-rc1 based on @ACwifidude ‘s build because the build I made based on 22.03-rc5 is not stable, spontaneous reboots after a few days. No idea why yet. Seems kernel related, not WiFi related.
I had similar experience as yours with private builds based on 22.03-rc5, as my crashes pointed to the same address location as yours.
Did you enable NSS fq_codel (using tc)? My crashes happened mostly after enabling NSS fq_codel and run it overnight. For now, I just use NSS acceleration without NSS fq_codel and no more crash thereafter.
I did enable NSS fq_codel. Not using the tc commands in /etc/rc.local but via the web interface after pulling in @KONG 's method to manage that via the webinterface (which is nice).
I've ruled out the latest ath10k firmware (*-157) from kvalo's GitHub repository. I've just had another crash, this crash now also rules out the performance governor. I had set that to ondemand for years. To rule out crashes due to which governor, I set it to performance a few hours ago. A crash just a few minutes ago.
The NSS fq_codel might indeed be suspicious too.
Which qdisc script are you using in combination with fq_codel?
The /etc/rc.local or KONG's nss.qos methods are pretty much the same behind the scene since nss.qos also uses tc to configure nss fq_codel.
I also use the latest ath10k firmware version 157.
Yes, it's much better with the new Wi-Fi commits. I've always had a little lag over Wi-Fi, it's all gone now.
Hello, even though I edited this patch in the current snapshot version, it doesn't work. Do you have a new patch for the 80P80? What do I need to do for it to work?
Why don’t you post what you edited and I’ll take a look?
I just had a quick look at master and while the area of code has been significantly rearranged, it still looks possible to apply the same idea.
--- a/lib/netifd/wireless/mac80211.sh
+++ b/lib/netifd/wireless/mac80211.sh
@@ -69,6 +69,7 @@ drv_mac80211_init_device_config() {
short_gi_40 \
max_amsdu \
dsss_cck_40
+ config_add_string channel2
}
drv_mac80211_init_iface_config() {
@@ -137,7 +138,7 @@ mac80211_hostapd_setup_base() {
[ -n "$acs_exclude_dfs" ] && [ "$acs_exclude_dfs" -gt 0 ] &&
append base_cfg "acs_exclude_dfs=1" "$N"
- json_get_vars noscan ht_coex min_tx_power:0
+ json_get_vars noscan ht_coex channel2 min_tx_power:0
json_get_values ht_capab_list ht_capab tx_burst
json_get_values channel_list channels
@@ -158,7 +159,7 @@ mac80211_hostapd_setup_base() {
ht_capab=
case "$htmode" in
VHT20|HT20|HE20) ;;
- HT40*|VHT40|VHT80|VHT160|HE40|HE80|HE160)
+ HT40*|VHT40|VHT80|VHT160|VHT80P80|HE40|HE80|HE160)
case "$hwmode" in
a)
case "$(( (($channel / 4) + $chan_ofs) % 2 ))" in
@@ -232,6 +233,7 @@ mac80211_hostapd_setup_base() {
vht_center_seg0=
idx="$channel"
+ idx2="$channel2"
case "$htmode" in
VHT20|HE20) enable_ac=1;;
VHT40|HE40)
@@ -274,6 +276,24 @@ mac80211_hostapd_setup_base() {
vht_oper_chwidth=2
vht_center_seg0=$idx
;;
+ VHT80P80)
+ case "$(( ($channel / 4) % 4 ))" in
+ 1) idx=$(($channel + 6));;
+ 2) idx=$(($channel + 2));;
+ 3) idx=$(($channel - 2));;
+ 0) idx=$(($channel - 6));;
+ esac
+ case "$(( ($channel2 / 4) % 4 ))" in
+ 1) idx2=$(($channel2 + 6));;
+ 2) idx2=$(($channel2 + 2));;
+ 3) idx2=$(($channel2 - 2));;
+ 0) idx2=$(($channel2 - 6));;
+ esac
+ enable_ac=1
+ append base_cfg "vht_oper_chwidth=3" "$N"
+ append base_cfg "vht_oper_centr_freq_seg0_idx=$idx" "$N"
+ append base_cfg "vht_oper_centr_freq_seg1_idx=$idx2" "$N"
+ ;;
esac
[ "$band" = "5g" ] && {
json_get_vars background_radar:0
The patch is like this, what should its name be? And where should I copy it when compiling? Sorry, I don't know much about these matters.
You needed to modify the patch more than that, like i said the code around it has changed and it needs to match the new way of doing things.
--- a/lib/netifd/wireless/mac80211.sh
+++ b/lib/netifd/wireless/mac80211.sh
@@ -69,6 +69,7 @@ drv_mac80211_init_device_config() {
short_gi_40 \
max_amsdu \
dsss_cck_40
+ config_add_string channel2
}
drv_mac80211_init_iface_config() {
@@ -137,7 +138,7 @@ mac80211_hostapd_setup_base() {
[ -n "$acs_exclude_dfs" ] && [ "$acs_exclude_dfs" -gt 0 ] &&
append base_cfg "acs_exclude_dfs=1" "$N"
- json_get_vars noscan ht_coex min_tx_power:0
+ json_get_vars noscan ht_coex min_tx_power:0 channel2
json_get_values ht_capab_list ht_capab tx_burst
json_get_values channel_list channels
@@ -158,7 +159,7 @@
ht_capab=
case "$htmode" in
VHT20|HT20|HE20) ;;
- HT40*|VHT40|VHT80|VHT160|HE40|HE80|HE160)
+ HT40*|VHT40|VHT80|VHT160|VHT80P80|HE40|HE80|HE160|HE80P80)
case "$hwmode" in
a)
case "$(( (($channel / 4) + $chan_ofs) % 2 ))" in
@@ -230,8 +231,10 @@
enable_ac=0
vht_oper_chwidth=0
vht_center_seg0=
+ vht_center_seg1=
idx="$channel"
+ idx2="$channel2"
case "$htmode" in
VHT20|HE20) enable_ac=1;;
VHT40|HE40)
@@ -253,6 +256,24 @@
vht_oper_chwidth=1
vht_center_seg0=$idx
;;
+ VHT80P80|HE80P80)
+ case "$(( (($channel / 4) + $chan_ofs) % 4 ))" in
+ 1) idx=$(($channel + 6));;
+ 2) idx=$(($channel + 2));;
+ 3) idx=$(($channel - 2));;
+ 0) idx=$(($channel - 6));;
+ esac
+ case "$(( (($channel2 / 4) + $chan_ofs) % 4 ))" in
+ 1) idx2=$(($channel2 + 6));;
+ 2) idx2=$(($channel2 + 2));;
+ 3) idx2=$(($channel2 - 2));;
+ 0) idx2=$(($channel2 - 6));;
+ esac
+ enable_ac=1
+ vht_oper_chwidth=3
+ vht_center_seg0=$idx
+ vht_center_seg1=$idx2
+ ;;
VHT160|HE160)
if [ "$band" = "6g" ]; then
case "$channel" in
@@ -321,6 +342,7 @@
append base_cfg "vht_oper_chwidth=$vht_oper_chwidth" "$N"
append base_cfg "vht_oper_centr_freq_seg0_idx=$vht_center_seg0" "$N"
+ append base_cfg "vht_oper_centr_freq_seg1_idx=$vht_center_seg1" "$N"
cap_rx_stbc=$((($vht_cap >> 8) & 7))
[ "$rx_stbc" -lt "$cap_rx_stbc" ] && cap_rx_stbc="$rx_stbc"
@@ -429,6 +451,7 @@
[ "$hwmode" = "a" ] && {
append base_cfg "he_oper_chwidth=$vht_oper_chwidth" "$N"
append base_cfg "he_oper_centr_freq_seg0_idx=$vht_center_seg0" "$N"
+ append base_cfg "he_oper_centr_freq_seg1_idx=$vht_center_seg1" "$N"
}
set_default he_bss_color 128
Try that, i've modified it to include HE80P80 as well. The patch is written to allow you to manually make the necessary changes to a running system. If you want to patch a build system apply it to package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh instead.
Note that i typed the patch out by hand rather than using a diff so it's likely got some whitespace/garbage that won't apply.
1 Like
It worked with this patch, thank you. But the speed was not what I expected. I have the same low speed issue I had with 160 Mhz. I was hoping maybe 80+80 Mhz would be faster. 80 MHz is much faster. I can reach 800 megabit upload and 600 megabit download speed with 80 Mhz. But what is the reason for lower speed with 160 and 80+80 Mhz?
Maybe number of streams. This device switches back to 1SS in 160/80+80 mode whereas 80 can use 3 maybe 4SS.
But your speeds don’t really line up with that.
I wonder if someone can test this pr
@hnyman can you help me with this?
I need to make sure this doesn't cause regression of some sort.
1 Like
Yes, I can do a test build.
(I have apparently done the last 5.15 test build in March... The 5.15 jump for ipq806x has really taken long 
)
1 Like
Is taking so long as we still need to understand if we can switch it to DSA or not. Wonder if now it's a good time as we have the LRU patch that should give improved perf.
Also 6.1 is incoming in some month....
1 Like