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
--
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
