Hi, I am currently running a recent regular snapshot. I understood that there are quite some issue left w.r.t. the R7800, as in:
latency spikes: my assumption is that these are solved?
NSS drivers not installed, because frequency scaling doesn't work: currently WIP.
CPU frequency scaling not working properly, resulting in delays and/or reboots.
sub-optimal (or even no use?) of dual core: IRQ's need to be appointed to a CPU manually to ensure efficiency here.
MU-MIMO not working: as far as I know this isn't working on any router yet.
any other known issues?
Therefore, I am considering hyman's build.
I don't suffer from reboots, but my internet isn't fast. I am just doubting if I should continue with the R7800, go for a Linksys WRT-32X with OpenWrt (Davidc502's builds) or switch to something like Ubiquity.
Forcing the NSS CPU to a fixed frequency worked around the stability issue. My R7800 has been up for more than 3 days now with the NSS cores accelerating routing functions. At the moment, my builds are based on lede-17.01 tho.
If you don't mind running a v4.4.x kernel, you can try installing my builds and see if it's performing up to your expectations. At the moment, we need more people to test in order to surface major issues.
R7800 has good all around OpenWrt support but people seem to have different levels of success as with the issues you point out. WRT32X is an excellent OpenWrt router too, with 940Mbit routing performance, fast SQM, 80 MB/s USB storage speed, cheaper price, great looking, etc. but has some missing Wi-Fi features because the mwlwifi driver was unfortunately abandoned by Marvel, so it doesn't do MU-MIMO or Mesh. I'd say both routers work well and are about equal overall with their own pros/cons.
Thank you for your good work. My post might have been a bit less polite. Hopefully Inhave some time to test your build this weekend, although I am not that technical. Stupid(?) question: is it possible to install and configure the NSS drivers in a snapshot build? Same question for setting the CPU to performance and sorting uit the IRQ issues.
Should be possible, but my attention at this point is to make the NSS drivers usable enough for my R7800 for lede-17.01 branch, i.e. kernel v4.4.x first. Then I'll proceed to port over to master, which is on v4.19.x. The NSS drivers are targeted for the v4.4.x kernel, but from what I understand so far, it shouldn't take too much effort to port it to v4.19.x. Hopefully I'm right.
In any case, v4.4.x is on LTS until early 2022, so it should still get security and bug fixes and it's still maintained by the OpenWRT folks.
The v17.01.7 release will also mark the end-of-life of the LEDE 17.01 series - we'll decommission the LEDE 17.01 related build resources and repurpose them for producing 19.07 binaries.
That's a shame. For some reason, v4.4.x LTS EOL is 1 year later than v4.19.x which is projected to end by Dec 2020. v4.4.x EOL is projected by Feb 2022.
So it looks like OpenWRT will be moving to v5.x next year.
What if you just run it once a week with --oneshot as part of a cron job, as suggested by @ hnyman? irqbalance caused crashes and freezes on my router when I used to have it running all the time, though it could be a coincidence too.
Well, this implies that one can predict the future based on the past only, with is not true.
A while ago I found that in my case it is beneficial for this router to split the CPU cores by dedicating one to processing network interrupts and the other one for all the other processes like dnsmasq, hostapd, collectd, nlbwmon, etc with no cross pollination. Everyone's milage will vary, but when I stopped doing that (decided to save some time by using the image builder) I started hearing complaints that the gaming experience suffers: a game-server party of 12 becomes a slide show apparently and the max party size dropped to 8...
Another option (that I am playing with right now) is to have both wifi's and all processes on one core and wired LAN/WAN/SQM on the other. It also looks pretty good so far.
From what I understand, SQM is gonna be on the same CPU as the WAN port (eth0). It is beneficial for gaming to have both LAN (eth1) and WAN (eth0) on the same CPU.
OpenWRT is missing tools for fine-grain CPU affinity control, so the nuclear option here is isolcpus=1 or isolcpus=0 (a kernel boot parameter that requires building an image): it takes a CPU away from the kernel and it will never place any process on it. So all processes are now running on the other CPU and the isolated one can be manually managed by assigning IRQ's to it.
The CPU irq tweaking discussion and the performance discussion would be better placed in the R7800 exploration thread, as this has nothing to do specifically with my build.
There is no specific change made to my build's wifi or network components in 18.06. And also in the main OpenWrt sources, there are just a few kernel bumps and a hostapd security fix, but hard to see how that could have cut throughput severely.
ipq806x is still at kernel 4.14 and looks like cake was deleted from the source tree by @ldir due to a (wrong) assumption that all major targets are already with 4.19 that includes cake in the upstream Linux.
There will be trouble in building SQM for ipq806x as cake is a dependency for it.
Edit: Looking at the buildbot snapshots, the cake kmod still gets built, but is empty. So, SQM can still be built, but cake qdisc will not work.
Ah, ooops. Yes indeed I thought that relevant targets were on 4.19, or at least soon would be. There's been discussion about trying to reduce the number of packages/specials held in the base repository, cake at least was marked as something that didn't need to be there.
The patch was in patchwork for a week or so and got no response. I'll have a chat whether a possible direction is to put an 'out of tree' version in openwrt/packages.