That's just it, my setup is completely standard, the only thing I changed from default settings is the AP names and passwords.
For what it's worth, most of the time when the radios crash out, this is what I see in the logs:
brcmf_msgbuf_tx_ioctl: Failed to reserve space in commonring
And no, I'm not running out of memory, it's showing about half of the 256MB of RAM free at the time.
I am running @ACwifidude build on my R7800 and it's rock solid and don't have any stability issues. Couple of days ago, got Linksys MR8300, which is a tri-band quad core router and am running snapshot build on it. It has a little bit better wifi coverage than R7800 and can't say about stability as I had it only for couple of days but from what I see, it has lots of potential and is on par with R7800, if not better!
Same amount of RAM as R7800 but is tri-band and is a quad core processor as opposed to dual core in R7800, so MR8300 might be marginally batter!
1 Like
Be careful mixing CPU apples and oranges.
Using a router as a dumb AP doesn't require much of its CPU. The MR8300 may very well have slightly better WiFi range in your use case and the extra radio for back-haul (if you have another device with an extra radio to use it with) is undeniably a great feature.
But that doesn't say very much about the CPU's.
The MR8300 has a quad A7 core ipq4019 CPU, that runs at only 717 MHz. The R7800 has a dual A15 core ipq8065 CPU running at 1.7 GHz.
The Cortex A15 core is roughly twice as efficient as the A7. In other words, running at the same clock rate, the A15 is still roughly twice as fast. Now factor in the clock rate too: each ipq8065 core is roughly 2*1700/717 or 4.74 times faster than each ipq4019 core.
An R7800 will run rings around an MR8300 used as a router, an OpenVPN client, or for CAKE SQM QoS. Having only two cores instead of four is not very consequential for these uses either, because they run on single cores for the most part.
Even for tasks that can take some advantage of more cores, like Wireguard or fq_codel QoS, the ipq8065 is going to be much faster.
2 Likes
My opinion is based on the performance between MR8300 and R7800 with the same set of devices on my network. The WiFi coverage is definitely better with MR8300. I don't use QOS as my speeds are at 500/500. With the extra band, the dedicated back-haul is a huge plus.
What you say about CPU is true but quad core will be an advantage in some cases.
MR8300 doesn't get as warm as R7800 even when I download several files over torrent. And, MR8300 is a dual boot/slot system and when something goes wrong, it boots on the other slot or you can manually switch it. To me, it feels that there are so many advantages over R7800 although it may be marginal for some users.
Btw, did I mention I snagged MR8300 as a refurbed device for $44 and it is practically a NEW device. Maybe, Linksys is trying to get rid of the inventory and sending NEW units as refurbs. OTOH, I paid two times more for R7800. Overall, I am quite happy with both R7800 and MR8300 but if I have to buy one today, it will be MR8300 without a doubt as the cost/performance is unbelievable!
OK, so I decided to get a HP T620 Plus thin client, with a quad-gigabit NIC and an Intel WiFi module. And the WiFi module is easily replaceable.
That gives me pretty much full modularity to replace any component that proves problematic. I'm staying away from Broadcom (because that is what my current R8000 uses) and Marvell (what this thread suggested is poorly supported and not upstreamed) WiFi modules, so I'm going to start with an Intel WiFi module and take it from there. Maybe switch to an Atheros if Intel also proves problematic.
Thanks for all the advice.
The MR8300 is a fantastic device for your use case - no argument from me on that point. If I needed wireless back haul (I don't - my home has wired Ethernet back haul), I'd definitely consider them - especially for $44 each! An ipq8065 device is nonetheless a much better choice for high CPU demand roles.
1 Like
Intel wifi as AP (STA) is worst than your broadcom or marvell. For openwrt 5ghz you basically have only 2 options Qualcomm (atheros) wifi5 (ac) or mediatek (both ac and ax supported)
In my experience, the time and money you will spend trying to get WiFi on an x86 platform working in AP mode with satisfactory performance and range will be much better spent on acquiring a dedicated wireless access point.
2 Likes
Given that I only get one radio and some of my devices don't support 5GHz, 2.4GHz-only is my only option anyway.
As long as it doesn't crash randomly and require power cycling to wake up, I'm totally OK with that.
And if it turns out I need to get a Qualcom module to replace the Intel, I can do that easily when it is on a mini-pcie card.
I have an x86 based router with a Compex Ath10k wifi card, and it works just perfectly (performance + coverage). Maybe you had a bad experience.
Nevertheless it's a single band wifi, so I have to choose between 2.4 and 5GHz, while a classical router/AP have both bands. That may be an argument for using a dedicated AP anyway.
And last not least ... I finally unclip the wifi card and only use the AP. It's only a choice of energy saving. The wifi card was heating 24/7 while rarely used. So I only power on the AP when I need it.
I also had some ugly crashes with an Intel card back in the 4.4 kernel days. I really hope it's fixed now 25+ cycles later as I haven't used one since.
You should get a Pi-router supported by OpenWRT and then just add a good Wireless AP to it.
Problem is, it's a lot more expensive, assuming you can actually get your hands on one, it think they're still in shortage.
NanoPi routers are still easy to get and not very expensive.
Interestingly, as more devices have come up on my network, both wired and wireless, and I installed and configured more features including relative CPU intensive ones (SQM, QoD, mwan3, adblock, snmp for monitoring), I haven't had a crash in nearly a week so far.
I am starting wonder if the reason for the various random crashes I have been experiencing is a bug in power saving on this SoC. My current theory is that when the SoC goes down to a certain level of deep sleep, sometimes it doesn't wake up reliably and instead hangs and crashes.
Does anyone know if there is a kernel boot or /sys or /proc parameter that can be tweaked to disable CPU power saving? I already tries disabling WiFi power saving and that didn't make any difference before, but since there has been a little bit more load on the CPU, it has been suspiciously solid, presumably because it no longer goes into as deep a sleep as frequently.
There is, but it might be platform dependant.
So going for a HP T620 Thin Client (x86-64) vs a "Pi Router": NanoPC-T6 (ARM) vs Asus TUF AX6000 (MT7986). Is there really a big difference? I also want a very stable network, handle more than 4000+ open connections and high traffic.
Ideally 2.5GB or higher on the WAN + LAN. My requirements aside, let's focus on the core question again;
would a x86-64 vs ARM vs MT7986 (and the mentioned models above) indeed be that much different in terms of stability on high throughput/traffic, 24/7 up-time, large nr. of connections, etc.?
If you say yes.. I really should go for a NanoPC-T6 instead of the Asus TUF AX6000 and buy a separate WiFi 6 AP, please let me know. Or even go for this HP system...?
All non x86 routers requiring more specific linux support to make them work nicely, once they are in kernel it should be working well (the former Nano Pi R4S with RK3399 is good example, rock solid as dual 1G ports router).
Currently RK3588 (the NanoPC-T6, I own NanoPi R6S which is almost the same) isn't upstream to LTS kernel so no official OpenWrt support (however some custom build right now showing quite good performance), the MT7986A just got it's support however the 4 x A53 is definitely a lot behind the RK3588 (4 x A76 + 4 x A55), while the upcoming MT7988 has 4 x A73 which performs a lot better (but no upstream kernel support yet). And BTW the TUF AX6000 is not getting official support yet, why would you consider if you really need stability?
incorrect - supported in snapshots