Background
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.
The WNDR3800
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.
Final Results
I'm starting with the final results, and then we'll compare the various revisions of settings and software that led to this.
180Mbps download
12Mbps upload
100s of ms of latency
~135 Mbps download speed
12Mbps upload
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).
