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

[Dave Taht]

On Mon, May 9, 2016 at 7:25 PM, Jonathan Morton <chromatix99 at gmail.com> wrote:
>
>> On 9 May, 2016, at 18:35, Dave Taht <dave.taht at gmail.com> wrote:
>>
>> should we always wait a little bit to see if we can form an aggregate?
>
> I thought the consensus on this front was “no”, as long as we’re making the decision when we have an immediate transmit opportunity.

I think it is more nuanced than how david lang has presented it. We
haven't argued the finer points just yet -
merely seeing 12-20ms latency across the entire 6-300mbit range I've
tested thus has been a joy,
and I'd like to at least think about ways to cut another order of
magnitude off of that while making better use of packing the medium.

http://blog.cerowrt.org/post/anomolies_thus_far/

So... I don't think we "achieved consensus", I just faded... I thought
at the time that merely getting down from 2+seconds to 20ms induced
latency was vastly more important :), and I didn't want to belabor the
point until we had some solid results. I'll still settle for "1 agg in
the hardware, 1 agg in the driver"... but smaller, and better formed,
aggs under contention - which might sometimes involve a pause for a
hundred usec to gather up more, when empty, or more, when the driver
is known to be busy.

...

Over the weekend I did some experiments setting the beacon advertised
txop size for best effort traffic to 94 (same size as the vi queue
that was so busted in earlier tests (
http://blog.cerowrt.org/post/cs5_lockout/ ) ) to try to see if the
station (or AP) paid attention to it... it was remarkable the
bandwidth symmetry I got compared to the defaults. This chart also
shows the size of the win against the stock ath10k firmware and driver
in terms of latency, and not having flows collapse...

http://blog.cerowrt.org/flent/txop_94/rtt_fairbe_compared.svg

Now, given then most people use wifi asymmetrically, perhaps there are
fewer use cases for when the AP and station work more symmetrically,
but this was a pretty result.

http://blog.cerowrt.org/flent/dual-txop-94/up_down_vastly_better.svg

Haven't finished writing up the result, aside from tweaking this
parameter had no seeming affect on the baseline 10-15ms driver latency
left in it, under load.

>
> If we *don’t* have an immediate transmit opportunity, then we *must* wait regardless, and maybe some other packets will arrive which can then be aggregated.
>
>  - Jonathan Morton
>



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