OpenWrt scalability Pi4->Mini PC

So, people complain that micro SD cards fail a lot so if you are going to buy one, industrial grade cards just hit Amazon (they were, previously only niche products made by companies I've never heard of); I'd get one of those.

They are not large but you don't need large.

1 Like

Or just those designed for surveillance recording, and use SquashFS then you'll be safe.

Well, the industrial grade is supposed to be more robust with better write leveling and overprovisioning. I.E. they have more storage than advertised and can and lie about their partitions.

Please don't ask me how, but is goes back to why you should, really, never fdisk/partition an sd card to fill all memory.

Is partitioning 3/4 of available space the same as over provisioning?

No.

Overprovisioning is done at the controller level. Some SSD software will let you set the amount of it but not in this case.

You can expand the file system to the size it reports and its overprovision allotment is invisible to you. Formatting unallocated space is different than wiping the whole thing clean and forcing a new map.

:spiral_notepad: If you want to read about how it works, click the link.

1 Like

The OpenWrt for R4S is 8gb.

Is there any reason to use a much bigger SD w OpenWrt?..... extra module storage?

Are you running Docker style containers under OpenWrt? Are add-on modules container style?

Seems wrong.

I'm not failure with the R4S. Where did you get that size?

Seems I was wrong.... Explorer shows zipped size as 8,641 Kb.
I was thinking Mb, not Kb.
Unzipped its 168Mb.

BTW, 7zip had unzip errors. W11 bundled/integrated zip unzipped fine....

So if one writes image to SD, thats tiny use of multi-Gig SD.
Lots of space for modules then....

I read your page while I waited; you should too.
It mentions it is zipped.

It doesn't look right, mine is very small in size, I never unzip it, simply using Balen Etcher, or Windows you can use Raspberry Pi Imager to flash it to SD card, it will handle it.

I have found openwrt and ddwrt do not have full duplex performance on the WAN interface. Decide if that is acceptable for your use case.

A router running openwrt & wireguard is a pretty useful combination when full duplex WAN performance is less important than the wireguard VPN connectivity.

This statement, as provided in general, is incorrect.

As long as you have one dedicated Ethernet card as wan and one+ dedicated Ethernet card as lan, you will get full-duplex routing at wirespeed using OpenWrt, provided your router is fast enough to service that (e.g. x86_64, RPi4+, NanoPi r2s+, …).

If you configured a one-armed router/ router on a stick, only using a single ethernet card and a managed switch to disentangle that, those would be your hardware constraints - as would be expecting too much from slow hardware.

OpenWrt can do it, full-duplex - on decent hardware (e.g. x86_64).

4 Likes

Citation or testing procedures with device information please.

3 Likes

Connect WAN interface to your local LAN; connect one test computer to the same local LAN. Connect another test computer to the test router's LAN. Run bidirectional iperf between the two test computers. As a control, test computers directly w/o router in between, i.e. same switch, crossover, or auto-MDIX.

In my tests (ranging from WRT54G to Nighthawk X6 and various others in between), stock ROM gets full-duplex performance; custom ROMs only half-duplex. If you need full duplex performance, e.g. on a switched GigE upilnk, stick with the stock ROM. Good luck with your testing.

This statement, as provided in general, is incorrect.

Run your own tests

OpenWrt can do it, full-duplex - on decent hardware (e.g. x86_64).

"This statement, as provided in general, is incorrect."

Someone already did that with their Raspberry Pi 4B, it's not about OS being incapable, mostly problem coming from "not configuring properly".

Some router hardware do have proprietary hardware acceleration which makes some difference between stock/OpenWrt (since OpenWrt has to stick with open source implementation), but for those with open source driver, it's the same, however stock firmware might already preset everything vendor believe it's good for performance (CPU scheduling, IRQ balance, etc....) but on OpenWrt you have to do it yourself.

And most home router stock firmware nowadays are just vendor modified OpenWrt as their OS (most of the time it's even older version), plus the driver I mentioned before, if there is no closed source implementation, I don't see any reason why using vanilla OpenWrt will cause performance impact on the same piece of hardware.

To add to what @fakemanhk said here, a MT7621 maintainer on upstream Linux was able to achieve full-duplex 1 Gbps on many MT7621-based devices simply by changing how the WAN port was connected to the CPU:

This involved no change to the Linux kernel or any OpenWrt code. All that was needed was updating the device trees of the relevant devices. (Device trees aren't specific to OpenWrt by the way, they're a common sight in embedded Linux deployments.)

1 Like

"not configuring properly" ...

not configuring properly by whom? Stock ROM gets full duplex performance w/o any mods.

And most home router stock firmware nowadays are just vendor modified OpenWrt as their OS

and they configure it properly to get full duplex performance...

I don't see any reason why using vanilla OpenWrt will cause performance impact on the same piece of hardware.

"not configuring properly"... I had to run the iperf tests myself to validate the performance... how many custom ROM users mistakenly believe they are getting full duplex performance? For a cable modem connection, maybe full duplex isn't important.

a MT7621 maintainer on upstream Linux was able to achieve full-duplex 1 Gbps on many MT7621-based devices simply by changing how the WAN port was connected to the CPU

Stock ROM has settings already done by manufacturer, it's not mods. OpenWrt is not a commercial product, the dev team produced a more generic software packages for users to DIY.

"mistakenly believe"? As shown before, other than the hardware with proprietary driver implementations, stock OpenWrt can do the same, or sometimes even better (because some routers vendors almost never update and still using old driver), you can say that general users without much knowledge might not be benefited from using vanilla OpenWrt since they don't know how to tune a device, that's true, but it's not the fault of OpenWrt.

And here, we are talking about vanilla OpenWrt can do the full duplex performance or not, you want examples, there are examples showing OpenWrt can do the job already by some fine tuning. Vanilla OpenWrt is a piece of software package for people to tinker with, they can make adjustments freely.

1 Like

Just to chip in my two cents; i've been running opnsense as my main router for many years now. It never goes down, is rocksolid and i never had any issues updating it. For me as a non power user it is easier to configure and maintain then openwrt. Firewall rules are easy to create and alter as do nat entries. To give me the same functionality in openwrt probably gives me a good headache.

Also, opnsense has a nice installer which supports uefi. No need for nasty partition resizing and image writing, just start the installer and your golden. It even runs on a serial console without having to make heavy alterations to the system.

For me openwrt is a good choice for my accesspoints , allthough i regret it not supporting the nss cores on ipq8064 by default. For that to work, i have to run a modifed custom build , which i dont want. I also wonder it if the "opensource format" of openwrt isnt too strict, since there is already closed source firmware in some builds, for example the candelatech firmware in ath9k-ct. I would love a ipq8064 standard build with nss cores enabled by default. But i guess im going a bit offtopic now.

1 Like