Lets make wifi fast again!
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: Adrian Chadd <adrian@freebsd.org>
Cc: "Jonathan Morton" <chromatix99@gmail.com>,
	make-wifi-fast@lists.bufferbloat.net,
	"ath9k-devel@lists.ath9k.org" <ath9k-devel@lists.ath9k.org>,
	"Toke Høiland-Jørgensen" <toke@toke.dk>
Subject: Re: [Make-wifi-fast] [ath9k-devel]  Diagram of the ath9k TX path
Date: Mon, 9 May 2016 21:04:55 -0700	[thread overview]
Message-ID: <CAA93jw55fQooUXhqGRQgOfZgwByMVzuZ14XAbi5Ae=oSaHLUjw@mail.gmail.com> (raw)
In-Reply-To: <CAJ-Vmo=KdM3N04Jbnnisvxa-Ot26ywRyDOr+9fJQDkxHw1dK5g@mail.gmail.com>

On Mon, May 9, 2016 at 8:30 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> Hi,
>
> So:
>
> * the hardware can give us a per-AC transmit opportunity;
> * software queuing needs to handle the per-STA transmit opportunity;
> * they (and I followed convention after testing)

"They" had probably not made proper sacrifices to the layer 3
congestion control gods, nor envisioned a world with 10s of stations
on a given ap and dozens of competing APs....

> found the "best"
> compromise was to hardware queue up to two frames, which we could
> probably do slightly more of at higher MCS rates for "reasons", but if
> we're getting enough packets come in then if the hardware queues get
> drained slower than we can fill them, we naturally aggregate traffic.
>
> So it actually works pretty well in practice.

Aside from seconds of queuing on top. :)

Is everybody here on board with reducing that by 2 orders of
magnitude?  I'm not posting all these results and all the flent data
just to amuse myself... The size of the potential patch set for
softmac devices has declined considerably - codel.h and the fq code
are now generalized in some tree or another, and what's left is in two
competing patches under test... one that leverages rate control stats
and wins like crazy, the other, dql, and takes longer to win like
crazy.

http://blog.cerowrt.org/post/ has the writeups
https://github.com/dtaht/blog-cerowrt has all the data and the
writeups still in draft form, in git, for your own bemusement and data
comparisons with the stock drivers.

> The general aim is to
> keep up to ~8ms of aggregates queued, and that's typically two
> aggregate frames so we don't bust the block-ack window.

My understanding was that hardware retry exists for the ath9k at
least, and that block-acks responded in under 10us. Also that ath9k
allowed you to describe and send up to 4 chains at different rates.
Yes?

As for "busting the window", what I wanted to try was adding in QoS
Noack on frames that you feel could be safely dropped,
so the first part of the txop would have an AMPDU of  stuff you felt
strongly about keeping, the second, one not block acknowledged, and a
third consisting of the last bits of the flows you didn't care about
as much, but want to provide packets for to inform the other side that
drops happened, block acked....

As for software retry, we could be smarter about it than we currently
are. A fixed number of retries (15 in the ath10k driver, 10 in the
ath9k driver) is just nuts...

As for 8ms, well, I'd much rather hand out 1ms each to 8 stations than
8ms each to 8 stations.

>
>
> -adrian



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

  reply	other threads:[~2016-05-10  4:04 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-09 11:00 [Make-wifi-fast] " Toke Høiland-Jørgensen
2016-05-09 15:35 ` Dave Taht
2016-05-10  2:25   ` Jonathan Morton
2016-05-10  2:59     ` Dave Taht
2016-05-10  3:30       ` [Make-wifi-fast] [ath9k-devel] " Adrian Chadd
2016-05-10  4:04         ` Dave Taht [this message]
2016-05-10  4:22           ` Aaron Wood
2016-05-10  7:15           ` Adrian Chadd
2016-05-10  7:17             ` Adrian Chadd
2016-05-10  3:41       ` [Make-wifi-fast] " David Lang
2016-05-10  4:59         ` Dave Taht
2016-05-10  5:22           ` David Lang
2016-05-10  9:04             ` Toke Høiland-Jørgensen
2016-05-11 14:12               ` Dave Täht
2016-05-11 15:09                 ` Dave Taht
2016-05-11 15:20                   ` Toke Høiland-Jørgensen
2016-05-13 17:46         ` Bob McMahon
2016-05-13 17:49           ` Dave Taht
2016-05-13 18:05             ` Bob McMahon
2016-05-13 18:11               ` Bob McMahon
2016-05-13 18:57               ` Dave Taht
2016-05-13 19:20                 ` Aaron Wood
2016-05-13 20:21                   ` Dave Taht
2016-05-13 20:51                     ` Dave Taht
2016-05-13 20:49           ` David Lang

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='CAA93jw55fQooUXhqGRQgOfZgwByMVzuZ14XAbi5Ae=oSaHLUjw@mail.gmail.com' \
    --to=dave.taht@gmail.com \
    --cc=adrian@freebsd.org \
    --cc=ath9k-devel@lists.ath9k.org \
    --cc=chromatix99@gmail.com \
    --cc=make-wifi-fast@lists.bufferbloat.net \
    --cc=toke@toke.dk \
    /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