Qualcommax NSS Build

markuznw · 2024-02-26T15:30:04.256Z

Having torrent issues with it (as soon as a torrent client is started lan becomes unusable, can't even access luci and pppoe goes down and up like crazy).
Tried to set pbuf off as per @qosmio post but that didn't work.
Trying now to set the pbuf to 512mb and see if that fixes it like someone mentioned.
This is on ax3600

AgustinLorenzo · 2024-02-26T15:33:01.122Z

Hi @markuznw

In principle I have left that variable at "auto" for new installations from 0, if it is updated through sysupgrade I believe that the content of the file is not changed.

Link: https://github.com/AgustinLorenzo/openwrt/commit/8f40d1b793984205e1074aaac84cbc562aea4d27#diff-5a640d321c9c6515d3f21e183c3baf3c845ae45ecff7fb8ff0b827b195e8e21fR3

Regards, Agustin

markuznw · 2024-02-26T15:36:23.745Z

Yes it was set to auto, but like said torrent makes it explode

JuliusBairaktaris · 2024-02-26T15:55:57.443Z

This makes no difference as the script, when set to auto, will simply select a memory profile according to your board, and since you have an AX3600, the 512MB profile will be selected.

This is my current memory usage with the script enabled for the ax3600:

image1070×634 13.7 KB

dingo · 2024-02-26T16:00:38.368Z

ok, who in here is capable of reviewing a dts that doesnt seem to work, for another device, it builds fine but refuses to boot.

i have both the original qsdk dts and the derivitive we created for openwrt.

anyone... ???

sppmaster · 2024-02-26T17:28:36.731Z

l33tlinuxh4x0r:

I am using the QNAP 301W and it works great.

You may be interested in these latest novelties about AQR 10G firmware for QNAP (enable using kernel for AQR firmware loading and using stock AQR 10G firmware extracted from stock QNAP firmware).

Edit - Big WARNING here (a bug!). Currently using the QNAP stock 10G firmware with NSS wifi brakes the 10G_1 port connection. Cannot get/lease IP address. See below.

qosmio:

@Everyone,

If any of you are using the pbuf script, could I get a consensus for the values you're using?
1.) Are you letting it autodetect or setting a custom memory value for "memory_profile"?
2.) Have you experimented with editing the /etc/init.d/pbuf script and setting custom values for extra_pbuf_core0, n2h_high_water_core0, and n2h_wifi_pool_buf?

I've tried all options - auto, 1gb, 512mb, 256mb without setting custom values in the script.
I didn't test these extensively. Most noticeable difference I saw was between 1gb/Auto and 512 mb profiles. Short testing showed around 100mb more free memory with 512mb profile.
Currently I test with 256mb profile. I don't see difference in memory usage compared to 512mb profile.

qosmio · 2024-02-26T17:36:05.329Z

Have you experimented with it off?

If you had it set to "auto" the default it selected for AX3600 was "512mb". Test with "256mb", and "off".

As mentioned before, these values require a reboot, as the "extra pbufs" setting is a static value once set.

markuznw:

can't even access luci and pppoe goes down and up like crazy).

Are you accessing Luci prior to WAN getting an IP? I've experienced this behavior whenever WAN hasn't fully come up. Others have experienced something similar, but it's still anecdotal as to what exactly causes this.

markuznw · 2024-02-26T17:40:44.231Z

Yes, tried with it off then reboot, used the exact commands you gave on some posts above this suggesting to disable pbuf cause of it being unstable yet. That didn't work.
So I've set it manually to 512mb and removed igmpproxy that was included in @AgustinLorenzo build and that seems to have fixed it, after a second reboot no more issues. Don't know which was the fix cause had to go work, will test it better tonight

About luci issue it was kinda unresponsive even after closing torrent client, it took 10 seconds to load the homepage, it was missing the menu. This was triggered by just opening torrent few seconds causing pppoe/luci/lan issues with connection going and coming back every one/two minutes. I see many people reported it as "torrent issue" days/weeks ago. A reboot fixed it.

