All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felix Fietkau <nbd@openwrt.org>
To: Ben Greear <greearb@candelatech.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: Scanning and channel types.
Date: Sun, 06 Feb 2011 20:59:03 +0100	[thread overview]
Message-ID: <4D4EFD87.4010005@openwrt.org> (raw)
In-Reply-To: <4D4EFC76.6090000@candelatech.com>

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

  reply	other threads:[~2011-02-06 19:59 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-06 19:01 Scanning and channel types Ben Greear
2011-02-06 19:42 ` Felix Fietkau
2011-02-06 19:54   ` Ben Greear
2011-02-06 19:59     ` Felix Fietkau [this message]
2011-02-06 20:07       ` Ben Greear
2011-02-06 20:23         ` Daniel Halperin
2011-02-06 21:07           ` Ben Greear
2011-02-06 21:09             ` Felix Fietkau
2011-02-07  5:42               ` Daniel Halperin
2011-02-07 18:03                 ` Ben Greear
2011-02-07 18:32                   ` Daniel Halperin
2011-02-07 20:04                     ` Ben Greear
2011-02-07 20:10                       ` Daniel Halperin
2011-02-07 21:01                         ` Jouni Malinen
2011-02-07 21:02                         ` Ben Greear
2011-02-07 23:53                           ` Daniel Halperin
2011-02-08  0:38                             ` Ben Greear
2011-02-09 13:22                               ` Jouni Malinen
2011-02-07 18:23       ` Ben Greear

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D4EFD87.4010005@openwrt.org \
    --to=nbd@openwrt.org \
    --cc=greearb@candelatech.com \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.