No, oficial openwrt is missing the new patchs that were released by friendlyelec recently.
And also no, oficial openwrt is not spreading the load to all cores... You need to do that yourself and i am not sure if oficial openwrt will accept a PR to change that, cause i am pretty sure that they will argue that this needs to be left as choice to each person to make.
The new patchs need to be upstream to openwrt, but some dev who actually understands them needs to do it otherwise it won't happen in case modifications are needed.
And the load spread is not a patch, but simple file modification.
Starting from an ext4 installation to begin with, upgrading from luci to the sysupgrade ext4 image has worked fine for me.
I did note that after a sysupgrade storage space reverted back to the default partition size. So if you have increased it, you'll need to do that again.
I dont think its a good idea to compare and make conclusions from the results of another hardware, even more when this hardware is new, different and clearly needs some "fixing" in a more deeper level than cpu affinity it seems... From these unstable results.
Given your results from seeing the base setup for R4S and seeing the trend continue with the R5S, I think we can safely say that the defaults while "ok" are defiantly not optimised. Using only the big cores and not balancing the queues could be improved.
Honestly this is down to friendlyelec not properly pushing things upstream. That's where it should be done with proper optimisations so other distributions pick up better defaults.
OpenWrt should not have to fix others mistakes.
But at least with the Load balancing wiki entry there is now option for users to "tweak" settings to better match their usage, such as walmartshopper using big cores for his camera detection.
For what i saw from the images they released of friendlywrt for the r5s and commits on their repo, they actually try to setup the load to spread from the first release unlike the r4s that they copied and pasted the smp_affinity from the r2s, but it seems that there is something else which needs fixing in order for the r5s to achieve stable 2.5 Gbe speeds...
But yeah, frienlyelec way of thinking seems: "We are making available a custom image of openwrt designed for the hardware we make\release, so we don't need to help support and maintain the same thing on\with oficial openwrt"
So its up to someone else to do it... I would do it if i had the knowledge and experience myself, which i still don't
Also i still wonder if friendlywrt is indeed not better to use with friendlyelec hardware than oficial openwrt, right now sure it seems better to use friendlywrt instead, cause of the newer kernel, uboot patchs and etc...
But i also need to confirm some other things like cpu usage(i am not talking about spreading load but the % with same task), cause i got a feeling that its lower for some reason with friendlywrt and i got this feeling cause i have been switching between builds and systems since i got multiple SD cards in hand.
Well the bright side of this "situation" is that ppl can at least choose between more options
I think once the R4S is in stable openwrt then things will settle. The new 22.04 is "soon(tm)" and there has been a great many changes and updates. ip-tables to nft-tables being a biggy. New kernels and also some fairly major fixes which improve things overall.
Then we can look at maybe asking for PRs to tweak things.
Interesting performance tests on the R5S. Hope they keep working on FriendlyWrt and do a release once OpenWrt 22.03 releases. Not sure their patches will be incorporated into OpenWrt anytime soon unless it gets some interest. It'll be great to see if they can actually hit 2.5Gbit. Hopefully CNX takes another look at it after a few months.
Have you tried installing irqbalance and enabling it in the /etc/config/irqbalance config file? Checking software offload in the firewall menu could help a tiny bit too by freeing a few CPU cycles up. There are no doubt better options, but these are simple and could help.
You might also try installing and running htop in a terminal session while putting a load on Wireguard to see what each CPU core is up to.
Going to echo what was said earlier - the OpenWRT defaults for the R4S are fine for the general case of using it as a router and achieve gigabit throughput. In fact, it's ideally suited for VPN as well, where it efficiently places the primary burden (interrupts) on the faster cores and VPN encryption on the smaller cores, thus preventing VPN activity from interfering with general throughput for all users.
If you're going to do anything else with it (compute or server work at all, really) beyond network transport functions, the default won't suit you, and that's rather the point - adjusting it for your use case is trivially done and easily optimized for any workflow.
There isn't going to be any "one size fits all" answer because, by definition, there isn't one.
Not sure if this reply was directed to my question, but, even though I understand what you're saying, if it is, it feels a bit out of place for what I asked. If it's not, ignore this, maybe I misunderstood.
Either way, I installed one of @walmartshopper builds I found here with the 2.0GHz OC, and optimized a few things here and there and managed to get stable 300/200 Wireguard VPN speeds. It's not the same as my VM on my home server, where I can achieve speeds around 400-500mbps, but for a VPN running on my router I am happy with it. Cheers
Yes, i agree that for general basic use of networking, then the openwrt defaults for the R4S are "enough" for gigabit! But if you try to do anything more fancy and\or if you have high speeds, then stuff like sqm, snort and for many others "fancy" things, the defaults wont be enough...
As proven here is this thread, with ppl coming here asking for help cause they cant achieve high speeds with sqm, pppoe and etc with default openwrt, so that is the reason why i try to make ppl aware that they might need to ajust the cpu affinity if they want to do something more than basic networking.|
And to be honest, ppl are going to buy this device to be more fancy, otherwise there is no reason buy it and waste those 4GB or those cpu cores by only using the 2 of the 6 cores.
I haven't do it in like 2-3 weeks but i tested adding a wireguard vpn to my R4S which was nordvpn and i was reaching my full 500/250 Mbit/s connection, the only way to not reach those speeds were to use the vpn + sqm + torrent with unlimited connections, then i would lose like 100 Mbit or a little more.
Right now i dont have a vpn running on my r4s, cause i am switching from builds all the time testing and figuring stuff out, like those new u-boot patchs for the r4s and etc.
Maybe a different scenario? I have a VPN running on my R4S for me to connect from anywhere to home. I'm not using a 3rd party service. I already had one (also wireguard) running on a VM on my home server, but I wanted to try and use my router as a 2-in-1 since it has the horsepower for it.
I tested from work on a 1000/1000 connection to my home (1000/400) and those are the speeds I was able to achieve on a full tunnel VPN. If I use my old vpn on the VM (running on a Xeon W-2145), I get the speeds I mentioned, which are not that much higher.
fyi the new rc4 loads fine on R4S. I just tried it briefly as i was testing something else and needed a clean install. amazed me how tiny it was too. ( I was using the ext4 build not the squashfs)
I tested RC4 briefly too, all good so far. On the weekend my kernel 5.15 pull request got merged to master, which is also good news. I’m running 5.15 on my main R4S for more than 4 months… so far rock solid.
If i am not mistaken, you need to compile a snapshot yourself instead of downloading the one officially available, cause the kernel 5.15 was added as a testing kernel.
I heard somewhere that 22.03 might switch to kernel 5.15 before release and ditch kernel 5.10, but i am not so sure If it does not do it, then kernel 5.15 will only be available for snapshots until the next major release of openwrt.
