I am weirdly pleased so many care about cake + the openwrt one. I would like (us) to make a concerted effort to make it scale better to this multicore. I have been thinking about ressurrecting IMQ in particular.
"Eero appears to have beaten them in their Wifi6 product."
Trust me they haven't. SQM on Eero wifi 6 products is a complete mess.
One thing while I have you here. I've always been puzzled about this. All these SQM algorithms seem to hate software based bandwidth limiters. There's something about the way they limit bandwidth that completely bamboozles the likes of cake and to some extent fq_codel. You'll get ridiculous jitter spikes. Maybe it's something to consider for CakeMQ on how to handle it. A whole network can be grinded to a halt if someone decides to limit bandwidth. Quite annoying.
I see this document was posted around August so you weren't to know but some later supported OpenWRT routers can now easily do Cake at over 2 Gbps. Most notably the MediaTek MT7986. The 500Mbit scaling problem mentioned isn't much of a problem going forward unless people want to stick to non wifi 6 devices for years... so maybe it is still worth looking into.
I understand why such a barebones device was selected for 2024 - as this device will be used in many counties where $100 is considered very expensive for a home or small business firewall, and where current internet access speeds are in dozens or hundreds of Mbps and not even close to 1 Gbps. Such a Low-end device needs to exist in 2024 for those setups.
However, I would like to propose that another - more powerful - device be also released as a standard OpenWRT hardware offering. Here’s my suggestion:
Interfaces: three interfaces (2x 2.5 Gbps) + 1 1 Gbps.
Storage: 16 GB MMC
RAM: 4 GB
Wi-Fi: none (use a dedicated AP or a number of dedicated APs).
Updates: easy updates with a one-button push with the standard set of packages (extensive set due to the higher storage and RAM capacities) having their setting survive the update.
This is why I think that the hardware platform that you guys selected is barebones and insufficient in specs for 2024 for more complex deployment scenarios.
Inter-VLAN routing done by OpenWRT. This is definitely a must for a hardware platform in 2024 to provide firewall-protected inter-VLAN routing. Therefore, the LAN interface must be at least 2.5 GBPs to account for a moderate amount of inter-VLAN-routed traffic in a Gigabit network. Some of this traffic would be inter-VLAN routed and some would be internet-bound. So, with the platform you chose, your Internet-facing port must be 1 Gbps, which is fine for maybe 95% of the world today but this is not forward looking whatsoever. There needs to be another more powerful official OpenWRT hardware platform that can take Internet connectivity above 1 GBPs. Personally, I think a more powerful platform should have two 2.5 Gbps interfaces for the dual Internet connectivity and a 5 GBPs interface facing the LAN switch for Inter-VLAN routing plus Internet-bound traffic. But, if this is too expensive or not yet available from the hardware perspective, the minimum that this more advanced hardware platform should have is two 2.5 Gbps interfaces (one for the primary WAN and one for the LAN) and one 1 Gbps interface for the secondary WAN).
There is no need to have a Wi-Fi chip in this more advanced official OpenWRT hardware platform because it would be used in larger residences or small business settings where dedicated APs are required to provide proper Wi-Fi coverage. It would suggest not including a Wi-Fi feature into this platform at all.
4 GB or RAM and 8 GB of storage is required to run additional official packages without negatively affecting the routing performance.
My dream device is so different from most. For the global south, cost is paramount, and driving down the cost of fiber (PON). There is an excellent Huwai device I have seen that is wireless-n, fq_codeled, all over Nicaragua, that convinced me that LibreQos was not needed there - but in Columbia. Next up is reliability and longevity - but neither of those are my priorities for my dream device.
I would love to see a quad-core A53 derivative with 64MB of onboard RAM, heck pure SRAM + no cache, or failing that, an increase in size of the icache and dcache, and while I am dreaming, an entirely separate memory area for dcache and icache in interrupt mode... Anything that can make an inorder processor fly, and behave predictably.
A single chip, 4 antenna wireless-n router. wifi started getting even crazier stupid ideas in it after that. An arm amulet successor with such low self noise as to eek another few db from the wireless signals, and fit in your watch.
Coupled power and rate control to lower power also...
... even smaller but far more capable than the rather lame esp32 chips.
Anyway... back to reality. (one big reason I am so enthused about the one project is OH! a Raspi with GOOD wifi!! Who'd have thunk it)
To use any internet service faster than 1 gigabit you need a 2.5 gigabit WAN port and at least one 2.5 gig LAN port. If I need more than one LAN port, I can add a switch. If the hardware only supports 1 gigabit on LAN (or WAN) then I have to replace the whole router.
Also, you need at least three ethernet ports to run dual WAN.
The GL-MT6000 has two 2.5 gig and four one gig ports for $160 on Amazon.
An M2 slot that would take a WIFI card would allow you to add 6GHz support.
I've had some time to read about this here and i'm thinking that this is pointless since we have alot of whole kind devices and we don't need another electro garbadge of which maybe fifteen enthusiast will have some fun for a few weeks and later it will land in garbadge bin. Better to focus on maintence this unwanted part of code to workaround some things that noone want to rewrite new.
I had tested a 100 and 10Mbit PON device, and it was clearly fq_codeled. I had also heard that Nicaragua "had good wifi" compared to "country X, Y, Z". My bufferbloat journey started there - and we tested fq_codel and cake extensively in SJDS - so i hope the national provider had figured this out! (I tested 3 different locations with very good results, at 10 or 100mbit). The WiFi on two of them was clearly NOT fq_codeled, tho.
So far, you've been the only one that's mentioned this concern in the forums. Haven't read it anywhere else. On the One announcement, OpenWRT mentioned they wouldn't be the ones manufacturing nor distributing the hardware. Maybe some OpenWRT devs will place a tad extra attention to making sure OpenWRT plays nice with their hardware, and some of their time will go into keeping the hardware up-to-date in subsequent iterations, but apart that, I don't see any downsides from the One announcement itself.
Is there a risk in general that an open source software splits and becomes a paid service... sure, but that's just a risk for any project really, even paid services split and to become another paid service. But so far there doesn't seem to be any movement from the developers/community to do so... but please feel free to post any evidence of the contrary. Anything else is just pure speculation.
Here's another speculation which I think has a little more evidence---20 years from now OpenWrt will celebrate their 20th anniversary of producing an open source hardware, and their 40th anniversary of OpenWrt, still with an active community.