[Make-wifi-fast] Status of the industry on over buffering at the WiFi air interface

Bob McMahon bob.mcmahon at broadcom.com
Wed Feb 12 19:36:44 EST 2020

hmm, not sure if this helps but "excess queueing" can be hard to define.

Do you know the operating systems for the WiFi devices and if tooling can
be loaded upon them?  iperf clients samples RTT and CWND for linux
machines. Iperf 2.0.14 (in development) has a lot of latency related

Also, if there is control over the AIFS one can set that for the high rates
devices such that they always win and the lower rate ones always lose.  If
that solves things it does suggest WiFi tx queues developing per the TXOP
arbitration and air transmission as an issue.  Standard cwmin/cwmax isn't
as effective though it won't allow high rates to starve low rates devices
as AIFS might (depending upon the values)

I use latency to measure the performance and define bounds that way and
it's very specific to use cases.  IT does require clock sync. My devices
have GPS disciplined oscillators which aren't common.

As an aside, the HULL approach of phantom queues looks interesting.


On Wed, Feb 12, 2020 at 4:08 PM David P. Reed <dpreed at deepplum.com> wrote:

> A friend of mine (not a network expert, but a gadget freak), has been
> deploying wireless security cameras at his home and vacation home. He uses
> a single WiFi AP in each place, serving the security cameras etc.
> What he observes is this:
> Whenever anyone on a laptop in one of the homes uploads a modest sized
> file (over the same WiFi) the security systems all lose data.
> Now I can't go to his home to diagnose this, but I've asked him to check
> out his cable bufferbloat using dslreports, and he gets no bufferbloat
> there. But it sure looks like *severe* lag under load is affecting the
> security camera feed to the cloud servers that the company that sells the
> security cameras provides.
> So, is there a way to simply *diagnose* the WiFi air link for excess
> queueing in all the high rate WiFi devices? Something a non-net-head could
> do?
> The situation around congestion control in the industry continues to
> royally suck, in my opinion. The vendors don't care, the ISPs don't care
> (they can sell a higher speed connection than is actually needed and
> super-fabulous MIMO gadgets that still don't quite solve the problem).
> I'm an old guy, basically retired. I'm sad because the young folks remain
> clueless.
> And it's been decades since bufferbloat was discuvered, and the basic
> issue of congestion signalling being needed. I'm sure 5G (whatever it
> really is) is not paying attention to this network level congestion issue...
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/make-wifi-fast/attachments/20200212/c5a86da0/attachment.html>

More information about the Make-wifi-fast mailing list