Real life utility of SoC speed and RAM size in routers

[sfx2000]

We used RISC in our old network Sun machines way back. Intel finally did them in. It is a way to get high clock, but you pay for it in the reduced instruction set.

RISC-V is a newer architecture - key benefit for RISC-V is that it's fairly permissive, e.g. open source as much as hardware can be.

RISC-V - Wikipedia

en.wikipedia.org

RISC-V is starting to become a big thing with ARM being a bit difficult recently with architecture licensees - most of the really cool stuff for RISC-V is coming out the the PRC because of the IP limits being imposed due to political sanctions.

 

[sfx2000]

I'd say that RISC-V isn't quite there today, but give it a year or two. I would say Realtek might be the first to try this, as they've always been about cost and Arm cores are costly in terms of licensing.

Yeah, but they're getting there - some of the moves are odd, like Vector Extensions in lieu of SIMD, but it's a growing thing...

Milk-V

Milk-V Pioneer is a developer motherboard based on SOPHON SG2042 in a standard mATX form factor. With PC-like interfaces and PC industrial compability, Pioneer provides native RISC-V development environment and RISC-V desktop experience. It is the first choice for RISC-V developers and hardware...

milkv.io

This one is kinda interesting, but a bit of a challenge to actually acquire here in the US - Mouser is a licensed distributor, but good luck actually getting one - if one knows folks over in Shenzen, it would be easier to get there, and ship to the US...

For SBC's - the Milk-V Mars board is a good starting point...

Milk-V

Milk-V Mars is a high-performance RISC-V Single Board Computer (SBC) the size of a credit card, built on the StarFive JH7110. This four-core device supports a plug-and-play eMMC module, as well as up to 8GB of LPDDR4 memory. The board is equipped with three USB 3.0 ports, one USB 2.0 port, an...

milkv.io

Qualcomm is on board with RISC-V as well - might be IP blocks inside an ARM-based SoC, but sooner or later...

 

[sfx2000]

It does matter though, at least when you step away from that "basic" router you mention, which most users here do. Once you want to do VPN or storage or anything outside of just routing data, the CPU core(s) really matter.

QCA IPQ6000, which is on the low end, can do 120 Mbit/Sec on openVPN, and 500Mbit/sec on WG

MediaTek on Filogic 830 is a mid-high tier target - 190 Mbit/Sec and 900 Mbit/sec on WG

Since this forum is Asus centric - one can consider the RT-AX59U & TUF AX4200 devices are supported now on OpenWRT master...

Having done a dive into the thing that is AsusWRT - this SoC could be supported by @RMerlin and/or @GNUton as most of AsusWRT is middle-ware...

AsusWRT is actually not Broadcom specific - they abstract much of the underlying BSP from the user facing WebUI, but they're good at adapting, which is why we see support for SoC's across the board.

Yes, that is a backhanded compliment to Asus as they do sort things well enough on their AIMesh platform...

 

[sfx2000]

QCA IPQ6000, which is on the low end, can do 120 Mbit/Sec on openVPN, and 500Mbit/sec on WG

MediaTek on Filogic 830 is a mid-high tier target - 190 Mbit/Sec and 900 Mbit/sec on WG

Thought about this - and perhaps this is due to WG living in L2 cache (code is that small) and it's all in kernel space - Fillogic runs clocks 2x the speed of IPQ6000 - the OpenVPN, well that's a known issue with ovpn architecture...

 

[Easy Rhino]

i'm not smart enough to follow the recent discussion, but for the original question, the only thing that really put a "load' on my routers was something that juggled lots and lots of tiny connections. Think bittorrent. and also to lesser extent video game downloads like from Steam. Doing those at a high (gigabit) rate could max out the CPU on my old netgear, and maybe on my current box (a mini pc running opnsense).

Trying to get fancy and turning on traffix shaping/Qos or packet inspection could also slow things down, but I never kept running those at home.

But regular usage where I just need to connect to the office and the family streams video? Things have been "fine" for years and years.

 

[coxhaus]

In Linux software only - yes, clocks and cores matter as well, but not as much as it does with BSD, and much of this is architecture of the network stack - don't get me wrong, as BSD's pf is great, but Netfilter under Linux has been under very heavy development, and there's been a lot of optimization there - there's also more support for HW acceleration, and we have the Fast Path in SW for NAT that BSD doesn't have.

Fast Path does not mean anything to me as it is too easy to defeat.

 

[Crimliar]

Think bittorrent. and also to lesser extent video game downloads like from Steam. Doing those at a high (gigabit) rate could max out the CPU on my old netgear, and maybe on my current box (a mini pc running opnsense).

Trying to get fancy and turning on traffix shaping/Qos or packet inspection could also slow things down, but I never kept running those at home.

But regular usage where I just need to connect to the office and the family streams video? Things have been "fine" for years and years.

I would honestly have thought that any sensibly specced low end mini-PC from the last 4 or 5 years would be powerful enough not to cope with a Gigabit broadband connection. My NanoPC-T6 8 core ARM based SBC running FriendlyWRT is more than powerful enough to keep up with my own 1Gb broadband - though its 2x2.5Gbps ethernet ports are not equal. Running as a router the GT-AX6000 eats 11W on average, but the NanoPC-T6 needs 19W in that configuration, and I'd trust the router to be more secure than the SBC - not overly impressed by FriendlyElec's firmware at times though it's running very smoothy at the moment.

 

