Bufferbloat only with WiFi

On my 1Gbps fiber connection, OpenWRT behave quite well, no buffer bloat with wired connection even without sqm enabled.

The WiFi interface, on the other hand, suffered from buffer bloat quite badly. So I applied cake only to the WiFi interface.

Is it the right way to handle the buffer bloat issue? My intention is to take advantage of cake as much as possible, by applying it to the most needed interface, and leave the others be it to save as much cpu as possible.

How did it work for you?

Bufferbloat occurs in WiFi because it's the slow link in the chain. Your theory is fine, except WiFi is a weird medium... I'm not sure how well cake works in that context. Please let us know what kind of results you got. Thanks.

The throughput dropped a little bit after applying cake, while the buffer bloat gone.

Before applying cake, the throughputs are about 40Mbps for both up and down, while after cake, it dropped to 33.6Mbps and 36.8Mbps respectively.

However, if the WiFi is sharing between 2 devices, one of them might have taken all the bandwidth. I know cake might not designed for it, but how can I set to handle bandwidth sharing issue?

"might"???
fq(and hence fq_codel and hence cake) aims to solve exactly this sharing case.
if one device did get all the bandwidth, there might be a problem. so, did it, or did it not?

otherwise your result looks good

The cake are set to the WLAN interface specifically created for the 2.4G WiFi, that make me wonder if I have to create another WLAN interface for the 5G WiFi, in order to apply cake as it does with 2.4G.

if your wan bandwitdh is greater than the combined speed of your wifi's, you can get away with running shaper on the two wifis separately.
if not, you would need a third instance on your wan interface.

How do I suppose to set the bandwidth limits if in my case the wan bandwidth do bigger than WiFis combined speed.

For the cake didn’t handle bandwidth sharing well, is it possible that the other guy’s packets been offloaded, cause it is reported that software offloading not compatible with SQM?

The difficulty with queue management is that often the queues form in a place where they cannot be directly observed (DSL modem, cable modem, wireless driver). For cake to be effective, it needs to move the queue from the "black box" device to itself. On fixed links, this is achieved with a suitable bandwidth limit in cake.

Since WiFi bandwidth is variable, especially for mobile clients, it's difficult to find a limit that works well under all conditions and does not waste link capacity.

Queue management for WiFi works best when it is integrated into the wireless driver, where the queues can be observed directly and no shaper is needed. This is one of the objectives of the Make Wi-Fi Fast Project. Another objective is "Airtime Fairness", which fixes the issue where a WiFi device on a slow link reduces throughput also for devices closer to the access point.

Take a look at the academic paper by @tohojo: Ending the Anomaly: Achieving Low Latency and Airtime Fairness in Wifi. Even if you aren't interested in the implementation details, it's worth looking at the diagrams showing the improvements.

The results of the Make Wi-Fi Fast Project are available in the ath9k and mt76 wireless drivers, and partial results exist for ath10k. To benefit from this work, you need to get WiFi hardware supported by these drivers.

3 Likes