R7800 performance

I don’t game so I’m not chasing after every milisecond - With gig download on WAN I haven’t really needed SQM, on the upload (Asymmetric cable 940/35 link) SQM is beneficial. :sunglasses:. I usually run fq_codel / simplest on only the upload side.

The NSS builds are experimental. If you have basic linux skills, can compile firmware, and know how to rescue your r7800- you can give them a try (If not, I’d stick to a hynman build- see community builds, kong, or your own flavor). They unlock the two NSS 800mhz CPUs for hardware offloading :

If someone wants to try the new build, they should be stable... The worse it can happen is a panic with a very very special packet (we should have fixed this) or some packets doesn't get offloaded.

1 Like

I can recover the router by tftf, and some linux things (I have VPS, raspberry, etc) but I have no practice compiling and those things .... :frowning: there are no images made? that can be loaded by openwrt web?

where are they?

Problem is that as they are custom compiled, you can't install kernel module if needed

This may be a dumb question.... does sqm get bypassed with NSS offloading. In testing (and logically) it seems like it does.

Yes sqm is bypassed... Nss have support for shaper but we still haven't added support for sqm (I'm still busy with summer+ pushing patch upstream)

3 Likes

At the moment, ipq806x routers with the NSS cores activated can already do ingress and egress shaping with no load imposed on the main CPU (i.e. Kraits) cores. It should be able to shape traffic up to line speed (i.e. 1Gbps) without issue.

The only downside is that it has to be done with startup scripts at the moment. We need someone who understand how to change Luci SQM codes to incorporate the changes to make it more user friendly.

The other catch is that the NSS shapers are not really modern. It has fq_codel and htb that could work in tandem to shape and split requests fairly, so it should serve most use cases.

1 Like

Interesting. @moeller0 is frequently on all the SQM threads - don’t know if linking up the NSS cores with SQM in luci is up his alley. :sunglasses:

I’ve enjoyed using ansuel’s master NSS build on my main router. Enjoying getting line rate (940/35). Seeing wifi performance similar to hynman builds so I’ve only kept it to this wired router.

I’m going to test your master build this weekend and see how offloading is working for wifi to see if that is a good setup for my APs.

I have no r7800 at my disposal so I will not be able to test anything at all and hence would typically avoid making changes, but what exactly is missing in the GUI, maybe somebody could explain the details here?

You need the QSDK 11 NSS firmware if you want to test my master branch codes. @Ansuel QSDK 10 branch has the feature for the NSS shaper and also the WiFi offload as well, so there's no difference between both repos as far as feature is concerned.

@moeller0 the 'tc' commands are different when invoking the NSS shapers. Need to target the NSS specific shapers when configuring SQM via Luci instead of the regular in-built shapers, and also take care of the parameters quirks for the NSS shapres. Also, no cake support in the NSS shapers.

1 Like

Mmmh, this sounds like what you need is a simple_nss.qos script, and probably no changes to the GUI.... Could you post the exact invocations?

The script below is used to configure both ingress and egress shapers:

# Shape ingress traffic to 500 Mbit with chained NSSFQ_CODEL
tc qdisc add dev nssifb root handle 1: nsstbl rate 500Mbit burst 1Mb
tc qdisc add dev nssifb parent 1: handle 10: nssfq_codel limit 10240 flows 1024 quantum 1514 target 5ms interval 100ms set_default

# Shape egress traffic to 200 Mbit with chained NSSFQ_CODEL
tc qdisc add dev eth0 root handle 1: nsstbl rate 200Mbit burst 1Mb
tc qdisc add dev eth0 parent 1: handle 10: nssfq_codel limit 10240 flows 1024 quantum 1514 target 5ms interval 100ms set_default

I forgot to add that there are quirks in which ethernet device to target for ingress shaping. The solution is also only for ethernet device only at the moment, but it should be enough for most real world use cases.

I have a simple read me doc here:

1 Like

perfect, I don't usually make any kernel changes, I don't have a level for that. where are the images to test? Thank you.

Do you need some special package or basic with Luci?

Only use:

luci spanish
OpenVPN
adblock
SQM (I see that it does not work with NSS)
wakeonlan

in addition to everything you need for a pppoe connection, firewall, vlan, etc.

thanks

So would it be as simple as adding those scripts to /etc/rc.local to get fq_codel?

and loading the standard baseline 3 NSS packages (What are all the additional packages needed, just nss-ifb?)

CONFIG_PACKAGE_kmod-qca-nss-drv=y
CONFIG_PACKAGE_kmod-qca-nss-gmac=y
CONFIG_PACKAGE_kmod-qca-nss-ecm-standard=y

If I remember correctly you need to also select the nss qdisk package

Please a summary of all this, I get lost :frowning:

Just need a build environment to compile openWRT images.

You can pull from the git that you want to try.

Example:

  1. create a directory (folder) for your build, run this command after you change in to that new directory using one of the git directories (quarky or Ansuel with the NSS changes):

git clone -b kernel5.4-nss-qsdk10.0 https://github.com/Ansuel/openwrt.git


  1. compile an OpenWRT image with the standard commands. During make menuconfig add the three base packages in my post above (plus qdisc and any other optional packages you desire, luci, etc)

./scripts/feeds update -a
./scripts/feeds install -a
make menuconfig
make

  1. now you have a sysupgrade .bin file in the new bin folder. :sunglasses:
2 Likes

shoudn't you source the firmware for the NSS cores somewhere as well?

1 Like