Using host's rate-ctrl in ath10k?

Using host's rate-ctrl in ath10k?

[Ben Greear]

Has anyone looked into what it would take to use standard host OS's
rate control (minstrel_ht) with ath10k?

I suspect the ath10k rate control logic in the firmware is
a bit dodgy, and it would be nice to use something with wider
testing such as minstrel_ht...

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Using host's rate-ctrl in ath10k?

[Michal Kazior]

On 22 September 2014 19:42, Ben Greear <greearb@candelatech.com> wrote:
> Has anyone looked into what it would take to use standard host OS's
> rate control (minstrel_ht) with ath10k?
>
> I suspect the ath10k rate control logic in the firmware is
> a bit dodgy, and it would be nice to use something with wider
> testing such as minstrel_ht...

Correct me if I'm wrong but that would require tx completions to
include tx retry information and a way to setup tx retries.

I recall there's a WMI command to control tx retries in 10.1 but I
think the WMI service bitmap doesn't indicate it as enabled (at least
in official firmware binaries) so I guess it's just a no-op now.
There's also HTT pktlog which is able to deliver tx descriptors to the
host but these aren't public.


Michał

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Using host's rate-ctrl in ath10k?

[Ben Greear]

On 09/23/2014 12:17 AM, Michal Kazior wrote:
> On 22 September 2014 19:42, Ben Greear <greearb@candelatech.com> wrote:
>> Has anyone looked into what it would take to use standard host OS's
>> rate control (minstrel_ht) with ath10k?
>>
>> I suspect the ath10k rate control logic in the firmware is
>> a bit dodgy, and it would be nice to use something with wider
>> testing such as minstrel_ht...
> 
> Correct me if I'm wrong but that would require tx completions to
> include tx retry information and a way to setup tx retries.

Something like that...I have not looked in detail.  It would
require a re-compile of the firmware at least.

I just don't like that we are depending on the firmware for something
something as tricky as rate control, especially when it seems buggy.

But, I don't have time to deal with trying to move it into
the driver now, and certainly not as a patch I would have to
carry forever in my own tree.

Thanks,
Ben


> I recall there's a WMI command to control tx retries in 10.1 but I
> think the WMI service bitmap doesn't indicate it as enabled (at least
> in official firmware binaries) so I guess it's just a no-op now.
> There's also HTT pktlog which is able to deliver tx descriptors to the
> host but these aren't public.
> 
> 
> Michał
> 
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
> 


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Using host's rate-ctrl in ath10k?

[Avery Pennarun]

On Tue, Sep 23, 2014 at 12:06 PM, Ben Greear <greearb@candelatech.com> wrote:
> On 09/23/2014 12:17 AM, Michal Kazior wrote:
>> On 22 September 2014 19:42, Ben Greear <greearb@candelatech.com> wrote:
>>> Has anyone looked into what it would take to use standard host OS's
>>> rate control (minstrel_ht) with ath10k?
>>>
>>> I suspect the ath10k rate control logic in the firmware is
>>> a bit dodgy, and it would be nice to use something with wider
>>> testing such as minstrel_ht...
>>
>> Correct me if I'm wrong but that would require tx completions to
>> include tx retry information and a way to setup tx retries.
>
> Something like that...I have not looked in detail.  It would
> require a re-compile of the firmware at least.
>
> I just don't like that we are depending on the firmware for something
> something as tricky as rate control, especially when it seems buggy.

I definitely agree with this.  Once of the best things about the ath9k
driver is its excellent rate control, and the ability of others to
experiment on rate control to improve it further.  We've lost this
with the ath10k and it makes things significantly worse in some of our
benchmarks in non-ideal network conditions.

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k