[ath9k-devel] [Make-wifi-fast] Diagram of the ath9k TX path

On Mon, May 9, 2016 at 8:30 PM, Adrian Chadd <[email protected]> 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