Hi I am seeking for a good solution to my home wireless network.
We're currently on VDSL with sloooow speed (70/10 Mbps), but hopefully soon will be getting better internet. Provider claims it'll be 950/500 Mbps, so huge improvement.
It's not that we currently suffer a lot (currently using Netcomm AC1600), but farthest from the router person sometimes complains about slow wifi.
So I'd like a router that wouldn't be a bottleneck.
We have 4 wifi consumers (quite active) with 2-3 devices each (phone + laptop + desktop).
Our house built in the way that distance between the most distanced consumers rooms is about 10 meters and ~2 meters elevation. Walls and doors on the way as well.
I personally like Asus, as I had one long time ago (WL500G) and I got attached to it after installing a custom firmware. Do they still reliable hardware?
Questions I have:
Does it would make sense to aim for tri-band. Would it really make any difference in our case?
Would mesh network be better approach to tri-band router?
Budget - not sure, from what I saw they start from $250
A link speed of 950/500 Mbps requires a router with a fast CPU (x86_64 or ARM), see the benchmarks.
When the provider's equipment suffers from bufferbloat, deploying SQM can improve the latency under load, but raises the CPU demand further.
Using separate devices for the router and WiFi access point is probably a good idea here.
WiFi speed for far away users can be optimized by installing additional AP's closer to the users, preferably connected to the main router via wired ethernet.
I do not own any recent Asus router. In addition to the brand, I would also consider OpenWrt support, the hardware specs (SoC performance, WiFi speed and drivers, Flash and RAM size), availability (new or used) and price.
The additional radio is useful for the backhaul when you cannot install a cable.
Tri-band APs improve the overall throughput when the backhaul is wireless (mesh or not).
With a wired backhaul, which I recommend, consider increasing the number of APs instead of using tri-band devices. This gives you more flexibility in their placement such that each client is near an AP and gets high data rates.
I don't use a wireless mesh network myself. As I understand it, three or more APs maintain wireless links among each other and figure out the best route for the data packets. Where the best route is obvious, such as with 2 APs only, or with 3 APs in a linear constellation, you can just set up the links manually, and mesh does not provide much advantage.
Some vendors use a central controller to manage access points and call that "mesh". This can be a useful feature even when the APs are connected with cables, but will only work among devices from the same vendor, and only with vendor firmware.
With this kind of link speed I would definitely build a custom x86_64 if you're wanting to use SQM or anything other than basic routing functions. Most off the shelf routers will struggle to do anything other than route at this speed.
I've been using Supermicro mini-ITX boards for years. I'm on my second one the A2SDi-8C-HLN4F.
The 4-core version should be more than sufficient for your purposes. Probably a little more expensive than your budget when you add the RAM, an SSD and a wireless module, but will handle your link speed well.
My 8-core version uses about 90% of a single core when SQM layer cake is running and both snort and softflowd are running on the lan interface when it's downloading a single stream at 1Gbps (SQM, snort and softflowd generate lots of softirqs / cpu usage).
Other cores are close to idling except the snort one which runs at about 20% - 30% usage. If I'm not running snort or SQM or softflowd, then a single gigabit stream will load one cpu core at around 40%, hence why I say the 4 core version is good enough. With multiple download streams it barely breaks a sweat.
A good wifi card would be the Compex WLE1216VX. I used to use an older version and the ath10k is well supported by Openwrt.
Now, since I live in a much larger place which requires multiple APs, I stopped using the internal wireless module and add a couple of Ubiquiti Nano HD APs (using the oem firmware) on a MoCA 2.5 wired backhaul. I don't think you need to go this route given the distances you mentioned. A decent enough wireless module with some high gain antennae will suffice.
The most cost effective high performance system is the RPi4 RPi4 routing performance numbers with a smart switch and probably two wired APs, EAP devices from tp link work well
Interesting thoughts. Haven't thought about building my own router. Could be a fun project.
What software is your build on? OpenWRT? Wandering how do you measure those loading metrics?
Thanks for the links to specific hardware too.
Is there a place where people share there builds and experience?
Lots of people here have built x86 routers, do a forum search and you'll see some examples (including some examples I helped people figure out). I do think that today, the Rpi4 is a cheaper route and has way more than sufficient levels of performance.
Yes. Openwrt master. It was on 19.07, but I updated recently.
either htop or top will show sirq use. htop can be configured to show it graphically per core, showing both percentages and a slider that is coloured differently depending on whether it's a user process, kernel process, sirq, etc.
One thing that linked thread doesn't mention is that while the ARM v8 SoC on the Pi 4 has AES instruction support, the Pi foundation didn't license it, so it's not available on that board. So if you think you might run a VPN client on the router you'd probably be better off going x86_64 or equivalent. (But do be aware that even some Intel SoCs lack it as well; notably the j1900 that you find in so many of those cheap NUC-alikes from Amazon and Ali.)
True enough, that silicon isn't there on the pi... However, it's a fast processor, here's the openssl speed aes results (one core saturated):
Doing aes-128 cbc for 3s on 16 size blocks: 13936404 aes-128 cbc's in 2.99s
Doing aes-128 cbc for 3s on 64 size blocks: 3750364 aes-128 cbc's in 2.99s
Doing aes-128 cbc for 3s on 256 size blocks: 982612 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 1024 size blocks: 247743 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 8192 size blocks: 31009 aes-128 cbc's in 2.99s
Doing aes-128 cbc for 3s on 16384 size blocks: 15539 aes-128 cbc's in 3.00s
vs on a j1900:
Doing aes-128 cbc for 3s on 16 size blocks: 12419901 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 64 size blocks: 3428222 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 256 size blocks: 894364 aes-128 cbc's in 2.99s
Doing aes-128 cbc for 3s on 1024 size blocks: 225700 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 8192 size blocks: 28023 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 16384 size blocks: 13989 aes-128 cbc's in 3.00s
So the Pi4 is somewhat faster than the j1900 at AES in software.
The 4-core version is plenty fast enough too; you don't really need the 8-core variant for a single gigabit connection. They're not cheap. But it handles a gigabit connection with ease.
A single gigabit download stream, though, if you're running SQM with ingress filtering turned on and using layer_cake, will pretty much max out the core it's running on, so it's not entirely overkill. Turn off SQM ingress filtering and the core usage drops to about 30%
I have ported all the Intel quickassist hardware crypto drivers for this platform to openwrt too, so it has openssl hardware acceleration (I'll make it available for public download soon).
I don't necessarily think you should be looking at AES speed to judge the platform suitability though. It's the network TX and RX softirqs that eat up cycles.
But if you're curious...
Doing aes-128-cbc for 3s on 16 size blocks: 54264049 aes-128-cbc's in 2.99s
Doing aes-128-cbc for 3s on 64 size blocks: 21841967 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 6204586 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 1652780 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 8192 size blocks: 210250 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 16384 size blocks: 105261 aes-128-cbc's in 3.00s