If you think it is ready for prime time, can you update your public repo so that those who build themselves can also do that?
Many thanks for all your good work and keeping these R7800s still running at max speed
1 Like
OK, now I just build 23.05.04 with previous backports. I left out QAM-256 patch.
Speedtest on 2.4G for my pixel from the same location shows:
Old backports: 82Mbps
New backports: 42Mbps
New backports + QAM256: 38Mbps
I can repeat this test 5 times and the numbers are consistent through each test.
I wonder what kind of testing people do in order to commit this to a stable branch.
This is absolut dogshit.
2 Likes
Could it be that the later versioned backports prioritised fairness/latency over bandwidth?
Maybe changing the AQL values may help?
The problem is client don't reach VHT-NSS2 in download for 5GHz band.
EDIT: as i said this is only for ax and be clients
On 2.4GHz client only connect at 72Mbits max.
2 Likes
Ahh ... looks like ath10k driver got a big change as well? I would have thot backports would touch mainly mac80211 and left ath10k alone, since it's not actively maintained?
Looks like then the issue is that the ath10k firmware is not getting setup like it used to.
i have problem with ath10k performance after mac80211 updated to 6.1.97, i did this to restore it
3 Likes
I don't have that call in my nss patches, not sure where you have that patch from, maybe from the ipq807x nss patches? I also just have an issue on 2.4G and only with the wifi6 device. Tonight I'm going to check if I see the same problem on my non-nss router, which is pretty much vanilla openwrt.
2 Likes
OK, now I tested again with plain Openwrt 23.05.04, no modifications. Same shit.
I only get half the throughput in 2.4G with a Pixel 6.
2 Likes
try this
revert wifi: mac80211: set station RX-NSS on reconfig · torvalds/linux@4e5bd22 (github.com)
2 Likes
OK, now tested on both regular and and NSS+QAM256 build. Both builds work fine now throughput is back to normal.
@regae , did you already file a bug report?
3 Likes
no, I haven't filed a report
maybe someone will
I can confirm your findings also on regular builds.
What can be reverted for K5.15 builds?
Never mind found it.
On my week old 23.0.5.4 R7800 build testing my 2.4 Ghz the throughput also halved looks like it only uses one stream
@regae I tried with your patch for my regular R7800 build but that did not work.
You put the patch in the /package/kernel/mac80211/patches/qca directory, however that seems not targeted in the regular builds so I moved the patch to the /package/kernel/mac80211/patches/subsys directory.
That did the trick in removing line 1840: ieee80211_sta_set_rx_nss(link_sta); from build_dir/...../linux-ipq806x_generic/backports-6.1.97-1/net/mac80211/cfg.c
(please correct me if I am wrong, compiling is not my day job)
My 2.4 Ghz throughput is now doubled again compared to my build with same config a week earlier so went up from 50 Mb/s to 104 Mb/s
you are correct, just move the file to subsys folder
glad to be helpful
1 Like
Bug report: https://github.com/openwrt/openwrt/issues/15999
5 Likes
BTW. I pushed my code with QAM-256 support.
Luci code needed for QAM-256 is here:
Code for the 23.05.4 NSS build, along with the throughput fix is here:
8 Likes
Many thanks your work is much appreciated 
i think there is a flaw in regulator nss patch for ipq806x
uV = data->nss_core_vdd_nominal;
if (rate >= data->nss_core_threshold_freq)
return data->nss_core_vdd_high;
it will never bump the voltage if needed, it causes at least on onhub to silently reboot
chromium: nss volt: fix silent reboot after bumping up frequency · regae/openwrt@7dc2e49 (github.com)
1 Like
I don't think your patch does what you expect it to do:
uV = data->nss_core_vdd_nominal;
if (rate >= data->nss_core_threshold_freq)
return data->nss_core_vdd_high;
uV = data->nss_core_vdd_high;
else
uV = data->nss_core_vdd_nominal;
curr_uV = regulator_get_voltage(reg);
The line after:
return data->nss_core_vdd_high;
will not be executed. A return jumps out of the function.
Then even if the code in there has a flaw, it won't matter. If you look in the dts e.g qcom-ipq8064.dtsi which is pulled in by the onhub dts .
qcom,low-frequency = <733000000>; /* orig value 110000000 /
qcom,mid-frequency = <733000000>; / orig value 550000000 */
qcom,max-frequency = <733000000>;
Nss frequencies have been fixed to the max freq, same for the ip8065. And also the cpu freq at least on the R7800 is set to max.
So right now the code should always return nss_core_vdd_high, but I have to check if that makes sense. I have to check the code, that calls nss_ramp_voltage
You can verify freqs via dmesg:
low,mid,max nss freq
root@K7800:~# dmesg | grep -A 3 Supported
[ 11.196738] Supported Frequencies -
[ 11.196741] 800Mhz
[ 11.200968] 800Mhz
[ 11.204460] 800Mhz
No scaling
root@K7800:~# cat /sys/devices/system/cpu/cpufreq/policy*/scaling_governor
performance
performance
Did you capture a crash dump that leads you to the conclusion, that this comes from this part of code?
if (rate >= data->nss_core_threshold_freq)
uV = data->nss_core_vdd_high;
else
uV = data->nss_core_vdd_nominal;
return ... is removed
in my repo i am using scalable nss frequency not fixed and using ondemand gov, with that i noticed the codes i mentioned before.
there was no dump or ramoops, that is why i call it silent reboot