Thread (27 messages) 27 messages, 8 authors, 2011-06-03

Re: Initial automatic channel selection implementation

From: Felix Fietkau <hidden>
Date: 2011-05-25 19:20:53

On 2011-05-25 5:01 PM, Luis R. Rodriguez wrote:
On Wed, May 25, 2011 at 7:45 AM, Helmut Schaa
[off-list ref]  wrote:
quoted
 On Wed, May 25, 2011 at 4:37 PM, Luis R. Rodriguez[off-list ref]  wrote:
quoted
 On Wed, May 25, 2011 at 5:19 AM, Helmut Schaa
 [off-list ref]  wrote:
quoted
 On Wed, May 25, 2011 at 12:54 AM, Luis R. Rodriguez[off-list ref]  wrote:
quoted
 Yes, thanks this is a lot of work already done. Now we just need a
 basic algorithm to parse this, quantify how ideal this channel is and
 then spit out a desired optimal channel.
 That's what I've hacked some time ago (in form of the attached _ugly_ shell
 script that does auto channel selection with rt2x00, not sure if it works
 correct with other drivers as the survey dump differs somehow between
 rt2x00, ath5k and ath9k, and it only does channel 1-11):

 - Iterate over all channels and stay on each channel for some time
 Nice, yeah I was thinking of using the offchannel operation if we want
 to spend more time there for inspection and if associated. For first
 iteration it should be possible to just move around. In fact for AP
 purposes I suppose one will want to just start AP mode ASAP and then
 later do offchannel operations to do the inspection on the ideal
 channel. Otherwise we sit there idle until we complete the Automatic
 Channel Selection thingy.
 Correct, especially if we also consider 5Ghz channels. Offchannel operations
 would be nice but how can we ensure AP mode while being offchannel?
Notification of absence.
quoted
quoted
quoted
 - Store busy time stats for each channel
 - Choose the channel with the lowest busy time (and on 2.4Ghz also
   check the busy times on adjacent channels)
 So I was reviewing this -- if we are TX'ing or RX'ing it seems to me
 we should skip that time from the busy time, otherwise the "busy" time
 includes time we induced on TX'ing or RX'ing ourselves. So I was
 thinking of using the:

   (active time - rx time - tx time)  / busy time
 Looks good ;) just one problem from a rt2x00 POV: We can't report rx/tx busy
 time separately, we can only advice the hw to include or exclude rx/tx time
 from the busy time statistics.
Doh, I see.. well in order for the above math to be useful we'd have
to be consistent across drivers. What is being done by rt2x00 right
now? If the later then the math would still work, otherwise then we'd
need to adjust.
Excluding rx time isn't even a good idea, since it makes no distinction 
between local BSS or other activity in the area.

- Felix
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help