l33tlinuxh4x0r · 2024-02-26T21:27:03.051Z

Thanks for letting me know about that.

qosmio · 2024-02-26T23:37:12.675Z

UPDATE: Pushed a new NSS SQM script that utilizes NSS clients igs module (act_nssmirred) for ingress shaping. This removes the dependency on nss-ifb. Thanks to @michaelchen644 for providing the working base.

github.com/qosmio/sqm-scripts-nss

nss-sqm: Initial commit for IPQ807x NSS builds

committed 11:29PM - 26 Feb 24 UTC

+345 -0

nss-ifb is no longer required, instead, qca-nss-drv-igs (act_nssmirred) will be …used for ingress shaping.

My current SQM config

config queue 'wan'
	option interface 'wan'
	option linklayer 'none'
	option qdisc_advanced '1'
	option squash_dscp '0'
	option squash_ingress '1'
	option ingress_ecn 'ECN'
	option egress_ecn 'ECN'
	option qdisc 'fq_codel'
	option verbosity '5'
	option script 'nss-zk.qos'
	option debug_logging '1'
	option enabled '1'
	option qdisc_really_really_advanced '1'
	option iqdisc_opts 'interval 25ms quantum 304'
	option eqdisc_opts 'interval 25ms quantum 304'
	option upload '969220'
	option download '969220'
	option itarget '2.5ms'
	option etarget '2.5ms'

Of course needs heavy testing. Update with your ISP's speeds and report any issues.

You can ignore the following errors in syslog/dmesg:

Mon Feb 26 18:16:33 2024 kern.warn kernel: [273142.009834] nss_qdisc_stats_qdisc_detach[681]: Error, stats wq should be initialized by now for root qdisc:0
Mon Feb 26 18:16:33 2024 kern.warn kernel: [273142.009909] nss_qdisc_stats_qdisc_detach[681]: Error, stats wq should be initialized by now for root qdisc:0
Mon Feb 26 18:16:33 2024 kern.warn kernel: [273142.019148] nss_qdisc_stats_qdisc_detach[681]: Error, stats wq should be initialized by now for root qdisc:0
Mon Feb 26 18:16:33 2024 kern.warn kernel: [273142.028897] nss_qdisc_stats_qdisc_detach[681]: Error, stats wq should be initialized by now for root qdisc:0
Mon Feb 26 18:16:33 2024 kern.warn kernel: [273142.038707] nss_qdisc_stats_qdisc_detach[681]: Error, stats wq should be initialized by now for root qdisc:0
Mon Feb 26 18:16:33 2024 kern.warn kernel: [273142.048791] nss_qdisc_stats_qdisc_detach[681]: Error, stats wq should be initialized by now for root qdisc:0

EDIT: Fixed above warnings

github.com/qosmio/sqm-scripts-nss

fix nss_qdisc_stats_qdisc_detach + shellcheck warnings

committed 04:09AM - 27 Feb 24 UTC

+81 -67

* Fixes warnings in `nss_qdisc_stats_qdisc_detach` when root is deleted prior …cleaning up rules. * Replace `let` expressions with more universal $((expr)) * Remove unecessary device deletion in egress/ingress, since sqm_stop is always called when restarting. This assumes SQM scripts is managing the interfaces.

JuliusBairaktaris · 2024-02-27T07:07:13.410Z

At what speeds does this become useful? On my 170/70 plan I don't get any buffer bloat and at higher speeds the consensus is that SQM Performance won't be able to keep up.

JuliusBairaktaris · 2024-02-27T08:26:08.224Z

@qosmio I think the pbuf script is causing a memory leak. When I reboot my router and connect all my 11 devices memory on my ax3600 sits at about 55ish% after an hour its at 70% and after a day at 80% (rough values)

JuliusBairaktaris · 2024-02-27T08:36:30.259Z

Updated my Builds to set this configuration by default.

hingbong · 2024-02-27T09:18:55.500Z

