[Make-wifi-fast] Major Bufferbloat

Jonathan Morton chromatix99 at gmail.com
Mon Mar 27 08:21:42 EDT 2017

> On 27 Mar, 2017, at 14:56, Jaap Buurman <jaapbuurman at gmail.com> wrote:
> Thank you very much for the quick replies! I tried two clients, one laptop with the Intel 7265ac chipset (Just to be clear, these tests were done on 2.4ghz n). And another client with an Artheros chipset. I am not entirely sure which one exactly, I can check in a few hours once I get home. Both clients were showing the same behavior. The Intel chipset was using Windows 8.1, while the Artheros chipset was using Windows 10. As a sidenote, I will try out Ubuntu clients as well once I get home.
> I initially also suspected bloated clients. But both clients showed an A bufferbloat score on an Archer C7 V2 2.4ghz wifi. This was the exact same test as the one in the OP, so with 32 upload streams. Unfortunately, I do not have the Archer anymore, so I cannot repeat the iperf tests.

Both are reasonably powerful routers with good CPUs and decent wifi capabilities. However, I now notice this from the thread you linked:

> As you can see, bufferbloat is fine wired (I am not using SQM, since that crashes my router, even with fq_codel, it's an outstanding issue with Mediatek socs). And WAN speeds are more than enough for my wifi connection.

It’s pretty hard to avoid bufferbloat if you don’t have any bufferbloat mitigation in place.  In the download direction you benefit from the router's mt76 chipset’s support for wifi-stack AQM/fairness (aka the result of the make-wifi-fast project).  In the upload direction you have to rely on whatever Windows does, which (as with many things) is grossly inferior.

Under Linux with a recent enough kernel, the ath9k driver also has the make-wifi-fast code fully enabled.  One of your wireless clients might therefore benefit from that.  Alas, the Intel chipsets have a different architecture which makes a full implementation much more difficult.

It’s important to realise that bufferbloat always occurs at the entry end of the bottleneck link.  Differences in link bandwidth (which are very common with wifi, even with the same hardware, if you simply move around a bit) can easily move that bottleneck from one link to another.  It’s therefore important to have AQM installed on every link that you can, in both directions.

You may want to double-check that your antennas are properly installed and oriented for best performance.  That will tend to improve your wifi link bandwidth, and might shift the bottleneck back to your uplink, which appears to be less bloated in the first place.

 - Jonathan Morton

More information about the Make-wifi-fast mailing list