ACS seems not to select the best channel in 2.4GHz.

[Jouni Malinen]

On Thu, Feb 05, 2015 at 07:03:16PM +0100, Eduard GV wrote:
> After some experiments and some math[3], we concluded that the
> adjacent channel (i.e. my center frequency +- 5MHz) is barely filtered
> (~0.5dB), so I'd suggest
> #define ACS_ADJ_WEIGHT 0.85
> 
> For the case of 2-channel separation (i.e. my center frequency +
> 10MHz) , the attenuation was ~2.5dB, so I'd suggest
> #define ACS_NEXT_ADJ_WEIGHT 0.55

Thanks, I'll update to those values.

> In fact, I'd also suggest that the "next to the next" adjacent channel
> (i.e. my center frequency +- 15MHz) should also be taken into account
> with a weight of 0.22 since transmissions three channels away do have
> an impact on my current channel.

I'm open to considering this extension, but for the initial step, I'd
likely to keep changes rather minimal.

> On the one hand, I agree that summing of interference_factors doesn't
> make much sense (you are summing channel utilization ratios, which
> could produce values > 100% of channel utilization?!?). On the other
> hand, band-edge channels are actually less interfered since they have
> less adjacent channels and, hence, it makes sense they are preferred
> (i.e., averaging those interference_factors is not my favorite option
> either).
> What I'd like to try (at some point, when I have time and resources)
> is a different formula for the interference_factor. Something like the
> linear sum of the average signal level measured in all channels
> (applying attenuation factors) and weighted by their utilization.

I'd certainly welcome experimentation in this area. I agree that there
may indeed be many cases where the band-edge channels are the best
candidates, but there are also reasons for not using these in some
cases. I don't think the current changes give too much of a preference
to channel 6, but if that turns out to be the case, this can obviously
be fine-tuned.

> Why not 1, 5, 9, 13 (where available)?

That is somewhat of a complex area.. In theory, if most devices around
you were to be using those channels efficiently, I'd agree with that
being a good default policy. However, that does not seem to be the case.
At least most of the APs that I've used in Europe end up defaulting to
channel 1, 6, or 11 and might not even always provide the option of
using 12-13. As such, I'd assume there is a significant existing
deployment of APs on channels 1, 6, and 11 and it may be better to use
those channels by default rather than try to bring in a different mix as
another "standard".

It would actually be interesting to see some statistics on operating
channel use in European deployments. Some quick searches through public
reports on this seemed to point towards channels 1, 6, 11 being used in
around 75% cases and 5, 9, 13 having a minimal (< 10 % in total) use.

In addition to the actual deployments, there are station implementation
reasons for 1, 6, 11 being a convenient set. Number of scan
optimizations make it more likely for APs to be found on those channels,
e.g., due to them being searched first or more frequently and channel 13
being scanned only with passive scanning. In addition, some P2P use
cases are quite a bit more efficient if the AP connection is on one of
the social channels (which, surprise surprise, are those 1, 6, 11).

All that said, it may make sense to provide an option for configuring
different bias for which channels to prefer. There may be reasons that
give different preferences even between whatever the set of selected
common channels are, so making this a bit more flexible could be useful.

-- 
Jouni Malinen                                            PGP id EFC895FA