Rpi4 < $(community_build)

now, this,

/dev/sda1: SEC_TYPE="msdos" LABEL_FATBOOT="boot" LABEL="boot" UUID="EBD7-05FF" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="12200438-01"
/dev/sda2: LABEL="rootfs" UUID="ff313567-e9f1-5a5d-9895-3ba130b4a864" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="12200438-02"

upgrade flavour is set to stable in the wrt.ini files. I just checked

1 Like

woohoo! second bug you found! you are good at this!

FIXED :crossed_fingers:

above was correct/ok/good, sorry I clobbered it resetting to defaults...

1 Like

I'll keep you posted!
do i need to change stable to release?

1 Like

yeah... looks like you have 21.02.x so release is/was correct (sorry) but you can change to your liking at any time also... (might take 1 more min for github to propogate)

1 Like

and its working now!

1 Like

winner!!! :1st_place_medal: :1st_place_medal:

1 Like

Hi @anon50098793 firstly thanks for the amazing build and continuous releases just awesome!

Not sure if this is a bug but recently I'm getting this message in the log The net.core.rmem_max sysctl limit needs to be raised to least 1048576 in order to successfully set the desired receive buffer size! thought you might like to know just in case there are some adverse effects by not setting this correctly. Can't say I've noticed but hey I'm just an amateur in the networking world.

Keep up the great work!!!

1 Like

cheers... and good to get reports...

that's an odd artifact/message related to nlbwmon... i've set the sysctl's it's requested in a few different ways but the messages keep reappearing...

there are a few posts on the forum about it...

[root@dca632 ../_HTTPS-DNS-DEBUG 55°] logread | grep rmem
Wed Dec 22 21:02:20 2021 daemon.err nlbwmon[5542]: by the kernel. The net.core.rmem_max sysctl limit needs to be raised to
Wed Dec 22 21:02:25 2021 daemon.err nlbwmon[8108]: by the kernel. The net.core.rmem_max sysctl limit needs to be raised to
Wed Dec 22 21:02:26 2021 user.warn kernel: [   61.323646] 01-sysctl> /etc/sysctl.d/19-nlbwmon_rmem_max > '1048576'
Wed Dec 22 21:02:26 2021 daemon.notice procd: /etc/rc.d/S95done: net.core.rmem_max = 1048576

nlbwmon basically says XYZ is not XYZ > lowering

could have done something wrong (ok looking at the log... now seems I apply the setting a fraction too late) or could be an interface restart runaway sysctl or something... but yeah afaik... false positive...

will move it to the nlbwmon init.d script (or similar)... thankyou!

woohoo! :1st_place_medal: and it's gone!

[ /usbstick 57°] logread | grep rmem
Wed Dec 22 21:58:11 2021 daemon.notice procd: /etc/rc.d/S60nlbwmon: net.core.rmem_max = 1048576
Wed Dec 22 21:58:19 2021 daemon.notice procd: /etc/rc.d/S95done: net.core.rmem_max = 1048576
Wed Dec 22 21:58:19 2021 user.warn kernel: [   59.960211] 01-sysctl> /etc/sysctl.d/19-nlbwmon_rmem_max > '1048576'
1 Like

First time using Pi4 and your build, I have onsys:3.5.317-15 installed on a rpi4 8GB with a USB3 r8152 adaptor for WAN.

By default my connection speed tops out at around 510Mb/s.

When I cat /proc/interrupts I get this:

           CPU0       CPU1       CPU2       CPU3       
 11:       7819       5516       5742       5322     GICv2  30 Level     arch_timer
 18:       2759          0          0          0     GICv2  65 Level     fe00b880.mailbox
 21:          2          0          0          0     GICv2 153 Level     uart-pl011
 24:         45          0          0          0     GICv2 114 Level     DMA IRQ
 31:          7          0          0          0     GICv2  66 Level     VCHIQ doorbell
 32:      20654          0          0          0     GICv2 158 Level     mmc1, mmc0
 39:     114101          0          0          0     GICv2 189 Level     eth0
 40:      29685          0          0          0     GICv2 190 Level     eth0
 46:          0          0          0          0     GICv2 175 Level     PCIe PME, aerdrv
 47:     217562          0          0          0  BRCM STB PCIe MSI 524288 Edge      xhci_hcd

I was expecting eth0 to have affinity with a different core, so I manually set it to core 1 like this:

echo 2 > /proc/irq/39/smp_affinity
echo 2 > /proc/irq/40/smp_affinity

