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

[Dave Taht]

On Wed, May 11, 2016 at 7:12 AM, Dave Täht <dave at taht.net> wrote:
>
>
> On 5/10/16 2:04 AM, Toke Høiland-Jørgensen wrote:
>> David Lang <david at lang.hm> writes:
>>
>>> There are two parts to this process
>>>
>>> 1. the tactical (do you send the pending packet immediately, or do you
>>> delay it to see if you can save airtime with aggregation)
>>
>> A colleague of mine looked into this some time ago as part of his PhD
>> thesis. This was pre-801.11n, so they were doing experiments on adding
>> aggregation to 802.11g by messing with the MTU. What they found was that
>> they actually got better results from just sending data when they had it
>> rather than waiting to see if more showed up.
>
> cat 802.11g_research/* > /dev/null

Sorry, that was overly pithy (precoffee here). What I'd meant was that
802.11e's assumptions as to how to do scheduling, particularly for
QoS, and how 802.11g behaved in comparison to n and later, does not
give you much of a starting point on how to address things now.
Successive standards and implementations have made certain things much
better and other things much worse.

Adopting 802.11e style QoS framing - good idea
Adopting 802.11e style hw queue scheduling (EDCA) by mapping diffserv
queues blindly to to those hw queues - horrific, without also
attempting to meet the service time requirements in the software queue
management. I have been perpetually demonstrating 200+ms VO queues
since day one, starving the other queues, where what you want is a
very short queue (under 10ms), served sparsely (say, no more than 2 or
4/10ths of the overall airtime) - and only "The right stuff" to map
into it. CS6/CS7 do not belong in VO.

802.11n - It became saner to just aggregate in most cases where you
might have used 802.11e qos, steering flows into the next packed txop.
And as noted elsewhere[1], per station queuing so you can, indeed,
aggregate sanely.

Packing on all the new management frames and crypto without sanely
managing those, not so good idea.

Holding multicast to it's 1998 rate... grump.

802.11ac - adopting the better framing universally for all hw queues -
good. Still blindly exposing those queues to userspace - horrible.
Hiding most the rate control and retry information (as all firmware
seem to do thus far), tying our hands behind our backs. Using up all
the channels in a world with an ever increasing density of aps and
stations and trying to manage the allocations in hardware, scary. Four
color theorem....

Cramming up to 4MBytes into a single TXOP - what a great lab result! I
have no idea how to do that, and am pretty sure even trying is
undesirable.

...

I'd like to (re)start with 802.11ac assumptions and work backwards,
rather than 802.11g assumptions and work forwards. The most desirable
thing I'd love to see is hardware capable of turning the tail end of a
txop around and
sending some real data back, and to know if QosNoack can be
selectively used.....

And on my bad days, I really would like to go back to playing with
5mhz channels (which the ath9k still supports), and getting channel
selection to work better. I'd rather have 5mbits of reliable low
latency bandwidth in the real world, than 500Mbits in a faraday cage.

/me goes in search of some more coffee.

[1] I really wanted people to argue with me about this talk one day...
http://blog.cerowrt.org/post/talks/make-wifi-fast/


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