Wish I saw this earlier, since WAN and LAN can sorta distribute themselves (via mq qdisc) if you delete this patch from the mvebu target directory. It was introduced with this commit, addressing this bug. As far as I can tell, the upstream Linux maintainers for mvneta have not addressed this, even after the elapsed period of two years since discovering this bug that potentially affects millions of devices using this switch family (searched a through a boatload of mailing lists/patchworks branches). Whilst the swconfig driver is mvsw61xx, doing stuff to mvneta still affects OpenWrt/the switch.
Example output of cat /proc/interrupts in my build (with the aforementioned patch deleted @ around 20-30 mins uptime):
But I can see why the bug isn't addressed. It doesn't really affect traffic that is just passing through the router. For my use case, the router does not have much TCP/IP traffic originating from itself. In fact, even DHCP/DNS is on a different device (Raspberry Pi 3b+). Whilst I don't get affected by the multi flow bug since the traffic flows through the router, traffic originating from the router (e.g. VPN / NAS are what I can currently think of) may get bit with the bug.
EDIT: There'd probably more interrupts on CPU1 if I had a constant throughput in the 100-500 Mbps range (just basically using more computing resource). As of current, my router's utilization is limited to a NAT traversal device (no IPv6 since the country I'm currently based in have zero ISPs that offer it for the home consumer) with UPnP (yikes! I know) & Cake SQM shaping for packets.
Thanks for the reply, If you could rebuild the .ipk file for others not sure if you can recompile just that package and replace the old one. As of now i am still having issues with compiling OpenWRT keeps bailing with error 2 all the time, starting to run out of OS'es of the linux kind. Using Arch Linux right now after Centos and Ubuntu was giving issues.
As for seeing the changes my end i edit the files directly on the router, the joys of WinSCP then i copy the changes over to github.
Interesting. So an individual running and iperf/netperf/throughput test from the router to a host inside the lan would see this bug? I also noticed as pinning the 2 wifi irq's that there was still some activity on the switch side. Small but albeit seen. Moving the irq's for WIFI helps dramatically as not too overload the cpu0, obviously. I wonder if this should be a default setting OOTB?
Building in a VM will take longer than on the bare iron (even more so since spectre and meltdown mitigations had to be considered), but hardware accelerated VMs (VT-x/ AMD-V using kvm (on linux) or similar frameworks on other operating systems) still provide reasonable performance.
Yes, they would. But only for when you set the parameters to use more than four flows (and at full Gbit).
It probably should. Probs best to make an init.d scripts.
And with regards to your OSX stuff:
I currently build OpenWrt in Ubuntu 18.04 in Parallels VM (given to me for free when I was once a student) on a non-retina Macbook Pro Mid-2012 (Ivy Bridge 2 cores w/ 4 threads). Upgraded it to have a 512GB SSD and 16GB of RAM (of which the VM takes 64GB space, 8GB RAM, and 3 CPU threads). It takes about ~2 hours for me to build the prerequisites + image, but about ~45 minutes for me to build the image only. [Modified the build system to use autoconf-lean (adapted from nbd/Felix Fietkau's staging-tree) and GCC 9.1.0, make -j3 V=s].
Tues May 14 05:31:23 2019 kern.notice kernel: [ 0.000000] Linux version 4.14.114 (Pzd@PLLVM) (gcc version 9.1.0 (OpenWrt GCC 9.1.0 r7676)) #0 SMP Thu Mar 14 03:14:15 2019
I was using the following command to compile " make -j1 V=99sc " the R61e i am using only has 2 cores any how after all its a Core2Duo.
Will be doing a clean install of Arch Linux tomorrow and retrying.
As for inspired to make some changes in what manner? Your current build is a solid one and as the atmaterial theme goes, i am more then happy to hear suggestions from the rest of the users
Dear Dave ( aka the Inimitable Davidc502 ),
First off - I love your Builds - and the new build - r9987 is great and no issues here. I still did not get umdns working - but it is probably due to my own lack of understanding. Also by way of reporting back to you and The Community at Large - I was able to get WireGuard Client working with both TorGuard and NordVPN. I put up both tutorials in the OpenWRT Forum - see TorGuard here : Solved: torguard openwrt wireguard client and NordVPN here : Solved: nordvpn OpenWrt wireguard client
Just to let you know - I absolutely love the new theme - luci-theme-atmaterial which you have been asking us for our feedback on. It is clean and responsive. Regarding the upgrade instructions; now I am not an expert but the following commands worked for me.
cd /tmp wget https://dc502wrt.org/releases/luci-theme-atmaterial_git-19.133.50139-d94d70f-1_all.ipk opkg install luci-theme-atmaterial_git-19.133.50139-d94d70f-1_all.ipk
The trick is to issue the install command while still in the /tmp directory. This is how we were advised to update the wifi drivers back when you would issue updates between releases in the olden days.
By no means am I trying to contradict your advice;
I am just offering up what worked for me for those who may encounter any difficulties.
Thanks again Dave for all you do in pushing out these stable, progressive and up to date and cutting edge Builds of yours for all of us.
Hi. I use google translate. Congrats for this great project by the developers. I am a basic user in this of openfirmware, I own a wrt1900ac v2 router. I used a few days ago a compilation DD-WRT of 10/10/18 with which I obtained a low performance in wireless network of 5 and 2.4 ghz. I would like to know if this firmware is more stable than the DD-WRT 10/10/18 in the Wi-Fi since I am interested in the options of advanced QOS and place a small hard disk to share files in my personal network.
