So you have 500Mbps-1Gbps fiber and need a router READ THIS FIRST

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...

BPF. BPF. BPF. :wink: And a little hardware offload :slight_smile:

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.