How OpenWrt Vanquishes Bufferbloat

Let's face it, the only relevant wifi chipsets in 2024 are:

  • mt76
  • ath11k
  • with some caveats (as in 'only' 802.11ac) ath10k
    (there's little bad to say here, but you're not going to buy new devices for it, even less if you are keen perfect performance)

Even if they had perfect bufferbloat support, 802.11g (ath5k, ar5523), 802.11n (ath9k/ ath9k_htc/ carl9270, rt2x00) really don't have any place in terms of decent performance anymore. Bufferbloat may be an important aspect, but so is basic throughput as well - and with that in mind, anything below 802.11ac doesn't meet the bar (and yes, I do still own everything from 802.11b and upwards, for a simple client with modest needs that may be fine, for your main AP and an expectation of smooth performance, no, not at all).

mwlwifi/ brcmfmac are each plagued by their own issues, and -as fullmac devices- won't ever give you driver side abilities to tune bufferbloat, the binary firmware is what it is.

The various Realtek chipsets have barely any support in OpenWrt at all. While rtw88/ rtw89 is getting vendor support for modern chipsets and rtl8xxxu quite some community support for older chipsets, I doubt anyone has tested it on OpenWrt (with AP mode) in anger at all.

Forget about brcmsmac, Broadcom just threw that stuff over the fence to kill off b43 and immediately forgot about it, it doesn't support AP mode at all.

We don't have any ath12k devices so far either, it will become relevant with ipq957x and ipq53xx some time in the future, but expect a double digit amount of months (my guess would be at least two years, celebrations if it's only going to be one year, but I wouldn't wonder if it's going to be 3+ years).

6 Likes