Return-path: Received: from nbd.name ([46.4.11.11]:47888 "EHLO nbd.name" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753406Ab1EYTUx (ORCPT ); Wed, 25 May 2011 15:20:53 -0400 Message-ID: <4DDD5691.2040205@openwrt.org> (sfid-20110525_212057_415327_EF3B21CB) Date: Wed, 25 May 2011 21:20:49 +0200 From: Felix Fietkau MIME-Version: 1.0 To: "Luis R. Rodriguez" CC: Helmut Schaa , linux-wireless , hostap@lists.shmoo.com, Matt Smith Subject: Re: Initial automatic channel selection implementation References: <201105241627.49201.helmut.schaa@googlemail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Sender: linux-wireless-owner@vger.kernel.org List-ID: On 2011-05-25 5:01 PM, Luis R. Rodriguez wrote: > On Wed, May 25, 2011 at 7:45 AM, Helmut Schaa > wrote: >> On Wed, May 25, 2011 at 4:37 PM, Luis R. Rodriguez wrote: >>> On Wed, May 25, 2011 at 5:19 AM, Helmut Schaa >>> wrote: >>>> On Wed, May 25, 2011 at 12:54 AM, Luis R. Rodriguez wrote: >>>>> 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. > >>>> - 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