??? memory saving? 60Mb?
Is the new code also in master? i last build it last week (r17468) should i re-build?
i want 60 more Mb to fill with stupid things! 
slh
1151
Unmodified master doesn't use any NSS cores, accordingly all of the RAM reserved for those in these NSS builds remains available there (simplified (wrong) calculation, +120 MB).
do you mean non-nss master?
i was referring to @ACwifidude 's master NSS..
The NSS1 delete is in yesterday’s master build and last week’s 21.02 build. Same performance - just dropped NSS crypto support (wasn’t using it anyways).
Memory use looks good:
as far as i can remember, nss crypto functionalities never got good enough to be proficiently used, isn't it? i can remember some @quarky 's topics on performance of crypto cores, far slower than pure-software calculations, so it seems not a big loss.
Trying to build it this afternoon.. thanks 
1 Like
quarky
1155
Yeah. The overhead of moving data between kernel and user space killed of all the benefit of using the crypto engine. Hopefully the OpenVPN DCO kernel driver will be done soon. With that we can revisit using the crypto engine to relieve the CPU from crypto duties.
4 Likes
i'm on r17516 now, i saw no memory advantage 
it's good anyway
Wonder how hard this will be. I’ll take a stab at this this weekend and post any errors I encounter.
Will move the requisite patches over to the 5.10 folder and try to troubleshoot / figure out the major differences between 5.4 vs 5.10 for NSS. 
3 Likes
Ok after a prolonged use and reports by other people in the house I conclude that the NSS builds are definitely LESS STABLE and more prone to random disconnection even of stable laptops with good reception, than the HNYMAN 21.02 stable builds. I use ath10k (not ct) on both - in HNYMAN's case this requires some SCP and Telnet action.
But yeah, his build is stable, and this one, while seemingly providing faster speed sometimes, is "adventurous".
Sorry to hear. Post any logs you have or if you suspect a particular feature is causing the issue.
There is always the potential of a bug in the NSS 10.0 firmware that is causing an issue for you. Any unique configuration options selected?
I'm not advanced enough to monitor logs for the right things. The router is just a wired-to-wireless extender, R7800, simple config, no SQM. I do set RTS threshold to 512, which is unconventional, but I'm pretty sure the instability was happening before that too
xeonpj
1161
If you only use it for a Wi-Fi connection and it still ends up crashing, it has to be something at the core level nss, yes or yes, no? if it is from the driver, there is little solution, right?
my router is a lot more stable than it was in a long time, but still, one day, for some reason, it reboots. It is also true that you put the image, and it lasts, for example 30 days, it restarts, and it never lasts 30 days, at 15 it restarts again, and it seems that it lasts less and less time. still, nss the work is very good
quarky
1162
My R7800, running my 21.02 custom build is up almost 33 days now. It's running as an AP and also running an OpenVPN TAP tunnel to a remote network. Usually have 3 WiFi and 3 LAN clients connected to it. Seems stable so far.
My 'new' Askey-RT4230W on the other hand is prone to the 2G WiFi interface firmware crashing, while the router is still running. 5G appears stable and the router is not crashing. Granted, I only got the Askey recently and has not put it thru it's paces, but initial run doesn't look promising. It appears to be heat related, so I'll be taking it apart and reapplying all the thermal paste and pads as necessary to the heat sinks and test again.
These routers may be prone to heat related problems so that's an area to investigate.
xeonpj
1163
could you pass a copy, and try?
I am using the official 19.07.8 but my 600/300Mbps fiber connection stress a little too much the router. I am really willing to try this NSS build. Can i upgrade keeping my settings? Its safe enough to try?
My primary R7800 runs on 19.07.8 and gets 900/900mbps even without software acceleration enabled.
In regard to your question, an upgrade will likely work, but you can expect to inherit the loopback bug not present in version 19 (aka FTPing to your own FTP server via external IP suddenly doesn't work), and of course you can't use SQM unless you configure it via command-line and stick to fqcodel-NSS only.
1 Like
You’ll need software offloading (SFE) or hardware offloading to get anywhere near line rate for routing purposes (WAN <=> LAN) with an ipq806x device. Routing is different from running it as a switch. LAN <=> LAN yes - possible to get line rate.
1 Like
quarky
1167
Unfortunately as I'm running QSDK 11.2 with the 11.2 NSS firmware, I'm restricted from distributing it, as I do not have any distribution rights.
The firmware built by @ACwifidude should perform the same as what I built. I would suggest trying the master NSS builds from @ACwifidude as it includes the CPU L2 freq. driver back-ported by @Ansuel which I back-ported to my 21.02 repo. The L2 driver should help in router stability.
Edit: Btw, do you mind telling me the router that you're using? I suspect you may be encountering the NSS core freq scaling issue. The router should be stable if the NSS cores are forced to run at it's max speed. If the core freq scales, it will sometimes spontaneously reboot without any logs printed.
I have two R7800 routers. Primary one is running final HNYMAN 19 version. I get 900up and 900down on sites like speedtestDOTnet, even with software offload disabled on the primary router. Of course the primary router also has wifi disabled because that function is relegated to the second router.
quarky
1169
You should be running the router with the performance CPU governor then. I would think that the CPU would be maxed out trying to process all the netfilter rules that it doesn't leave much CPU cycles for anything else when going out full whack.
2 Likes
