[ath9k-devel] sensitivity control for ath9k with mac80211

[Flavio Leonel <frleonel@gmail.com>]

We Can testing the IW command with txpower limit, but not the ar92xx 
response for this parameter ...

i 'm looking finding one solution for this problem too in my network ..!
can someone help us?

thank for this

ATT: Flavio Leonel
> On 07/19/2013 05:53 PM, Sergey Ryazanov wrote:
>> 2013/7/19 Felix Fietkau <nbd@openwrt.org>:
>>> On 2013-07-19 4:58 PM, Sergey Ryazanov wrote:
>>>> 2013/7/19 Ben Greear <greearb@candelatech.com>:
>>>>> On 07/19/2013 06:36 AM, Flavio Leonel wrote:
>>>>>> Ok i know that but the command iw not permited set sensitivity limit
>>>>>>
>>>>>> how i can seting this limit on atth9k , this question..
>>>>> I tried messing with this some months ago and got nowhere.  I could
>>>>> not figure any way to make the NIC ignore fainter signals, and I am
>>>>> not sure it is possible to make the hardware do this...
>>>>>
>>>> At least 5k chips have a special register for CCA threshold
>>>> configuration. Modern 9k chips have not inherited this register?
>>> The CCA threshold is not the same as the threshold for signal detection.
>>> In many ways, 5k and 9k cards have a somewhat similar set of registers
>>> to configure various aspects of detection sensitivity. Some of those are
>>> set in the initvals, some are controlled by ANI.
>>> The main issue is that the driver does not expose any convenient knobs
>>> to control this.
>>>
>> Yeah. It would be useful for developers to get delicate and operative
>> control over Tx/Rx process (at least via debugfs). But I never faced
>> with situations where this would be useful for end user. So, IMHO,
>> even if somebody submit appropriate patches, they will not be
>> accepted.
> I do a lot of testing in cases where there are a few APs with signal level of around -70 to -85,
> primarily due to not-that-great shielding, as well as APs in surrounding buildings.
>
> I'd like to be able to tune a NIC so that it just plain ignored those weak signals
> to increase throughput with systems with much better signal quality.
>
> Thanks,
> Ben
>
>