After the oops I just described in the previous e-mail I disabled the
"Wireless-N only" feature and set the AP to "Wireless-BG only" feature
on the AP. I then observed some terrible throughput on iperf using UDP
(TX'ing out). Here is the last "watch cat rcstat" output, the box then
just hung with no panic or trace (even through netconsole):
Every 2.0s: cat rcstat
Tue Nov 10 16:31:56 2009
Rate Success Retries XRetries PER
1.0: 712 4930 1491 100
2.0: 103 453 159 87
5.5: 111 202 55 28
11.0: 8 30 11 43
6.0: 0 0 0 0
9.0: 0 0 0 0
12.0: 5 19 7 87
18.0: 1 14 6 75
24.0: 1 6 1 30
36.0: 0 0 0 0
48.0: 0 0 0 0
54.0: 0 0 0 0
Its unclear if something other than the rate control algorithm used is
what could be busted, I cannot see from the logs.
One way or another I think we should prioritize making ath9k work with
minstrel optionally on legacy networks at least for now, and see if we
can help Felix test/advance minstrel support for MCS rate support.
The ath9k rate control code proves unmaintainable, not clearly
understood even with things like this:
/* Update PER, RSSI and whatever else that the code thinks it is doing.
If you can make sense of all this, you really need to go out more. */
We can't possibly successfully maintain a driver with code like this.
Luis
Luis R. Rodriguez wrote:
> One way or another I think we should prioritize making ath9k work with
> minstrel optionally on legacy networks at least for now, and see if we
> can help Felix test/advance minstrel support for MCS rate support.
>
> The ath9k rate control code proves unmaintainable, not clearly
> understood even with things like this:
>
> /* Update PER, RSSI and whatever else that the code thinks it is doing.
> If you can make sense of all this, you really need to go out more. */
I'll send a patch removing this comment. :-)
Sujith
On Tue, Nov 10, 2009 at 8:11 PM, Sujith <[email protected]> wrote:
> Luis R. Rodriguez wrote:
>> One way or another I think we should prioritize making ath9k work with
>> minstrel optionally on legacy networks at least for now, and see if we
>> can help Felix test/advance minstrel support for MCS rate support.
>>
>> The ath9k rate control code proves unmaintainable, not clearly
>> understood even with things like this:
>>
>> /* Update PER, RSSI and whatever else that the code thinks it is doing.
>> If you can make sense of all this, you really need to go out more. */
>
> I'll send a patch removing this comment. :-)
Heh, that piece of text is valid though, it'd do more harm to the read
to remove it.
On a better note, I took the same AP (WRT610n v1) and same laptop with
AR9285 home and things are lot nicer. I get average about ~17 Mbit/s
and rcstat looks like this after a while:
Every 2.0s: cat rcstat
Tue Nov 10 20:12:00 2009
Rate Success Retries XRetries PER
1.0: 34 184 46 12
2.0: 105 75 30 6
5.5: 76 45 13 7
11.0: 138 38 9 7
6.0: 0 0 0 0
9.0: 0 0 0 0
12.0: 485 66 11 7
18.0: 6291 408 50 7
24.0: 13820 3550 665 9
36.0: 581538 58714 4602 6
48.0: 27661 47472 23272 48
54.0: 336 1973 1200 47
This was with the same kernel, 2.6.31 on ubuntu 9.10 with the
linux-backport-modules package (which takes the 2.6.32-rc6 wireless
bits) with the AP configured to bg-only.
The distance to the APs has been the same in both tests. The only
difference was the noise. My results on my original post are from
using the card and AP at work, where there are easily over 60 APs in
my area. Granted, not what your average user would run into but it
still needs to be addressed.
Luis
So I tested the AP with 11n-only option setting both on 20mhz and 40
mhz channel bandwidth setting (although in reality I only see it
setting itself to 20 mhz). The rates are not so bad, I consistant
usage of MCS4 with throughput sometimes hitting 30mbps on the end
iperf server.
Here is the rcstat
very 2.0s: cat rcstat
Tue Nov 10 21:05:37 2009
Rate Success Retries XRetries PER
1.0: 0 0 0 0
2.0: 0 0 0 0
5.5: 0 0 0 0
11.0: 0 0 0 0
6.0: 0 0 0 0
9.0: 0 0 0 0
12.0: 0 0 0 0
18.0: 0 0 0 0
24.0: 0 0 0 0
36.0: 0 0 0 0
48.0: 0 0 0 0
54.0: 0 0 0 0
6.5: 0 0 0 0
13.0: 1 0 0 0
19.5: 650 77 5 0
26.0: 31906 3022 148 10
39.0: 49889 13260 2853 17
52.0: 3421 2318 1199 28
58.5: 21 81 63 87
65.0: 0 0 0 0
So it seems the issues I saw are only caused on extremely noisy environments.
Luis