The bufferbloat project is tackling overbloated systems in two ways:
- Removing the bloat everywhere that we can
- Moving bottlenecks to places where we can control the queues, and keep them from getting bloated
sqm-scripts, and now cake, are part of the latter. They work by restricting the bandwidth that flows through an interface (ingress, egress, or both), and then carefully managing the queue so that it doesn't add any (or much) latency.
More details on how cake works can be read HERE.
Cake was meant to perform well on lower-end CPUs like those in home routers. So the test results that follow are all on a Netgear WNDR3800. This was a fairly high-end router, 5 years ago when it was new. Now, it's dual 802.11n radios are falling behind the times, and it's 680MHz MIPS CPU is distinctly slow compared to the >1GHz multi-core ARM CPUs that are currently in many home routers.
All the tests that follow were taken using the same piece of hardware.
I'm starting with the final results, and then we'll compare the various revisions of settings and software that led to this.
100s of ms of latency
~135 Mbps download speed
no additional latency vs idle conditions
What's really impressive is how smooth the incoming streams are. They really are doing well. Upstream is also pretty good (although not great, this is the edge of what the CPU can manage). But what's simply amazing is the latency graph. It doesn't change between an idle or fully-in-use connection.
And the CDF plot really shows that. There's no step between the idle and loaded operation, just a near-vertical line around the link latency (which is almost entirely between the modem and the head-end).