Re: [RFC] ath9k: remove ath9k_rate_control

[Felix Fietkau <nbd@openwrt.org>]

On 2013-02-08 2:30 PM, Sujith Manoharan wrote:
> Felix Fietkau wrote:
>> In many tests throughput with ath9k_rate_control has been shown to be
>> worse than with minstrel_ht (the mac8021 default RC).
>> 
>> This module also has some other problems, like starting to use the
>> highest possible rate early in the connection, causing problems with
>> reliability of connection/authentication attempts.
>> 
>> It also has a much more limited search space, ignoring many potentially
>> useful rates, caused by the design decision to operate on a sorted rate
>> set with the assumption that higher rates are always more unreliable
>> than lower rates. In some scenarios this assumption is not true, and
>> this can cause it to fall back to a really bad rate.
>> 
>> minstrel_ht has been tested extensively in AP and client mode by lots of
>> users (mostly in the OpenWrt project, where it has been the default for
>> years).
>> 
>> The only advantage that ath9k_rate_control previously had over minstrel_ht
>> was the support for using CCK rates as fall back in case MCS rates got
>> too bad, but this has now also been taken care of.
> 
> Various rates are marked as invalid in the ath9k rate control module. I don't
> know all the reasons, but the recommendation to disable certain rates came from
> the internal algorithms team. How will this be handled ?
I'm pretty sure it's because the algorithm isn't designed to handle more
rates. It's a step-up/step-down type algorithm, and those typically only
work with a sorted rateset, preferably duplicate free.

Minstrel_ht selects rates in a different way that doesn't have the same
limitations, so it can use the full rateset.

- Felix