[PATCH] wpa_supplicant: Prefer 5 GHz networks over 2.4 GHz networks.
Thu Aug 18 09:30:38 PDT 2011
[resending from the right account...]
On Tue, Aug 16, 2011 at 3:50 PM, Dan Williams <dcbw at redhat.com> wrote:
> On Tue, 2011-08-16 at 10:43 -0700, Sam Leffler wrote:
> > On Mon, Aug 15, 2011 at 3:41 PM, Dan Williams <dcbw at redhat.com> wrote:
> > > On Fri, 2011-08-05 at 16:23 -0700, Gary Morain wrote:
> > >> In scan.c, merge a channel's noise value into the scan results. When
> > >> scan results, compute the signal-to-noise ratio and use it when
> > >> Prefer a 5 GHz network if its SNR is really big (> 30) or if its SNR
> > >> relatively close to the other network's.
> > >
> > > Honestly I'd rather have something like a "bands" option on a
> > > per-netblock basis, so you could do this:
> > >
> > > bands=5
> > > bands=5,2
> > > bands=2,5
> > > bands=2
> > >
> > > ie, the connection manager can set whichever band it prefers, or leave
> > > it out entirely to let the supplicant do whatever it's already doing.
> > > The problem with micro-optimizations like this are that they often
> > > break, and they aren't necessarily clear. I'd advocate for simpler,
> > > clearer rules here, with behavior set by the connection manager, rather
> > > than continually more complicated matching rules in the supplicant
> > > itself...
> > I'm trying to understand how this would be used. The point of Gary's
> > change is to prefer the 5GHz band only when two AP's have equivalent
> > signal quality. (5GHz is considered better because it has
> > non-overlapping channels, less likely to have interference, etc.)
> > This is meant to improve the algorithm by which a BSS is selected.
> Yeah, I guess that's different than I'm proposing. But making this
> decision is still a policy decision that I'm not sure should be done in
> the supplicant.
The supplicant already makes a decision on which channel to use. I'm not
proposing a new policy but instead a refinement of the existing policy to
prefer 5 GHz channels.
There are in fact two refinements in the CL.
1) Instead of using signal level as the criteria for channel quality, use
signal-to-noise ratio if available. SNR is a better metric. Also, cap SNR
at 30 because channels with an SNR greater than 30 will perform equally well
from a signal quality point of view. Using SNR for selecting channel is
better for all bands.
2) If two channels have the same or close-enough SNR, then prefer the 5 GHz
channel. Because of the capping of SNR at 30, it is much more likely that
this preference will occur.
What seems to be controversial is preferring 5 GHz channels. This behavior
can be configurable. For sake of simplicity, I propose making the 5 GHz
preference a compile-time option, defaulted to off.
Can we get agreement on this?
> > Also, specifying a preference on a per-netblock basis seems odd; when
> > would you want to control band preferences only for a specific SSID?
> I've had this request come up periodically. If your institution uses
> the same SSID between the 5GHz and 2.4GHz wifi networks, but you'd like
> to always be on the 5GHz segment because it's less loaded. But other
> places you may not want to be on the 5GHz network. It really is a
> per-SSID (ie per network) preference.
> > You can lock down a netblock using bssid= and assign priority though
> > it might be painful to list all the AP's in an ESS. If we really want
> > to add this complexity it seems like it belongs per-interface or
> > global (or at compile-time).
> I disagree. It's not global to the entire decision, it's specific to
> the netblock. You may not always want to prefer 5GHz networks
> everywhere you are. The problem with the freq= parameter is that to
> achieve this behavior you'd have to list *all* the frequencies in the
> 5GHz and 2.4GHz range, while using bssid= is a no-go because the
> situation where you want this behavior is one where there are a ton of
> APs around.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Hostap