And now I'm hitting close to 1GB downloads - which is amazing! (thank you - great work!)

I thought IRQbalance was supposed to do this for me, is there something I need to do in order to active it? Or is the manual approach above the recommended solution?

Also when running speed tests CPU core 0 is hitting 99/100 percent, at the stock 1500Mhz, is it possible to enable an overclock to 1650Mhz or 2Ghz? I tried editing /boot/config.txt and adding:


But this didn't work, HTOP is still reporting 1500Mhz.

howdy, merry christmas :wink:

will have to check my notes, but looks like a bug in /bin/rpi-perftweaks.sh (will take a look, thanks for the report!)

if you enable it, probably will, i don't use it, will render the above bug mostly irrelevant

maybe? i don't use config.txt overclock for a number of reasons, but there is a post or two in this thread or on the general forums about it so feel free to experiment...

as you are running 1G, I suggest you;

cp /bin/rpi-perftweaks.sh /bin/rpi-perftweaks.sh_SubZero
echo 'PERFTWEAKS_SCRIPT="/bin/rpi-perftweaks.sh_SubZero"' >> /root/wrt.ini
echo "/bin/rpi-perftweaks.sh_SubZero" >> /etc/sysupgrade.conf

then edit this file to your liking and share back with the rest of the community when happy...

( you can even just put exit 0 and enable irqbalance if thats what you want to do )

if you search this thread for PERFTWEAKS_SCRIPT you may find more recommendations or info for faster links...

Merry Christmas!

where did you set these?

echo 2 > /proc/irq/39/smp_affinity
echo 2 > /proc/irq/40/smp_affinity

so... it appears I manually/deliberately stopped assigning eth0 interrupts to different cores...

not sure why I did that, so will think about it some more... and search thread for reminders...

for a long time... (and from the top of my head) the build set 1st eth0 interrupt to core0 and second eth0 interrupt to core1, i'd recommend this for links over 600M as a beginning/baseline setting;

echo 1 > /proc/irq/<ETH0INT_0>/smp_affinity
echo 2 > /proc/irq/<ETH0INT_1>/smp_affinity

where do i set this?

echo 1 > /proc/irq/<ETH0INT_0>/smp_affinity
echo 2 > /proc/irq/<ETH0INT_1>/smp_affinity

see above...

if you are unfamilar with performance-optimization/script-editing then irqbalance may be a simpler option...

I want to run rpi-perftweaks.sh on boot automatically, how do i do that?

already happens...

##### [ /usbstick 53°]# dmesg | grep perftweak | tail -n 1
[  179.868694] rc.custom> raspberrypi,4-model-b perftweaks /bin/rpi-perftweaks.sh [run]

fyi, for any (future) users with the seeed carrier... a kmod(.ko) is currently available here (21.02.1 only):


while it might be a little bit of a pain to install on this build for beginners worth mentioning... ( thanks sergey! )... when an official ipk becomes available for usb-net-lan78xx i'll add it to the build (even tho' it's unlikely there will be more than 1-2 seeed users afaik at most)


and add those two commands to the end of the file, save, reboot.

On the snapshot that I installed, by default, core 0 is taking the load for just about everything. I guess this just isn't an issue for users with a connection of 0.5GB or less as a single core can cope. But on faster connections CPU affinity is critical.

I experimented a little with IRQ balance and packet steering, they work but not consistently, there seems to be a lot of volatility in how they distribute the load.

Manually assigning both eth0 interrupts to core 1 seems to be enough most of the time. But core zero is still hitting 100% when the data collection services are running.

My lazy fix is to overclock the Pi4 to give it just a little more headroom under load, but the better solution would be to manually distribute heavy services to specific cores. And given that the RPi4 is a known quantity, and the vast majority of users will be using a USB3 dongle, it seems reasonable to setup a default profile that just assigns all of this stuff at boot.

So my next question: is it possible to start services on specific cores?

PS I still can't find a way to overclock the Pi4 using OpenWRT - I'm a newb! ¯_(ツ)_/¯

1 Like

as there is no one size fits all solution, examples are provided in the build as well as hooks for using your own script as discussed above
( tried it several times already, what works for one does not necissarily work for others, and guess who ends up holding the pieces? )

you will find examples in the sample script already implemented
(nope: that was removed too search this thread for TASKSET or taskset)

more than happy to include anyone's suggested script within the build

this is currently the most practical way forward until broader user input or knowledgeable (succinct) test data is provided