I recommend using PA or RU country code, there is no DFS policy, so that could enable WiFi without 60 secs waiting.

JuliusBairaktaris · 2024-02-27T09:23:37.645Z

This field is not meant to be set to where you were born, and not the country where you would prefer to live happily forever and ever with Katy Perry. It's also not some optional “cloud usage statistics” input field.

dckiller51 · 2024-02-27T09:24:49.872Z

Hello, I have been using your version for a while, I updated to the latest version. Unable to recover my mesh configuration. Is this patch applied because it corresponds to my problem (I think).

qualcommax/ipq807x/ax3600: Bootloop for led configuration caused by conflict between mesh and wireless network on same radio

sppmaster · 2024-02-27T10:09:48.014Z

dckiller51:

Is this patch applied because it corresponds to my problem (I think).

qualcommax/ipq807x/ax3600: Bootloop for led configuration caused by conflict between mesh and wireless network on same radio

The patch is applied.

dckiller51 · 2024-02-27T10:21:41.848Z

Thanks. Too bad for me, I'll dig into why this doesn't work anymore.

shi05275 · 2024-02-27T13:05:29.313Z

@qosmio Hi buddy, I tried to use your nss patch on ipq60xx platform and it caused the wifi to crash. This is the log:

[   14.611035] ECM init
[   14.611123] ECM database jhash random seed: 0x27c714b6
[   14.671909] ECM init complete
[   15.403746] ath11k c000000.wifi: radio is not up
[   15.579846] br-lan: port 1(eth1) entered blocking state
[   15.579911] br-lan: port 1(eth1) entered disabled state
[   15.584605] device eth1 entered promiscuous mode
[   15.606838] br-lan: port 2(eth2) entered blocking state
[   15.606892] br-lan: port 2(eth2) entered disabled state
[   15.611935] device eth2 entered promiscuous mode
[   16.538522] mtdblock: MTD device 'rootfs' is NAND, please consider using UBI block devices instead.
[   18.719925] nss-dp 3a001000.dp1 eth0: PHY Link up speed: 1000
[   18.720007] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   19.615774] __adpt_hppe_uniphy_psgmii_mode_set[1156]:INFO:uniphy 0 psgmii channel selection
[   19.725716] _adpt_hppe_port_interface_mode_apply[2754]:ERROR:config instance0, rv:fffffffc faild
[   21.471683] ath11k c000000.wifi: failed to wait qmi memory request: -110
[   21.471733] ath11k c000000.wifi: qmi failed to respond fw mem req: -110
[   21.478782] qcom-q6v5-wcss-pil cd00000.remoteproc: fatal error received: 
[   21.478782] QC Image Version: QC_IMAGE_VERSION_STRING=WLAN.HK.2.4.0.1-01746-QCAHKSWPL_SILICONZ-1
[   21.478782] Image Variant : IMAGE_VARIANT_STRING=6018.wlanfw.evalQ
[   21.478782] 
[   21.478782] platform_hk.c:754 Assertion remote_ddr_mem_req->mem_seg[idx].addr != 0x0 failedparam0 :zero, param1 :zero, param2 :zero.
[   21.478782] Thread ID      : 0x00000072  Thread name    : wlan_platform  Process ID     : 0
[   21.478782] Register:
[   21.478782] SP : 0x4af7ccb8
[   21.478782] FP : 0x4af7ccc0
[   21.478782] PC : 0x4ac94024
[   21.478782] SSR : 0x00000008
[   21.478782] BADVA : 0x00020000
[   21.478782] LR : 0x4ac937c0
[   21.478782] 
[   21.478782] Stack Dump
[   21.478782] from : 0x4af7ccb8
[   21.478782] to   : 0x4af7d050
[   21.478782] 
[   21.535668] remoteproc remoteproc0: crash detected in cd00000.remoteproc: type fatal error
[   21.557841] remoteproc remoteproc0: handling crash #2 in cd00000.remoteproc
[   21.566020] remoteproc remoteproc0: recovering cd00000.remoteproc
[   21.598998] remoteproc remoteproc0: stopped remote processor cd00000.remoteproc
[   21.893509] remoteproc remoteproc0: remote processor cd00000.remoteproc is now up
[   31.711692] ath11k c000000.wifi: failed to wait qmi memory request: -110
[   31.711741] ath11k c000000.wifi: qmi failed to respond fw mem req: -110
[   31.718810] qcom-q6v5-wcss-pil cd00000.remoteproc: fatal error received: 
[   31.718810] QC Image Version: QC_IMAGE_VERSION_STRING=WLAN.HK.2.4.0.1-01746-QCAHKSWPL_SILICONZ-1
[   31.718810] Image Variant : IMAGE_VARIANT_STRING=6018.wlanfw.evalQ
[   31.718810] 
[   31.718810] platform_hk.c:754 Assertion remote_ddr_mem_req->mem_seg[idx].addr != 0x0 failedparam0 :zero, param1 :zero, param2 :zero.
[   31.718810] Thread ID      : 0x00000072  Thread name    : wlan_platform  Process ID     : 0
[   31.718810] Register:
[   31.718810] SP : 0x4af7ccf8
[   31.718810] FP : 0x4af7cd00
[   31.718810] PC : 0x4ac94024
[   31.718810] SSR : 0x00000008
[   31.718810] BADVA : 0x00020000
[   31.718810] LR : 0x4ac937c0
[   31.718810] 
[   31.718810] Stack Dump
[   31.718810] from : 0x4af7ccf8
[   31.718810] to   : 0x4af7d090
[   31.718810] 
[   31.775680] remoteproc remoteproc0: crash detected in cd00000.remoteproc: type fatal error
[   31.797854] remoteproc remoteproc0: handling crash #3 in cd00000.remoteproc
[   31.806025] remoteproc remoteproc0: recovering cd00000.remoteproc
[   31.839206] remoteproc remoteproc0: stopped remote processor cd00000.remoteproc
[   32.133662] remoteproc remoteproc0: remote processor cd00000.remoteproc is now up
[   41.951695] ath11k c000000.wifi: failed to wait qmi memory request: -110
[   41.951748] ath11k c000000.wifi: qmi failed to respond fw mem req: -110
[   41.958794] qcom-q6v5-wcss-pil cd00000.remoteproc: fatal error received: 
[   41.958794] QC Image Version: QC_IMAGE_VERSION_STRING=WLAN.HK.2.4.0.1-01746-QCAHKSWPL_SILICONZ-1
[   41.958794] Image Variant : IMAGE_VARIANT_STRING=6018.wlanfw.evalQ
[   41.958794] 
[   41.958794] platform_hk.c:754 Assertion remote_ddr_mem_req->mem_seg[idx].addr != 0x0 failedparam0 :zero, param1 :zero, param2 :zero.
[   41.958794] Thread ID      : 0x00000072  Thread name    : wlan_platform  Process ID     : 0
[   41.958794] Register:
[   41.958794] SP : 0x4af7cd18
[   41.958794] FP : 0x4af7cd20
[   41.958794] PC : 0x4ac94024
[   41.958794] SSR : 0x00000008
[   41.958794] BADVA : 0x00020000
[   41.958794] LR : 0x4ac937c0
[   41.958794] 
[   41.958794] Stack Dump
[   41.958794] from : 0x4af7cd18
[   41.958794] to   : 0x4af7d0b0
[   41.958794] 
[   42.015714] remoteproc remoteproc0: crash detected in cd00000.remoteproc: type fatal error
[   42.037825] remoteproc remoteproc0: handling crash #4 in cd00000.remoteproc
[   42.046032] remoteproc remoteproc0: recovering cd00000.remoteproc
[   42.078967] remoteproc remoteproc0: stopped remote processor cd00000.remoteproc
[   42.373423] remoteproc remoteproc0: remote processor cd00000.remoteproc is now up
[   52.191689] ath11k c000000.wifi: failed to wait qmi memory request: -110
[   52.191741] ath11k c000000.wifi: qmi failed to respond fw mem req: -110
[   52.198778] qcom-q6v5-wcss-pil cd00000.remoteproc: fatal error received: 
[   52.198778] QC Image Version: QC_IMAGE_VERSION_STRING=WLAN.HK.2.4.0.1-01746-QCAHKSWPL_SILICONZ-1
[   52.198778] Image Variant : IMAGE_VARIANT_STRING=6018.wlanfw.evalQ
[   52.198778] 
[   52.198778] platform_hk.c:754 Assertion remote_ddr_mem_req->mem_seg[idx].addr != 0x0 failedparam0 :zero, param1 :zero, param2 :zero.
[   52.198778] Thread ID      : 0x00000072  Thread name    : wlan_platform  Process ID     : 0
[   52.198778] Register:
[   52.198778] SP : 0x4af7ccf8
[   52.198778] FP : 0x4af7cd00
[   52.198778] PC : 0x4ac94024
[   52.198778] SSR : 0x00000008
[   52.198778] BADVA : 0x00020000
[   52.198778] LR : 0x4ac937c0
[   52.198778] 
[   52.198778] Stack Dump
[   52.198778] from : 0x4af7ccf8
[   52.198778] to   : 0x4af7d090
[   52.198778] 
[   52.255673] remoteproc remoteproc0: crash detected in cd00000.remoteproc: type fatal error
[   52.277846] remoteproc remoteproc0: handling crash #5 in cd00000.remoteproc
[   52.286041] remoteproc remoteproc0: recovering cd00000.remoteproc
[   52.319058] remoteproc remoteproc0: stopped remote processor cd00000.remoteproc
[   52.613436] remoteproc remoteproc0: remote processor cd00000.remoteproc is now up

