From: Felix Fietkau <nbd@openwrt.org>
To: "Luis R. Rodriguez" <mcgrof@gmail.com>
Cc: Helmut Schaa <helmut.schaa@googlemail.com>,
linux-wireless <linux-wireless@vger.kernel.org>,
hostap@lists.shmoo.com, Matt Smith <Matt.Smith@atheros.com>
Subject: Re: Initial automatic channel selection implementation
Date: Fri, 27 May 2011 02:23:08 +0200 [thread overview]
Message-ID: <4DDEEEEC.6010800@openwrt.org> (raw)
In-Reply-To: <BANLkTimuaOoV0uvyzs9PbeK_k6vwOG=+YA@mail.gmail.com>
On 2011-05-27 1:45 AM, Luis R. Rodriguez wrote:
> On Thu, May 26, 2011 at 3:45 AM, Felix Fietkau<nbd@openwrt.org> wrote:
>> On 2011-05-25 9:27 PM, Luis R. Rodriguez wrote:
>>> The missing piece is how to deal with noise info here. In short the
>>> lower noise we have the better signal we'll get. The challenge then is
>>> to take into consideration the noise mathematically in such a that a
>>> high noise value would nullify any clean idle air time ratio
>>> conditions from the formula postulated before. Let me review again
>>> with some modifications.
>>>
>>> Active time is the time we spend on the channel, so to get an idea of
>>> how "busy" that channel is we have to remove the tx and rx time from
>>> that channel. That gives us the time we spent idle on that channel.
>>> Then the busy time is a subset of the entire active time but we should
>>> also exclude the time we spent tx'ing and rx'ing as well. We then
>>> have:
>>>
>>> (busy time - rx time - tx time) / (active time - rx time - tx time)
>>>
>>> This is a bounded ratio already, given that if we spent 0 time tx'ing
>>> 0 time rx'ing, but 10 ms on a channel, and all that time we had busy
>>> time as well we'd have a ratio of 10 / 10 = 1. In the best case we'd
>>> have 0 / 10 = 0.
>>>
>>> What I'd like to do is to affect the ratio to nullify it if the noise
>>> is very low on the channel. Given that noise is logarithmic we'd have
>>> to use a logarithmic function as well. Working on that now.
>>
>> Please explain why you want to remove the rx time, it makes no sense to me.
>> Without rx time you will usually not get any useful indication of how busy
>> the channel is.
>
> The busy time that happens when do not TX or RX accounts for
> interference on the frequency which is not accounted for. RX time may
> mean receiving beacons or probe responses, this type of data exchange
> doesn't necessarily mean interference. I believe sampling conditions
> each frequency without TX or RX'ing data would yield a more fair
> representation of general interference on the channel, otherwise the
> interference would be taking into consideration explicit forced
> interference on the frequency by our own radio.
I think real channel load (including rx) is much more interesting for
channel selection than only interference. Interference time shouldn't
really matter that much in practice unless it's excessively high. Also,
even normal packets will increase the measured non-rx/tx busy time,
partially due to collisions, partially (on Atheros radios) because of
the way the radio works.
- Felix
next prev parent reply other threads:[~2011-05-27 0:23 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-24 12:48 Initial automatic channel selection implementation Luis R. Rodriguez
2011-05-24 14:27 ` Helmut Schaa
2011-05-24 18:07 ` Eduard GV
2011-05-24 21:21 ` Pavel Roskin
2011-05-24 22:54 ` Luis R. Rodriguez
2011-05-25 12:19 ` Helmut Schaa
2011-05-25 14:37 ` Luis R. Rodriguez
2011-05-25 14:45 ` Helmut Schaa
2011-05-25 15:01 ` Luis R. Rodriguez
2011-05-25 19:20 ` Felix Fietkau
2011-05-25 19:24 ` Luis R. Rodriguez
2011-05-25 19:27 ` Luis R. Rodriguez
2011-05-25 20:01 ` Luis R. Rodriguez
2011-05-26 10:45 ` Felix Fietkau
2011-05-26 23:45 ` Luis R. Rodriguez
2011-05-27 0:23 ` Felix Fietkau [this message]
2011-05-27 0:59 ` Luis R. Rodriguez
2011-06-02 22:36 ` Luis R. Rodriguez
2011-06-02 23:49 ` Felix Fietkau
2011-06-03 5:23 ` Luis R. Rodriguez
2011-05-26 7:37 ` Jouni Malinen
2011-05-24 15:28 ` Pavel Roskin
2011-05-24 16:44 ` Cristian Ionescu-Idbohrn
2011-05-24 17:04 ` Pavel Roskin
2011-05-25 4:24 ` Helmut Schaa
2011-05-25 4:39 ` Adrian Chadd
2011-05-25 8:08 ` Cristian Ionescu-Idbohrn
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=4DDEEEEC.6010800@openwrt.org \
--to=nbd@openwrt.org \
--cc=Matt.Smith@atheros.com \
--cc=helmut.schaa@googlemail.com \
--cc=hostap@lists.shmoo.com \
--cc=linux-wireless@vger.kernel.org \
--cc=mcgrof@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).