I think that R7800 can't do that 900/150 without hardware acceleration, especially if you use SQM, VPN's etc. CPU intensive stuff.
There is experimental/ongoing-development NSS hardware acceleration for R7800 discussed in the forum, so if you want to try that NSS, you need to search for a build with NSS. My build does not include NSS.
R7800 with my build should probably do something like 400/200 or so. Software offloading would increase speeds somewhat.
(I have only a 200/60 connection, so I haven't much looked into the gigabit speeds.)
r18650 was running fine for 3 days: no more reboots. I now installed r18683: All went well so far. I am a bit hesitant to enable SQM again, but I would prefer to have it enabled. Should it work on these newer builds?
I'm just sticking with r18609 until the firewall4 issues are closed. For me, SQM is the most important part of openwrt. After a router crash, are you seeing any crash logs in /sys/fs/pstore/dmesg-ramoops-*?
Yes I would like to have SQM enabled, but downtime is more of an issue to me. Even with 18609 with SQM enabled I had crashes. I do use vlan as well, so it might be my exotic configuration.
The newer builds without enabling SQM seems to work well so far. I will enabled SQM tomorrow if things are stable on the 18683 build. Hopefully I can report back some good news, otherwise I will look in the crash logs!
@kiss81@illumiN8i
Just wondering if either of you had tried the new Qosify?
I saw it was added a few months ago and tried it out... I didn't test it extensively, but it seems to work pretty well. Would be interested to hear your experiences as well. Not sure if this would change the stability for you on newer builds.
daemon.err nlbwmon[12723]: Netlink receive failure: Out of memory
daemon.err nlbwmon[12723]: Unable to dump conntrack: No buffer space available
I have seen these errors as well (for a long time) and wanted to see if increasing the buffer size would help.
I made the change you posted ( option netlink_buffer_size 1048576) in the config file, but after a restart I checked the system log and saw this:
daemon.err nlbwmon[17060]: The netlink receive buffer size of 1048576 bytes will be capped to 180224 bytes
daemon.err nlbwmon[17060]: by the kernel. The net.core.rmem_max sysctl limit needs to be raised to
daemon.err nlbwmon[17060]: at least 1048576 in order to sucessfully set the desired receive buffer size!
I changed it back to the default value of 524288 and after restarting got this error as well (but with the appropriate buffer size number). From the looks of this, the default value isn't even being used - which might explain why the out of memory keeps happening... it won't go above 180224 in my case.
Were you able to change this limit net.core.rmem_max and If so, how? I am wondering if this is a bug as I haven't messed with any of this before - so perhaps hnyman can shed some light for me? Is it as simple as I need to restart the device, not just the service?
Would this be considered a "bug" that the buffer for netlink is defaulted to a value higher than the sysctl is limited to? Not really a bug but a misconfiguration? Just wondering if end users should be adjusting it, or if (for example) you would fix that in your builds now that it has been uncovered (assuming that it's not just me).
after you restarted the service (nlbwmon) check you system log and see if you get the same error I am getting.. perhaps the changes you are making and being blocked like mine. That would explain why you are still getting the errors even after increasing the buffer... it isn't allowing it.
Tue Feb 1 22:05:16 2022 daemon.err nlbwmon[9914]: The netlink receive buffer size of 2097152 bytes will be capped to 180224 bytes
Tue Feb 1 22:05:16 2022 daemon.err nlbwmon[9914]: by the kernel. The net.core.rmem_max sysctl limit needs to be raised to
Tue Feb 1 22:05:16 2022 daemon.err nlbwmon[9914]: at least 2097152 in order to sucessfully set the desired receive buffer size!
Yes is capped. Will change rmem max to 524288 and change nlbwmon to default again
Indeed it has not point to set it to 5xxxx ++++ if the kernel doesn't allow it.
I know that Kongs build had 1048576 in nlbwmon conf but i don't know if the kong kernel allows that.
It got everything I need, but for me it's a bit overkill I think, but I might give it a try if SQM keeps giving me troubles. I will post my experiences when I do.
I enabled SQM again on the 18683 to see if it's stable...