Can you give me some help?

qosmio · 2024-02-27T14:30:51.964Z

JuliusBairaktaris:

At what speeds does this become useful?

I have a 1G/1G fiber line, it can pretty much saturate on hardwire. But, on my M1, the M1->ROUTER averages 760mbps up, 895mpbs down, with 7ms unloaded and causes latency spikes (24ms+ download, 14ms+ upload).

Setting both to 769220/769220 brought me down to 4ms, and 4ms respectively. And have A+ score (From just A before)

However, I don't game on my Mac, and haven't had issues with setting my values to 90% of my actual speeds in day to day things like Zoom/Teams meetings, so I don't keep mine that restrictive. Running a P

JuliusBairaktaris:

On my 170/70 plan I don't get any buffer bloat and at higher speeds the consensus is that SQM Performance won't be able to keep up.

The idea is to set it to 80% (or 90%) of your upload and download, and only if you're noticing bufferbloat. Which in your case, you are not, so I wouldn't worry about it.

JuliusBairaktaris:

@qosmio I think the pbuf script is causing a memory leak.

Unless you have a specific need for it, disable it. Or start with smallest value of '256mb'. It doesn't play nice on 512mb platforms. I personally have left it off, but I'm not running heavy applications on the router that users have reported to cause OOM, or hung LAN activity (torrenting).

I'd actually like it if folks could make edits to /etc/init.d/pbuf and play around with the values for the 256mb profile:

extra_pbuf_core0=3100000
n2h_high_water_core0=30258
n2h_wifi_pool_buf=4096

Scenarios:

1.) Setting values JUST for extra_pbuf_core0 (3100000, 2000000, 1550000). Ensure you comment out n2h_high_water_core0 and n2h_wifi_pool_buf

2.) Setting values JUST for n2h_high_water_core0 (25215,15129, 10086) while keeping n2h_wifi_pool_buf at 4096. Ensure you comment out extra_pbuf_core0

3.) A mix of scenario 1 and 2.

Then carry on activities where you've noticed extreme LAN/WAN degradation (i.e. torrenting).

This would be very valuable as the run away memory usage on 512M platforms has been difficult to pin down.

More background on pbuf settings