On 06/05/2013 09:05 PM, Sujith Manoharan wrote:
Ben Greear wrote:
If you will just delete that code above, then you can compile in both ath9k
and minstrel rate controls and select at run-time by twiddling the mac80211
rate control module option.
I am not sure if a user is going to change the rate control at run-time by
reloading mac80211 and what would be point in using ath9k RC which has basic
connectivity problems ?
Last I tested there were still advantages to ath9k rate control in our environment,
(including when running through an attenuator and over-the-air),
so I think it should be left in to keep minstrel honest if nothing else.
ath9k RC shows slightly higher throughput numbers in an _ideal_ environment,
but that is hardly the case in real-world usage. I agree that the code can
be left in the driver, it will be useful for comparison with minstrel.
Then default to minstrel, but no need to make people re-compile their
kernel to try a different rate control. For some users/systems this is
effectively impossible, and for the rest, it is an extra bit of pain.
The point of leaving ath9k rate control in is exactly to help make sure
minstrel has something to compare against. And if a user happens to know
they have a clean environment always and forever, then ath9k may be
the best solution for them.
It is a trivial amount of change to your patch to enable this
behaviour. In fact, if you just remove the code I mentioned then
they will *automatically* get defaulted to minstrel regardless of
their kernel config. The only way to use ath9k rate control after
that is to set the module option in mac80211 (and enable ath9k rate
control for compilation).
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
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
