Earlier this year, I discovered ‘wondershaper‘ a great Linux tool that configures traffic shaping on my notebook to fight buffer bloat on an upstream router. Without it, video calls and other interactive Internet use become impossible to use on some connections when sending large amounts of data in the uplink direction. This works on a device basis, so several devices in the local network, all sending data to the Internet at the same time, can still cause buffers to bloat in unsophisticated access routers. The solution: Apply traffic shaping on a local Wi-Fi access point that is inserted before the router where the bloat happens. It turned out that configuring traffic shaping on OpenWrt is a piece of cake!
When trying out Wireguard on my OpenWrt enabled Linksys WRT-1200ac router recently, I also took the next step and installed OpenWrt’s traffic shaping package “Smart Queue Management” (SQM). Once installed, a new menu item appears in the GUI. Here, Download and upload speeds can be conveniently configured for any interface. Once configured slightly below the backhaul line rate, buffer bloat immediately stopps.
The first image below shows round trip delay times in excess of 400 ms when the uplink was fully saturated. Interactive video calls and even web browsing become pretty much unusable:
After activating traffic shaping with an uplink speed value just below the line rate, round trip delays returned to a usable 70-80 ms. It’s still a bit high but that was caused by using an LTE backhaul together with a Wireguard VPN tunnel to a destination 1000+ km away.
An impressive difference!
One thought on “Fighting Buffer Bloat With OpenWrt and Traffic Shaping”
If you are using wireguard extensively or exclusively as a site to site vpn you will find using fq_codel to manage the traffic mildly better than cake, as it preserves the hash from the tunneled flow to the tunnel.
cake however is really good in multiple other ways (and we keep meaning to add this fq_codel feature to it). Glad you dig it. Fix it for a friend (or three)
(one of the authors)
Comments are closed.