From: Dave Taht <dave.taht@gmail.com>
To: Juliusz Chroboczek <jch@irif.fr>
Cc: babel-users@lists.alioth.debian.org,
Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>
Subject: Re: [Make-wifi-fast] [Babel-users] reducing delays in wifi mcast queues
Date: Tue, 18 Sep 2018 16:31:29 -0700 [thread overview]
Message-ID: <CAA93jw6oiCXgvmsdzhUmhtHy_fq5pKCQE4HE0-9BBthCGrS-Vw@mail.gmail.com> (raw)
In-Reply-To: <87efdqcs28.wl-jch@irif.fr>
welcome back!
On Tue, Sep 18, 2018 at 4:19 PM Juliusz Chroboczek <jch@irif.fr> wrote:
>
> > (I ran across this babelweb pic from my old c.h.i.p + rtod experience,
> > which cracked 16sec of delay in the mcast queue:
>
> Bufferbloat in the driver queues?
In that case yes, the driver had an infinitely long mcast queue. Once
the number of routes
cracked a certain point, updates across the 1mbit "bus" hit RFC970.
One answer of course
is to fix the driver (which I never got around to), another is to
think about some sort of
delay based rate control, and to ensure hello packets get out on
reasonable intervals.
...
Now that bufferbloat is fixed in several wifi cards (ath9k, ath10k,
mt76, and soon iwl),
and we don't have infinitely long queues...
new problems are rearing their heads. Recently I tried to deploy a few
babel 1.8.2 nodes
with the latest openwrt, which I had to back out rapidly because I was
dropping so many
babel packets under contention.
A patch to universally enable babel ecn in net.c "solves" this
problem, even with no defined response,
my network - particularly the congested gw in the middle - got a *ton*
more reliable. But this opens whole cans of worms as to what the right
approach is to respond to CE marks (mine is to treat it like a loss -
or like half a loss - but to never expire the route merely because it
is congested) - and doesn't solve the infinite queue problem either.
Honestly I'd hoped to have unicast to deploy rather than continue to
fiddle with ecn.
https://www.bufferbloat.net/projects/ecn-sane/wiki/
--
Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
next prev parent reply other threads:[~2018-09-18 23:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-19 4:15 [Make-wifi-fast] " Dave Taht
2018-09-18 23:19 ` [Make-wifi-fast] [Babel-users] " Juliusz Chroboczek
2018-09-18 23:31 ` Dave Taht [this message]
2018-09-19 0:04 ` Juliusz Chroboczek
2018-09-19 0:07 ` Jonathan Morton
2018-09-19 0:32 ` Dave Taht
2018-09-19 0:43 ` Juliusz Chroboczek
2018-09-19 0:53 ` Dave Taht
2018-09-19 6:05 ` Jonathan Morton
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=CAA93jw6oiCXgvmsdzhUmhtHy_fq5pKCQE4HE0-9BBthCGrS-Vw@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=babel-users@lists.alioth.debian.org \
--cc=jch@irif.fr \
--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