On Wed, May 25, 2011 at 12:24 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxx> wrote: > 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? Once we figure out that... 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. 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
