@walmartshopper and @Barrakketh
On friendlyelec repo, besides these patchs for uboot and openwrt, do you guys see anything else that should also be add to oficial openwrt?
If im using the R4S with Openwrt only and have the below set up
OpenVPN
SQM
AdGaurd
What would be best way to set up the CPU affinity / IRQs?
Do i need to install any thing or just run a few commands to ballance the loads?
Anyone try the new NanoPi R5S yet? It has 2x 2.5Gbit and 1x 1Gbit. Looks very promising.
1 Like
I'm not familiar with uboot but AFAIK the new changes only disables UHS for part of the boot process.
Part of the changeset (I compared OpenWrt 22.03 with FriendlyWrt 22.03) that I overlooked is that one commit reverted the patch "rockchip: disable UHS modes for NanoPi R4S".
1 Like
Theres a few posts in there and a benchmark post. CNX software are waiting for theres to bench it too.
2 Likes
Use that for auto balancing loads.
or use the https://openwrt.org/toh/friendlyarm/nanopi_r4s_v1#cpu_management guide on the wiki if you want to balance to specific cores etc. Honestly it depends on your purposes. If you have 1gb connection its suggested you put the networking queues on the A72 cores. If you have a lower speed connection and need the A72s for load processing eg for docker. then you can tweak the cores that way. @walmartshopper has a few posts in this thread about how he did it for his camera processing
2 Likes
Cheers, so as standard does it only use 1 CPU?
Yeah i have 1gb internet wich it does hit the max of the network port. 930mb
@xShARkx post details it nicely.
Its not single core. but the default is to use both A72 (big) cores and then leave the network queues blank. but by setting your network queues onto separate cores for each port then you will get more dedicated resources.
1 Like
Thanks, I thought it was odd graph usage i have on interface that 4 where always on less then 1%
Im now see them with below % when running speedtest
Core 0 -1 40%
Core 2 - 3 3%
Core 4 - 5 6%
As @mercygroundabyss said, I've explained a lot on that post that he suggested! You can also check the wiki and other posts of this thread like my older posts which have a little bit more info and also @walmartshopper posts, since he is the person who actually shared the initial information\findings about the cpu affinity for the R4S like the commands, some tests and etc! I've only tested more, did some more research, figure out some new stuff and expanded upon it...
Anyway if you want to see the current affinity, you can use the following command in shell to see the queues:
cat /sys/class/net/eth0/queues/rx-0/rps_cpus
cat /sys/class/net/eth1/queues/rx-0/rps_cpus
Mine is hex 3f, which is the hex for all 6 cores! Yours and if you did not change anything or enabled package steering, will be 00.
And you can use these ones, to find out about the IRQ:
1 -> grep eth /proc/interrupts
2 ->
cat /proc/irq/27/smp_affinity
cat /proc/irq/232/smp_affinity
As you can see above its hex 10 for eth0 and hex 20 for eth1, in other words, IRQ affinity for eth0 is using core 4 and IRQ affinity for eth1 is using core 5.
The layout of the CPU of the nanopi r4s in openwrt is like this by default:
The first core is 0 and the last one is 5 since its a 6 core cpu, now for which one of those are the a53 and a72 we have the following:
Core 0 = a53
Core 1 = a53
Core 2 = a53
Core 3 = a53
Core 4 = a72
Core 5 = a72
As @walmartshopper explained before:
"The number you echo into the file defines which CPUs to use. It's basically a binary number where each bit represents one CPU, then convert that to hex. Rightmost bit is CPU 0."
Binary = hex = cpu core
000001 = hex 1 = cpu core 0
000010 = hex 2 = cpu core 1
000100 = hex 4 = cpu core 2
001000 = hex 8 = cpu core 3
010000 = hex 10 = cpu core 4
100000 = hex 20 = cpu core 5
001111 = hex f = cpu cores 0, 1, 2 and 3
111111 = hex 3f = cpu cores 0, 1, 2, 3, 4 and 5.
110000 = hex 30 = cpu cores 4 and 5
Just use binary and covert it to hex, 1 = select that cpu core and 0 = unselect that cpu core.
Examples:
#ETH0 irq on core 4(a72 core)
echo 10 > /proc/irq/IRQ-NUMBER/smp_affinity
#ETH1 irq on core 5(a72 core)
echo 20 > /proc/irq/IRQ-NUMBER/smp_affinity
#ETH0 queues on all 6 cores(0, 1, 2, 3, 4 and 5)
echo 3f > /sys/class/net/eth0/queues/rx-0/rps_cpus
#ETH1 queues on all 6 cores(0, 1, 2, 3, 4 and 5)
echo 3f > /sys/class/net/eth1/queues/rx-0/rps_cpus
Just keep in mind that only the queues will spread to as many cores as you selected, the IRQ won't! You need to pick 1 core for the IRQ of each eth and thats the reason why i keeped mine on core 4 for eth0 and core 5 for eth1 
I am still researching about this matter, cause yesterday i just saw someone using a different way of setting up the affinity in a rk3399 cpu:
4 Likes
Cheers, Yeah previously I got them wrong way around, but changed code to
#eth0 IRQ on A72 cores
echo 10 > /proc/irq/grep eth0 /proc/interrupts|awk -F ':' '{print $1}'|xargs/smp_affinity
#eth1 IRQ on A72 cores
echo 20 > /proc/irq/grep eth1 /proc/interrupts|awk -F ':' '{print $1}'|xargs/smp_affinity
#eth0 queue on A53 cores
echo 3f > /sys/class/net/eth0/queues/rx-0/rps_cpus
#eth1 queue on A53 cores
echo 3f > /sys/class/net/eth1/queues/rx-0/rps_cpus
which now shows same as yours
Ok, quite sure that's not the same behaviour on FreeBSD but I haven't tested recently
1 Like
What is difference between:
OpenWrt 21.02 2022.06.01 Latest
OpenWrt branch 21.02 (stable)
vs
OpenWrt 21.02 2022.05.01
OpenWrt branch 21.02 (stable)
?
Changes between those 2 are the commits that happened on openwrt branch 21.02 between those dates, also includes packages updates.
1 Like
OK I see now, looks like they only disable UHS during the SPL part of the boot process and then it gets enabled later. Maybe I'll try it on my next build.
Some of those other rockchip devices are another story, but for R4S the only unofficial patches I use are the immortalwrt reboot fix and and a 1.6/2.0 overclock, neither of which should be submitted to official openwrt. If we can get the new friendlywrt uboot patches upstream that properly fix the reboot issue, the R4S will be in good shape for official builds (at least the 4GB, not sure if the 1GB version needs additional patches).
1 Like
Can you confirm that patches 301 and 302 will solve the reboot issue? I use to do my own builds from OpenWrt official repository, and while waiting for my new R4S to be delivered I will prepare my image.
Since I understand that current OpenWrt code has a reboot issue, I would like to add these patches from FriendlyElec to my OpenWrt builds to have this issue solved (until these patches are officially added to OpenWrt repository).
In terms of me squinting at this image, you have an a72 core pegged at the 500Mbit setting with SQM enabled?
I keep hoping to get back "flent" results from testing things more coherently (torrent is a good choice, btw), would it be possible for y'all to run the test outlined over here w/without SQM?
I don't own a R4S so I can't confirm that, I was just doing my homework on potential new router options to see how well they were supported by stock OpenWrt and how much work I'd be stuck doing if I had to maintain a private branch.
1 Like
Completely stock OpenWrt on the R4S 4GB is perfectly fine as long as you are not planning on running docker applications from your SD card and don't care about overclocking. The official patch does fix the reboot issue, but it does it by completely disabling high speed signaling on the SD card. If you are not running docker apps from the SD card, then you would probably never notice the speed difference and there would be no need to maintain a private branch.
1 Like