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. 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 ? Sujith -- 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