[sfx2000]

Fast Path does not mean anything to me as it is too easy to defeat.

Not sure what your statement means... there is nothing to "defeat"

FastPath has nothing to do with security, and FastPath is a linux thing in any event - it's all in the netfilter code...

In the BSD world - NAT is the limit - every path needs a clock tick, so a 1GBe connection needs a 2GHz processor at a minimum, and every packet needs to go thru the stack.

Linux and netfilter - the fast path in SW makes a direct flow from interface to interface, so the kernel doesn't have to do packet routing directly.

Much like the HW solutions like ctf/netrunner/nss/ppe - depends on the vendor, but it's pretty much the same...

The shortcomings with Linux FastPath are basically the same as the HW solutions - QoS becomes a problem.

 

[sfx2000]

My NanoPC-T6 8 core ARM based SBC running FriendlyWRT is more than powerful enough to keep up with my own 1Gb broadband - though its 2x2.5Gbps ethernet ports are not equal. Running as a router the GT-AX6000 eats 11W on average, but the NanoPC-T6 needs 19W in that configuration, and I'd trust the router to be more secure than the SBC - not overly impressed by FriendlyElec's firmware at times though it's running very smoothy at the moment.

Well - you should explore what's happening on that board/chipset over in OpenWRT master - interesting things...

I've been more focused recently on the MediaTek and Qualcomm 11ax chipsets - which also perform quite well, and are a bit more focused on communications rather than Apps...

 

[Crimliar]

Well - you should explore what's happening on that board/chipset over in OpenWRT master - interesting things...

Personally, it was something of an experiment. It's capable of being used that way so I had it running off an SD card not of the EMMC (or SSD). At a future point I'm more likely to head towards a more serious device for the router than down the homebrew route.

 

[tiddlywink]

..

 

[Crimliar]

Yup, the RK3588 SoCs such as the NanoPC-T6 from FriendlyElec are marketed in part as being a router replacement using their own FriendlyWRT. But I had my board for roughly 8 months before FriendlyElec managed to create a stable (at the point of install) Ubuntu image, so I'm a little edgy about fully trusting FriendlyWRT. It's why at least until recently I've not recommended this SBC as an introduction to the format - the Raspberry Pi being a far better introduction!
I should have taken screenshots of how the NanoPC-T6 performed when set up as a router. In its normal use as a mini-server, backup device, and cloud game streamer it currently pulls 5-7W (more than on earlier firmware which used to be about 4W). Running as a router, it pulls an average of about 19W - for the record the Asus GT-AX6000 averages at 11W but I've seen peak at 17W.
Then comes the usage scenario! I don't have the luxury of being able to play with the router settings or set up for hours on end when there are others in the house. I have an M2 2x2 AX card that I could use in the device but it means building the drivers and it didn't get particularly good coverage when I've tested it - So it actually has an AC card that's supported by default, just for the Bluetooth. This means I'd probably have to use an AP with the device, along with my 2.5Gbps switch. That's a whole load of niggles, just to do what my existing router can already do pretty much flawlessly.
*I've recently received an automatic refund for the SH1008 2.5Gbps switch as apparently it's an early model and they don't work properly, despite my not being aware of mine ever doing anything odd - note that the only Intel dased device plugged into it is a NAS with 1Gbps network ports.

 

[tiddlywink]

..

 

[sfx2000]

Flint 2 (GL-MT6000) (if you care about security, you need to replace the CCP controlled uboot)

First I've heard of this - care to elaborate?

 

[tiddlywink]

..

 

[sfx2000]

Should be easy to replace, but I've yet to see anyone ever comment that they did such a thing. Most leave the OEM uboot alone so they can easily go back to OEM firmware.

OpenWRT has their uboot internal development, so if one replaces the factory uboot image, it's kind of a one-way street... but this isn't unique to GL-Inet, but many supported devices can have similar concerns - e.g. the RT3200 from Belkin, which is/was fairly popular, had a very different NAND/filesystem setup from stock to OpenWRT, and this has caused problems over time.

GL-Inet's factory uboot image works fine with OpenWRT, and if kept in place for the moment (this could always change), one can move back and forth...

At the moment, I would not swap the bootloader, it's not a requirement.

One does have to do a full reset if moving from one to another, as settings and capabilites are kept in different places - and some of those can clash - gl-inet tends to keep a lot of their configs in their own /etc/config files compared to openwrt stock locations.

 

[sfx2000]

"Established in 2014, our company is headquartered in Hong Kong"

Last time I checked, Hong Kong is still a special admin region, so more latitude there compared to perhaps someone based in Shenzhen, Guangzhou, etc...

 

[tiddlywink]

..

 

[tiddlywink]

..

 

[sfx2000]

If you care about security, you should be replacing the Chinese uboot.

there is no routable network stack support in the uboot - it's pepe4k mods only, and this is well known and documented.

Besides, once the kernel has booted, uboot exits the scene.

Not sure what your concern is from a technical basis here, and why so focused on uboot - perhaps a lack of knowledge?