[Make-wifi-fast] Experimental ath10k airtime fairness patch?

[Dave Taht]

With versions of the patchset going back to august, we tested airtime
fairness with 4, 12, and 30 under a variety of conditions. It looked
*really good*. In one scenario, with one slow station and 28 "faster"
ones, we got 5x more throughput through the AP while retaining low
latency.

I'd planned, til recently, to roll it out to my production (babel)
mesh at the yurtlab this month, but various factors (like having to
climb roofs in the winter, and some other bugs in powersave, recently
resolved, and a nagging issue with TSQ), have thus far stopped me.
There have been so many other mods elsewhere in the stack since that
original round of testing that a full on set of tests with lede head
are needed, and certainly my hope is a few more teams get excited
enough to do evaluations in their environments.

On Thu, Nov 17, 2016 at 1:04 AM, Valent Turkovic
<valent at otvorenamreza.org> wrote:
> Hi guys,
> this news is awesome! Aritime fairness is really missing feature.
>
> Has anyone done some tests? What kind of difference do you see with and
> without the patch? Has anyone tested the patch with 20+ clients?
>
> Cheers,
> Valent.
>
> On Thu, Nov 17, 2016 at 12:59 AM, Noah Causin <n0manletter at gmail.com> wrote:
>>
>> Thank you for the patch.
>>
>>
>>
>> On 11/15/2016 1:36 PM, Michal Kazior wrote:
>>>
>>> On 14 November 2016 at 18:06, Noah Causin <n0manletter at gmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I was wondering if there is an experimental airtime fairness patch for
>>>> the
>>>> ath10k on LEDE.
>>>>
>>>> I have been using Toke's patch for enabling intermediate queue support
>>>> on
>>>> the ath10k, and it has been working well.
>>>
>>> I did some work on that but didn't finish nor publish it.
>>>
>>> I just dug around my git repo and found something. I can't remember if
>>> it was this exactly what I used in the "100 station" thingy[1][2] or
>>> not. Attached.
>>>
>>> Feel free to play around it if you want. It should provide fairness
>>> but will degrade peak performance due to delayed firmware aggregation
>>> introducing extra idling latency and the naive design.
>>>
>>> You'll most likely need to rebase it.
>>>
>>> [1]: http://imgur.com/a/sSn8V
>>> [2]:
>>> http://www.linuxplumbersconf.com/2016/ocw//system/presentations/3963/original/linuxplumbers_wifi_latency-3Nov.pdf
>>> page 28, 30
>>>
>>>
>>> Michał
>>
>>
>> _______________________________________________
>> Make-wifi-fast mailing list
>> Make-wifi-fast at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>
>
>
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>



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