Ipq806x NSS build (Netgear R7800 / TP-Link C2600 / Linksys EA8500)

[kesagatame]

Newest build of what?

[Robenger]

21.02.0-rc4 for the 7800

[ORi]

nss.qos live system

When following @nihilt 's manual addition of the nss.qos script fq_codel actually works. It's egress shaping is working fine while I hardly notice any cpu increase. So thanks great.

However, I tried KONG's PKG_NAME:=sqm-scripts package and none of them appear to work. I tried different combinations and stuff. None of the cake scripts work with this NSS build, only the combination fq_codel and nss.qos as specified above.

What am I missing to make it work out of the box? Btw, I'm running [git-21.189.60983-f57d20b)] OpenWrt SNAPSHOT r16983-e4a4b77263.

Thanks @anon50098793 for pointing me to this thread.

[anon50098793]

@ORi

KONG's PKG

that's handy for when you build from source or need to track / consolidate best practice (thanks kong)...

but what you have done is pretty much what there is afaik...

which is 'nssfq_codel' instantiated from nss.qos (with the few other variable changes)

as all known (l3 fwd?) traffic pretty much gets shunted via the NSS dedicated cores... traditional CPU level shaping (layer_cake etc.) is not applicable as the CPU has nothing to work with...

nssfq_codel hooks into the NSS engine... and that's why it works...

tar -cvzf nsssqm.tar.gz /etc/config/sqm /usr/lib/sqm

will get you a zipfile you can unpack from / next time to make setup easier... (assuming nothing needs refactoring with the recent sqm bump for next time)

[ORi]

So while I reported that egress traffic shaping is working I now noticed that ingress traffic shaping is not.

config queue
        option debug_logging '0'
        option verbosity '8'
        option enabled '1'
        option qdisc 'fq_codel'
        option script 'nss.qos'
        option download '40000'
        option upload '10000'
        option linklayer 'none'
        option interface 'eth0'

Speedtest by Ookla - The Global Broadband Speed Test

As you can see the download goes well above the 40Mbps treshold while the egress is nicely followed.

Edit: I have experimented with both eth0 and pppoe-wan and they provide the same results. But I see above that @nihilt 's instructions mentioned eth0, so I stuck with the recommendation there. I'll change to pppoe-wan and reboot once more

[anon50098793]

see comment re: threshold inaccuracy

@quarky

Note tho that the rate configured may not be actual shaped thruput. Try to experiment with figures above and below for best result. Also, do ensure you have sufficient allowance for upstream for reply packets, especially if the upstream bandwidth is low. E.g. if your upstream bandwidth is 10Mbps, cap it with NSS Qdisc as well, or your buffer float will also be affected.

also... if your wan is pppoe this may be an unknown entity

@ORi

option interface 'pppoe-wan'

see if someone else runs a similar setup and can comment, with 'eth0' set in the sqm settings as advised here (and statically set in the qos script), and wan-is-pppoe... might be a spanner in the works...

(no setting sqm settings to pppoe for now is no good as there is no handling for that in the underlying qos script - unless of course you wanted to edit that too and see if something changes)

[ORi]

Ok. I've tested with pppoe-wan as interface and egress shaping seems to work as well, still no ingress though. But I'll set back to eth0 for now. pppoe-wan, eth0.2 and eth0 are all the same WAN port anyway.

I've also tested by setting to 1/4 of the actual speed, so 10Mbps and the ingress doesn't shape at all. Must be an issue somewhere in the script I assume.

[anon50098793]

see also

R7800 performance

One more question before I start working on this. You wrote: printf eth1 > /sys/module/nss-ifb/parameter/nss_src_dev You need to change the source interface first before bringing up the 'nssifb' interface. Changing it after the interface is up will have no effect. You need to bring down the interface and bring it back up to have the changes take effect. Does this also work for pppoe, e.g. printf pppoe-wan > /sys/module/nss_ifb/parameters/nss_dev_name Has anyone tried nss with pppoe conne…

maybe @chief can advise if he has any alterations to the instructions you followed ( not sure if those physdev rules are related to this )...

[KONG]

NSS cores do not support cake, only the qca nssfq_codel module can utilize the nss cores.

Regarding in and out shaping, this should work fine in my build, at least it did when I last tested it and it doesn't matter if you use pppoe or not.

[quarky]

Shaping eth0 for ingress should shape pppoe traffic as well, if wan-pppoe is using eth0.

Edit: just to be clear, I was referring to the NSS Qdisc shapers.

[ACwifidude]

Dumb question. So to eliminate nss1. Seems like we just need to remove the reference to it in this patch (delete this entire section of code from the patch...or do I just remove the references to crypto and ipsec to save memory for ea7500v1 devices?). I don't see any other places that nss1 is referenced in the other patches / modules - seeing if off the top of your head there is any other places I missed:

