Message-ID: <4D4EFD87.4010005@openwrt.org>
Date: Sun, 06 Feb 2011 20:59:03 +0100
From: Felix Fietkau <nbd@openwrt.org>
MIME-Version: 1.0
To: Ben Greear <greearb@candelatech.com>
CC: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: Scanning and channel types.
References: <4D4EF004.3040109@candelatech.com> <4D4EF99D.5020601@openwrt.org> <4D4EFC76.6090000@candelatech.com>
In-Reply-To: <4D4EFC76.6090000@candelatech.com>
Content-Type: text/plain; charset=ISO-8859-1
Sender: linux-wireless-owner@vger.kernel.org

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.

- Felix