Hi Johannes,
When testing with iperf I've been observing very significant problems
with throughput and packet loss during software scans. Throughput often
drops to the point where iperf is reporting 0 bits/sec for several
seconds, and packet loss commonly gets over 20%. I started investigating
and discovered the following problems:
1. It seems that drivers are responsible for ensuring that PM is set in
frame control when powersave is enabled. However drivers are unaware
of off-channel powersave, so when the scan is suspended frames may
be transmitted that cause the AP to think we've exited powersave. As
a result the AP may attempt to deliver frames while we are
off-channel.
2. There's no flushing of the hardware queues after queueing the
nullfunc frame to enable off-channel powersave before going
off-channel, so it's possible to go off-channel before the frame is
transmitted.
3. There's no flush of pending frames prior to queueing the nullfunc
frame to enable powersave. That frame is sent at a high priority,
and drivers supporting QoS may have lower-priority frames queued
with PM cleared. Those frames will be sent after the nullfunc, and
the AP may try to deliver frames while we are off-channel.
4. During a scan we won't process beacon frames from our associated AP,
which prevents PS-Poll from starting when the scan is suspended.
Even if we process the beacons we won't start PS-Poll unless
powersave is actually enabled, which isn't the case during a scan.
5. The SCAN_SUSPEND state uses a fixed timeout, so if we do start
PS-Poll there's no guarantee that it will receive all buffered
frames from the AP before going back off-channel.
The following RFC patches contain fixes for problems 1, 2, and 3. I
toyed around with fixing 4 and 5, but the results really aren't much
better than before. Even with PS-Poll working properly during scans I
was seeing poor throughput and high packet loss with iperf. So instead I
tried disabling off-channel powersave when the scan is suspended, and
the results were fantastic. The implementation is trivial, packet loss
is completely eliminated, and the performance drops during scans are
modest. Therefore I've included a patch which does this rather than
fixing PS-Poll during scans.
These changes aren't quite complete, although they currently work very
well with ath9k and brcmsmac. I'm hoping to get some feedback on the
changes and answers to some questions before I proceed.
It turns out that fixing problem #1 (i.e. patch 2) probably isn't
necessary with the other changes, as no frames should be sent while
off-channel PS is enabled. Does this still seem like a problem worth
fixing?
If so, there's one other change I had considered making. Currently patch
2 will require all drivers to have some amount of powersave support for
off-channel PS to make sure PM is set. Would it make sense to set PM in
mac80211 when IEEE80211_HW_PS_NULLFUNC_STACK is set?
Thanks,
Seth
Seth Forshee (3):
mac80211: Add flushes to ensure off-channel PS is enabled during sw
scans
mac80211: Convey information about off-channel powersave to drivers
mac80211: Disable off-channel powersave when software scans are
suspended
drivers/net/wireless/ath/ath9k/main.c | 2 +-
.../net/wireless/brcm80211/brcmsmac/mac80211_if.c | 16 +++++--
drivers/net/wireless/brcm80211/brcmsmac/main.c | 10 ++++
drivers/net/wireless/brcm80211/brcmsmac/pub.h | 3 ++
include/net/mac80211.h | 23 ++++++++++
net/mac80211/mlme.c | 19 +++++---
net/mac80211/offchannel.c | 48 +++++++++++++++-----
net/mac80211/scan.c | 20 +++++---
net/mac80211/util.c | 2 +-
9 files changed, 113 insertions(+), 30 deletions(-)
--
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
