@slh
This devices have already an installed OpenWRT version. The vendor has done changes to the system, for example Web GUI, but the core is OpenWRT.
So just another vendor firmware loosely based on OpenWrt, not OpenWrt…
--
no, this is not baseless nitpicking, it matters a lot if you need anything beyond what the vendor has included in their derivative (kernel modules, …) - or if you want to update in the future.
2 Likes
Absolutely correct, but there are other models from the vendor already listed at the hardware table.
I personally would highly appreciate direct OpenWRT support for this newer models.
2 Likes
Likely Qualcomm IPQ40xx based. Not too powerful with their quadcore 716 MHz 32-bit ARMv7 processors.
4 Likes
Since we have top routers pushing 500-600 Mbps with SQM cake right now I assume these upcoming WiFi 6 / AX routers will get pretty close to 1 Gbps with SQM cake since they have faster CPUs. It's a couple years away for OpenWrt support since it'll be the release that follows 21.02. Best to stick with one of these top routers for now, and wait to see which WiFi 6 router emerges as the best for OpenWrt once that happens and get one then (the IPQ8074 might be promising who knows).
2 Likes
You'll probably be the first to find out.
Yes, the wifi6 routers are generally faster (at least those based on ipq807x or mt7622, not the first mt7621+mt7915 generation), routing 1 GBit/s shouldn't be an issue for those - but also doing sqm at 1 GBit/s line speed would be another question. So far no one has reported test results with these devices (well, currently only mt7622+mt7915 is available for OpenWrt) under those conditions yet.
hello everybody liinksys EA8500 is more powerfull i think for gigabit fiber ??
The EA8500 is ipq8064 (not ipq807x, nor wifi6) based, which is not fast enough for routing at 1 GBit/s line speed (probably about ~500 MBit/s at best, without sqm, much less with sqm), the OEM firmware depends on NSS offloading to achieve higher throughputs, which isn't available for OpenWrt.
1 Like
The e8450 is a very different device, mt7622b+mt7915e, 2*1.35 GHz cortex a53, it can apparently (based on vague test results provided by one of the developers who added OpenWrt support for it) achieve ~900 MBit/s throughput at ~40% CPU load on one of its two cores - it would be pure guesswork to speculate about sqm performance. That's what I meant with "you'll probably be the first to find out" - proven performance tests are still missing, which isn't surprising, given that support for the e8450 has only been merged two weeks ago and with ipq807x so far not being supported at all.
These wifi6 devices are considerably faster than their wifi5 predecessors, just to keep up with the demands of their new wireless cores, but also to deal with rising wired demands (ftth/ 1 GBit/s), but how fast exactly remains to be seen.
4 Likes
I'll go out on a limb here and say that I don't think ANY off-the-shelf router can handle a single gigabit flow using SQM with layer_cake...and you won't find any that will until gigabit links become the norm and OEMs get forced by market pressure to make some serious high-end, off-the-shelf kit available to consumers.
And even then, such devices are not likely to be a dime-a-dozen and they'll be expensive.
If you're just firewalling and routing, then you can find some kit that will use hardware flow offloading to reduce the CPU load. But as soon as you add SQM to the equation, you can't use hardware flow offloading and so you need a way more powerful device.
As @dlakelan said in the very first post, "you now have a serious bit of computing to do just to route and firewall and SQM your network"
Here's a couple of representative screenshots from htop of a how much of a single core of a 2.2Ghz x86_64 cpu (Intel C3758) is needed to route a gigabit flow.
Configuration: SQM layer_cake and a diffserv4 profile, with shaping enabled on ingress with a 900mbps bandwidth cap.
Single flow without SQM
single flow with SQM
It's hard to believe that a much less capable CPU wouldn't just cap out handling the gigabit flow with SQM and send the latency through the roof....
NOTE: This test is a bit contrived, as I deliberately left Intel's too-clever flow-director feature on the NIC enabled, which leads to all the interrupts for a single flow being processed on a single core, but it makes the point I wanted to make, which is that even a beefy core beyond what's found in most consumer routers struggles with a full gigabit SQM flow, so that 1.3Ghz dual core cpu in router xyz, for example, will.almost certainly choke on it.
3 Likes
ipq8074 is designed to handle two 10 GBit/s interfaces (and 5*1000BASE-T on a switch), plus the needs of 802.11ax - while you won't find (m)any consumer devices actually providing that, quite a few will come with (usually one) Aquantia 2.5GBASE-T or 5GBASE-T ports. Obviously they do rely on NSS offloading to accomplish that, but at 1 GBit/s doing SQM might, just might, be within its performance envelope in software/ netfilter (heat dissipation might be an issue though), so I wouldn't disregard that immediately (4*2.2 GHz ARMv8/ cortex a53). Sadly we won't know for sure, until device support for it enters OpenWrt.
2 Likes
Be interesting to see if it does. That ipq8074 SoC uses an ARM core essentially equivalent to that used in budget to mid-range smartphones from a couple of years back. (eg, the underwhelming Nokia 3.2 from 2019 has a Qualcomm Snapdragon 429 SoC, which is a 1.95GHz 4-core Cortex A53, while the the 2016 Samsung Galaxy A3 has a Exynos 7578 4-core Cortex A53, although clocked at a lower 1.5Ghz)
I think one should always buy a router with little headroom ... since you get symmetric speeds these days with PON , these things like the E8450 are probably good upto 500mbps up/down. Probably double the cores would do it for gigabit but a closed router like that is challenging for heat... But like the pinned post suggests true gigabit is still a hassle. I would buy something like protectili for gigabit (a good investment) which is cheap silent and comes with intel ports.
You probably meant Protectli but yeah, looks promising once they would do an SFP or SFP+ version...
And a little hardware offload 
I think eBPF is far less friendly than nftables and not substantially faster for most things. Once we move to nftables flow offloading comes for free without any special iptables hacks, and also we get a lot of good stuff like sets and maps. Zone based packet filtering is pretty trivial it looks like defining a few variables to hold sets of interface names, and then a few rules along the lines of
iifname $lanzone oifname $wanzone accept
The complexity of the code drops dramatically and far fewer cycles will be needed. This should boost a lot of routers capacity for at least firewalling
2 Likes
I agree that user-friendliness is tantamount, esp in projects like OpenWRT.
But see link 2. eBPF performance vastly exceeds pure nftables. Even Google is in on it:
Granted that BPF is not a panacea - but with its help this project will see performance improvements.
I think the real evolution will be nftables compiling to eBPF.
2 Likes
This topic was automatically closed after 13 days. New replies are no longer allowed.