Cake is almost ready
-
There have been some takers on the call for testing. There's a been a lot of renewed discussions and testing. There is also a bit of minor polishing, but parameter names, accepted ranges, but the core of Cake seems to be very stable.
-
To be clear, no work is being done to bring cake to pfSense/FreeBSD. Cake is Linux-only for the foreseeable future.
-
Yeah.. we don't even have fq_codel yet.
-
So if we want to run Cake then we will have to build a different Linux server? FML. Not having followed Cake and it's development - what is the best flavor to do this with?
-
I'd bet IPFire will be among the first x86 firewall distros to offer it.
-
If it's Linux-only without any roadmap for a *BSD port, why are we even talking about this? Is the source available? Is it a simple matter of swapping out headers, library refs & API and recompile for *BSD?
-
@KOM:
If it's Linux-only without any roadmap for a *BSD port, why are we even talking about this? Is the source available? Is it a simple matter of swapping out headers, library refs & API and recompile for *BSD?
cake is the evolution of codel/fq_codel, something we have talked about quite a bit around here, so it is a somewhat pertinent topic. Yeah, cake probably belongs in the General sub-forum, not here.
The source-code is available, but cake is deeply entrenched in Linux-only features. I highly doubt we will ever see it.
We will be getting fq_codel but it will be via limiters (dummynet), and I have no clue whether that means we can properly make use of fq_codel's abilities or not. We primarily use ALTQ for traffic-shaping.
-
Thanks for the deets. I'd rather they spent the time making the shaper interface less inscrutable than it currently is than adding more shaping algorithms. I suspect that there are only about 10 people in the entire forum that effectively understand the traffic shaper. I've spent hours reading up on it, experimenting and asking questions, and I still don't have the confidence in my knowledge that I should. It's getting to the point where good QoS is not just an enterprise-level feature. With every home having multiple users with multiple devices, managing bandwidth and contention is very important. There has yet to be a Hangout that covers the shaper in-depth, and the interface makes most users scratch their heads.
-
It is very disappointing that cake most likely will not be making it's was to PfSense. I have loved PfSense ever since I started running it and ipfire looks like junk to me.
-
It is very disappointing that cake most likely will not be making it's was to PfSense. I have loved PfSense ever since I started running it and ipfire looks like junk to me.
Cake is not really meant for power users with complex traffiic shaping needs.
pfSense will be getting fq_codel via it's inclusion in the "limiters" (FreeBSD dummynet) feature. I am unsure how useful it will actually be for us, but it should be 99% as effective as cake.
-
Cake isn't useful for shaping bandwidth. Think of it as an advanced fair queue that evenly distributes bandwidth and advanced flow isolation. It's a near-zero configuration QoS that will make sure high bandwidth applications won't starve your low bandwidth latency/jitter/loss sensitive flows. Cake does have a few things an ISP would like to have. By default, Cake hashes on dstIP+Port, but can be configured to instead hash on srcIP or dstIP. This would allow an ISP to isolate customers from each other and evenly distribute bandwidth among all customers in a stateless way. Stateless is important for scaling reasons. Limiters are great until you have tens or hundreds of thousands of IPs. A new limiter per IP isn't going to work well.
fq_codel does not has perfect flow isolation. It is susceptible to the "birthday attack" issue. If you have sqrt(hash) of flows, you have a 50% chance that one of the hash buckets contain 2 or more flows. Even at 1024 buckets, fq_codel has a 50% chance that there is a collision. Cake uses "ways" to deal with this. Think cache associativity. Cake can handle up to 8 flows in the same bucket before a true collision occurs. This does not happen in the real world. At even 100,000 TCP flows on a 100Mb link, you still don't get collisions. With even 10,000,000,000 buckets, fq_codel would still have a 50% chance of collision with 100,000 flows, while cake has no collisions and only 256 buckets.
Many of cake's ideas could be backported to fq_codel. I think that would be awesome, because I like HFSC.
As a shaper, one important thing that cake does for low speed connections is it calculates in link layer overheads as part of its packet scheduling. This is important for connections like DSL where cell-framing + PPPOE + Ethernet can bloat up a packet's true size quite a bit relative to a 1Mb slow speed.
-
Any news about cake?
-
yeah I would love cake as well, but sadly I cannot see any information on it been ported to dummynet, it looks like nothing is happening for that. :(
