[PATCH] WLAN: --power maxperf shot into the dark
werner at openmoko.org
Tue Jan 27 22:36:24 CET 2009
Joel Newkirk wrote:
> Have you run a cycle of your bouncing-ap-channel tests with maxperf?
That's a good idea, thanks !
I'm now cleaning up my test setup, such that the tests are free from
contamination. E.g., in the frequency change test, there was also
forced reassociation by the AP and the ESSID didn't change. Both are
not properties of what one would consider normal roaming and I found
that they did affect the outcome of the test.
In fact, the ESSID issue goes a little deeper. My test network
consists of a number of WRT54G and WRT54GL routers, now all running
OpenWRT. When I installed Kamikaze 8.09 RC2, they all ended up with
the same MAC address for their wireless interface. This didn't
bother my laptop (AR5k using mac80211) but the AR6k would never see
more than one of the four stations.
Now, the interesting question is how often one might run into this
sort of surprise in real life. I hope not too often, but if even a
rather popular AP firmware does this, ...
With the test that only produces the frequency change, the AR6k
doesn't seem to crash anymore. The test is still limited by the
Broadcom 4712 stopping to send beacons after toggling txpower a few
times (the Broadcom 5352 doesn't seem to have this problem, so I'll
rotate the stations and hope for the best), but I've now seen a few
hundred changes and the AR6k always performed decently.
If anyone is curious, my test scripts are here:
The test setup involves four stations: two perform the handover
and two are listening on the respective channels. The listening
stations are necessary because a station involved in a handover
may shut down RF transmitter and receiver or even the entire
interface, depending on how the handover is done.
This means that the crash might be caused either by just associating
and deassociating or by a combination of events. I don't have a
clear idea yet what the maxperf issue might be.
More information about the openmoko-kernel