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

["Toke Høiland-Jørgensen" <toke@toke.dk>]

Dave Taht <dave.taht@gmail.com> writes:

> On Wed, May 11, 2016 at 7:12 AM, Dave Täht <dave@taht.net> wrote:
>>
>>
>> On 5/10/16 2:04 AM, Toke Høiland-Jørgensen wrote:
>>> David Lang <david@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.

802.11e != 802.11g. I am completely ignoring 802.11e for now, and the
rest of the standard is not that different between g/n/ac; it's
basically different rates, encodings and interframe gaps. Which from a
scheduling point of view simply means different constants.

Once we have a working baseline scheduler we can think about how to
behave sanely in an 802.11e world; as far as I'm concerned the right
answer might just be "shut it off entirely"... :P

-Toke