ipq806x: NSS Hardware Offloading Required DTS and Voltage Entries

+		nss1: nss@40800000 {
+			compatible = "qcom,nss";
+			qcom,low-frequency = <733000000>; /* orig value 110000000 */
+			qcom,mid-frequency = <733000000>; /* orig value 550000000 */
+			qcom,max-frequency = <733000000>;
+
+			interrupts = <GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 233 IRQ_TYPE_LEVEL_HIGH>;
+			reg = <0x36400000 0x1000 0x39010000 0x10000>;
+			reg-names = "nphys", "vphys";
+			resets = <&gcc UBI32_CORE2_CLKRST_CLAMP_RESET>,
+				 <&gcc UBI32_CORE2_CLAMP_RESET>,
+				 <&gcc UBI32_CORE2_AHB_RESET>,
+				 <&gcc UBI32_CORE2_AXI_RESET>;
+			reset-names = "clkrst-clamp", "clamp", "ahb", "axi";
+
+			qcom,id = <1>;
+			qcom,num-irq = <2>;
+			qcom,load-addr = <0x40800000>;
+			qcom,num-queue = <2>;
+			qcom,turbo-frequency;
+
+			qcom,capwap-enabled;
+			qcom,crypto-enabled;
+			qcom,dtls-enabled;
+			qcom,ipsec-enabled;
+		};

[ORi]

Ok, I've switched eth0 back to pppoe-wan just because it makes more sense to me.
After careful testing and several attemps modifying the shaping treshold I can confidently say that the ingress shaping doesn't work in @anon50098793 's NSS build for the RT2600AC. It clearly works well for egress, it has reduced my ping from 200ms to 30ms under high upload. It's still higher than I expected, idle it's about 14ms => 30ms under load, so still +16ms, but certainly better. I'll check some of the fq_codel params.

Speed test result

[ACwifidude]

If your ISP speed is that speed (<100mbps) - you would do better with a non-NSS build. For those speeds I’d run cake to get the best latency.

NSS fq_codel really shines at faster speeds ( >200 mbps) that “normal” OpenWrt with its lack of hardware offloading starts struggling on ipq806x devices.

[quarky]

@ACwifidude

So to eliminate nss1. Seems like we just need to remove the reference to it in this patch (delete this entire section of code from the patch...or do I just remove the references to crypto and ipsec to save memory for ea7500v1 devices?).

Correct. Just remove the entire nss1 section. The driver will not load the nss1 firmware if the DTS doesn’t have it. The firmware will be loaded if the nss1 section exists, so there’s no memory savings there.

[altuntepe]

Hi, how did you add the processor operating frequency and temperature value to this page?

[ACwifidude]

Rebased off of the 21.02.0 first stable release. Cleaned up the commits, made some tweaks to the CPU settings, and removed NSS1 (just eating up memory towards NSS functions not included on the build, might make ea7500v1 more stable?)

Let me know what you think about the 21.02.0 NSS build

[kesagatame]

Thank you. I assume the changes are included in R7800-20210905-Stable2012NSS-ath10k-sysupgrade.bin ? Aka OpenWrt 21.02-SNAPSHOT r16281+17-6f8143fa4a / LuCI openwrt-21.02 branch git-21.231.26241-422c175

[pattagghiu]

hello,
i'm building my image based on @ACwifidude repo and my old diffconfig file (last time i built an image was in july, the master r17109)
This used to work flawlessly, but today i'm gettina a strange (to me) error expanding the config file:

WARNING: Makefile 'package/feeds/packages/ieee8021xclient/Makefile' has a dependency on 'wpa_supplicant', which does not exist
tmp/.config-package.in:117030:error: recursive dependency detected!
tmp/.config-package.in:117030:  symbol PACKAGE_ethtool-full depends on PACKAGE_ethtool
tmp/.config-package.in:117017:  symbol PACKAGE_ethtool is selected by PACKAGE_ethtool-full
For a resolution refer to Documentation/kbuild/kconfig-language.rst
subsection "Kconfig recursive dependency limitations"

how can i manage this?
thanks

[iGz]

Hi folks,

since 21.02 final clean install on Zyxel NBG6817 I have small rectangle near masquerading checkbox in firewall Zones. When I hover over it with mouse pointer it says "Limited masquerading enabled" .
Is this OK or do I have something misconfigured ? Why it says "limited" ?

Thanks

[ACwifidude]

They changed several dependencies recently. I don’t recall any error this most recent build (I think they have fixed the dependencies errors by now). Usually a make clean will clear out those old dependency requirements and give the build system a fresh look.