Search Linux Wireless

Re: Initial automatic channel selection implementation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 26, 2011 at 5:23 PM, Felix Fietkau <nbd@xxxxxxxxxxx> wrote:
> On 2011-05-27 1:45 AM, Luis R. Rodriguez wrote:
>>
>> On Thu, May 26, 2011 at 3:45 AM, Felix Fietkau<nbd@xxxxxxxxxxx> Â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.

Alright, I'll include rx time too, I'm not really keen either way,
just trying to get a proof of concept going and moving.

Oh and for the record and quick cache of this information.. the busy
time is defined on Atheros hardware by the "The receive clear counter
" register, (AR_RCCNT, 0x80F4). The receive clear counter counts the
number of cycles the rx_clear signal is "NOT" active.

  Luis
--
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


[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux