On 02/06/2011 11:59 AM, Felix Fietkau wrote:
On 2011-02-06 8:54 PM, Ben Greear wrote:
On 02/06/2011 11:42 AM, Felix Fietkau wrote:
On 2011-02-06 8:01 PM, Ben Greear wrote:
Current code always sets the channel type to NO_HT when scanning.
From what I can tell, we should be able to send NO_HT packets on
any channel type, and for passive scanning, it should not matter
at all what channel-type we are using.
I tested relaxing scanning to use the current channel type
when scanning on the operating channel, and it seems to
work.
Does anyone see any problems with this approach?
One thing you should make sure is that once you're done associating to
an NO_HT or HT20 AP (and you have no other interfaces to consider), the
channel mode must not be HT40 - otherwise it could reduce throughput.
That is currently handled correctly by the ieee80211_set_channel_type
method, as far as I can tell...
Regardless of that, in my multi-vif testing, I see lower throughput when
using HT40- than using HT20 (between 128 ath9k vif machine and 1 VAP ath9k machine).
The VIFS all claim 300Mbps rate.
I haven't looked into this any further at this point...
Well, with HT40 you take a hit from not just the busy time of the
primary channel, but also from the busy time of the extension channel.
If you have other wifi activity on the extension channel, then it's
normal that this would reduce throughput.
I think you perfectly described the problem. I had another system that
had a bunch of STAs configured and was making all sorts of noise.
With it powered down, latency & throughput looks quite nice
with 300Mbps HT40- (128 stas, 20kbps per sta tx and rx to other stas).
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
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
