Re: [RFC] ath9k: remove ath9k_rate_control

[Felix Fietkau <nbd@openwrt.org>]

On 2013-03-01 2:23 AM, Sujith Manoharan wrote:
> Felix Fietkau wrote:
>> In that case I'd rather keep PID than the ath9k rate control. The ath9k
>> rate control is a horrible example of how to use the rate control API,
>> and fixing that is a waste of time in my opinion.
> 
> I acked the earlier RFC patch to remove the ath9k RC as I assumed that minstrel_ht
> would perform adequately, if not better. But, there appear to be areas in which
> the numbers given by minstrel_ht are sub-optimal and which can be improved if we
> have something to compare it with. The ath9k RC code is crap, no doubt, but I'd
> prefer to have it for some time in the tree - we can switch the default RC to minstrel_ht
> by default.
Right, I will only submit this patch again once more performance tests
have been run. My own tests and tests of other people that I know of so
far have shown minstrel_ht to perform better than ath9k_rate_control,
whereas in your tests ath9k_rate_control seems to perform better. I'd
like to get some more details on your tests, e.g. raw numbers, rate
control stats, info on how much the throughput fluctuates, etc.

> Can you also explain how the ath9k RC uses the mac80211 API horribly ? The algorithm might be
> terribly implemented and the internal code nasty, but how does it violate the API ?
When I called it a horrible example, I was referring to the bad code
quality, not API violations. The API violations are only minor, there
are a few places left where the rate control code accesses struct ath_softc.

- Felix