It works. If I don't report anything else within the next 48 hours its stable (btw without echo 1 > /sys/module/mt76_usb/parameters/disable_usb_sg
).
Different thing though. Using the Argon theme if navigating to https://192.168.1.1/cgi-bin/luci/admin/network/network (Interfaces). I get TypeError firewall.getZoneColorStyle is not a function
.
Bootstrap works fine, just fyi not really important at all.
im seeing uneven load across cores after awhile of uptime with irqbalance. Uptime is about 10d. Doing speedtests to reproduce at high 7xx mbit/s up and down.
even after irqbalance restart the same behaviour is seem. I believe it was balanced across all 4 cores on a fresh install or maybe even reboot of the router.
after restart of irqbalance
Any thoughts why this is happening?
sed -i 's|irqbalance||g' /root/wrt.ini
echo "PERFTWEAKS_Gbs=1" >> /root/wrt.ini
/etc/init.d/irqbalance stop; /etc/init.d/irqbalance disable
curl -sSL https://github.com/wulfy23/rpi4/raw/master/ib/files-community_rpi4/bin/rpi-perftweaks.sh > /bin/rpi-perftweaks.sh
reboot
Happy new year!
FYI I found after using this, interrupts were all back on CPU0, throughput fine though.
Also I noticed, that if I change the wifi country to my country (from driver default), it will not come back up again. With some trickery like disconnecting the mediatek usb and reconnecting it to a different port, one can get it back up.
FWIW I experimented with IRQbalance for a days and found it frustratingly unreliable. In the end the only way I could achieve consistent results was to pin hardware / processes to specific cores.
I'm consistently achiving wire speed 1Gbps throughput with ~35% usage on each core with the PERFTWEAKS_Gbs=1 setting that @anon50098793 implemented above.
hmm I just tried this and CPU 0 is pegged using the waveform buffer bloat test. I wasnt able to get over 650mbps.
I guess this setting is YMMV?
The best results i get now is when irqbalance is enabled and packet steering option on the waveform test.
I get:
root@
reboot
cat: can't open '/sys/class/net/br-lan/address: No such file or directory
Because Iām using 2 separate interfaces for wan and lan? Does that affect anything else?
most of what it does happens at an eth0/eth1 level so id expect the 'effects' to be similar/the-same on your setup...
the main thing that would not is for people using eth0 as wan, in which case users should swap the interfaces devices in the steering section (rps/xps)...
So if my wan was eth1 what would I do exactly?
that's the recommended setup... so no action really required (afaik)
Note: this wasn't good testing on my part as I have a bunch of stuff running on my LAN right now but here are my waveform results with the PERFTWEAKS_Gbs=1
and nothing else tweaked, I ran it three times with about 1% variance and ~1Gb download each time.
Hi wulfy, thought you might want to know I implemented your perftweaks update script and it's hugely improved my performance having nlbmon pinned to a specfic CPU (didn't even know you could do this!). I was running SQM per host setting in advanced and it was killing my RPi4 prior to having the CPU pinning....now smooth as butter.
I checked the logs today and have noticed a bug has crept in NETDEV WATCHDOG: eth0 (bcmgenet): transmit queue 0 timed out. I have found this subsequent issue in github https://github.com/raspberrypi/linux/issues/4485. Hope this helps in someway.
UPDATE: Just actually read the full github and seems you also flagged this I disabled Packet Steering as suggested in earlier posts and the issue seems to have gone.
Out of interest if I set perftweaks=1 in wrt.ini that enables the CPU pinning of the processes irrespective of PERFTWEAKS_Gbs? Then PERFTWEAKS_Gbs=1 pins eth0 to core 2 (whereas eth1 - wan is on core1)? I have also enabled IRQBalance as this seems to improve the performance of my RPi4 and load seems to be balanced across cores - I assume (I haven't a clue) that the pinning and IRQ balance can work together?!
Still learning so thanks for your patience.
pretty much correct if you mean 'processes' like userspace stuff (nlbwmon/uhttpd/etc)... this is best referred to as TASKSET or TASKAFFINITY
On pointing this out to SubZero, i could not justify why i'd removed this for any other reason to 'see what defaults look like for a while'... I'd had that on for ages before... and re-enabled the 'TASKAFFINITY' section outside of the PERFTWEAKS_Gbs=1 logic (everyone get's it)
eth0 has two interrupts this stuff is best referred to as CPUAFFINITY/IRQAFFINITY or similar... eth1 is not 'pinnable' in a general sense... if you run irqbalance they can end up anywhere... if you run my script Gbs will get the two eth0 interrupts on 0 + 1 respectively... if you don't run Gbs, both stay on cpu0 for better latency...
for experimentation... you should create / fork the simpler code here and set
PERFTWEAKS_SCRIPT="/YOURSCRIPT"
and add that path to sysupgrade.conf after your experimentation would be good if you can share what values you felt worked better for you or send a version of your script so other people on Gbs connections can test and compare your findings...
Kind of a known issue for OpenWRT on Pis - I haven't had an opportunity to engage with the OpenWRT core dev team on the "proper" way to add https://github.com/raspberrypi/linux/commit/76f19e201af853569927b1c5740558ea3ae48bed.patch to OpenWRT.
By "proper" I mean how to have it apply only to Pi devices, because I'm assuming they won't want it applied to non-Pi brcmfmac devices.
For others, adding that patch file and renaming it so it is applied before 998-survey in https://github.com/openwrt/openwrt/tree/master/package/kernel/mac80211/patches/brcm should work for self-builds.
Anyone using master ('stable'/'current') be advised that
master is undergoing some firewall changes
Im shifting future master builds from 'current'>'testing'
verbage
and suggest anyone/everyone not use them unless you are
a very advanced user/know how to test/inspect your
firewall (or related service) at a low level
They could very well be safe... but i'm not willing to take
risks with other peoples routers...
Probably no point sending 21.02.x down as 'stable' as we have 'release'
The early indication is that master (builds) may be volatile / onhold
or discontinued (if the switch to nft is made... too many things for
one man to test / fix and whatnot likely for several months if
at all... although if you have nft skills etc. feel free to roll up
sleeves et. al.)
Most people are advised to change UPGRADEsFLAVOUR to 'release'
and switch to 21.02.2 when it arrives or when you next upgrade.
The current master r18436 is in a very good state an will likely last at
least two-three months fairly well without upgrading anyway...
Having said all the above... people who NEED to have master for X reason... feel free to voice your requirements... good for me to know
where to poke if I end up poking around...
i.e. I have/like to stay on master because I need ............... (etc. etc.)
OTOH... there is/was;
- Docker has a few minor improvements
- TBA (well AdguardHome has some new cool stuff on master but most of this is backported afaik... same with crowdsec or similar)
- TBA (one or two kmods only available on 5.10 master?)
....
I saw all those firewall4 changes in master, but didn't think it was enabled yet and have still been testing new builds. Noticed the LuCI package was updated to detect which version and (hopefully) display the features correctly. Haven't seen any changes personally yet but know they are coming and quickly. Thanks for the info.