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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
