On Wed, May 25, 2011 at 12:20 PM, Felix Fietkau <nbd@xxxxxxxxxxx> wrote: > On 2011-05-25 5:01 PM, Luis R. Rodriguez wrote: >> >> On Wed, May 25, 2011 at 7:45 AM, Helmut Schaa >> <helmut.schaa@xxxxxxxxxxxxxx> Âwrote: >>> >>> ÂOn Wed, May 25, 2011 at 4:37 PM, Luis R. Rodriguez<mcgrof@xxxxxxxxx> >>> Âwrote: >>>> >>>> ÂOn Wed, May 25, 2011 at 5:19 AM, Helmut Schaa >>>> Â<helmut.schaa@xxxxxxxxxxxxxx> Âwrote: >>>>> >>>>> ÂOn Wed, May 25, 2011 at 12:54 AM, Luis R. Rodriguez<mcgrof@xxxxxxxxx> >>>>> Â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. What if we do an offchannel operation? 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
