Lets make wifi fast again!
 help / color / mirror / Atom feed
From: "David P. Reed" <dpreed@deepplum.com>
To: make-wifi-fast@lists.bufferbloat.net
Subject: [Make-wifi-fast] Status of the industry on over buffering at the WiFi air interface
Date: Wed, 12 Feb 2020 19:08:33 -0500 (EST)	[thread overview]
Message-ID: <1581552513.586428831@apps.rackspace.com> (raw)

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...


             reply	other threads:[~2020-02-13  0:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-13  0:08 David P. Reed [this message]
2020-02-13  0:36 ` Bob McMahon
2020-02-13  1:56   ` David P. Reed
2020-02-13  6:27     ` Bob McMahon
     [not found]     ` <mailman.471.1581575247.1241.make-wifi-fast@lists.bufferbloat.net>
2020-02-13 21:32       ` Bob McMahon
2020-02-13 22:23         ` David P. Reed
2020-02-13 22:36           ` Jonathan Morton
2020-02-13 23:49             ` Bob McMahon
2020-02-14 16:40             ` David P. Reed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/make-wifi-fast.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1581552513.586428831@apps.rackspace.com \
    --to=dpreed@deepplum.com \
    --cc=make-wifi-fast@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox