Netgear R7800 exploration (IPQ8065, QCA9984)

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:

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=68886f301850c6c35bdff002a719fed1ded584c9

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?

80

80p80

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.