<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 18, 2011, at 9:30 AM, Gary Morain wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">[resending from the right account...]</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Tue, Aug 16, 2011 at 3:50 PM, Dan Williams <span dir="ltr"><<a href="mailto:dcbw@redhat.com">dcbw@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="HOEnZb"><div></div><div class="h5">On Tue, 2011-08-16 at 10:43 -0700, Sam Leffler wrote:<br>
> On Mon, Aug 15, 2011 at 3:41 PM, Dan Williams <<a href="mailto:dcbw@redhat.com">dcbw@redhat.com</a>> wrote:<br>
> > On Fri, 2011-08-05 at 16:23 -0700, Gary Morain wrote:<br>
> >> In scan.c, merge a channel's noise value into the scan results. When comparing<br>
> >> scan results, compute the signal-to-noise ratio and use it when available.<br>
> >> Prefer a 5 GHz network if its SNR is really big (> 30) or if its SNR is<br>
> >> relatively close to the other network's.<br>
> ><br>
> > Honestly I'd rather have something like a "bands" option on a<br>
> > per-netblock basis, so you could do this:<br>
> ><br>
> > bands=5<br>
> > bands=5,2<br>
> > bands=2,5<br>
> > bands=2<br>
> ><br>
> > ie, the connection manager can set whichever band it prefers, or leave<br>
> > it out entirely to let the supplicant do whatever it's already doing.<br>
> > The problem with micro-optimizations like this are that they often<br>
> > break, and they aren't necessarily clear. I'd advocate for simpler,<br>
> > clearer rules here, with behavior set by the connection manager, rather<br>
> > than continually more complicated matching rules in the supplicant<br>
> > itself...<br>
><br>
> I'm trying to understand how this would be used. The point of Gary's<br>
> change is to prefer the 5GHz band only when two AP's have equivalent<br>
> signal quality. (5GHz is considered better because it has<br>
> non-overlapping channels, less likely to have interference, etc.)<br>
> This is meant to improve the algorithm by which a BSS is selected.<br>
<br>
</div></div>Yeah, I guess that's different than I'm proposing. But making this<br>
decision is still a policy decision that I'm not sure should be done in<br>
the supplicant.<br></blockquote><div><br></div><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: arial, sans-serif; font-size: 13px; background-color: rgb(255, 255, 255); "><div>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.</div>
<div><br></div><div>There are in fact two refinements in the CL.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>
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.</div></span></div></blockquote><div><br></div><div>I think we can agree that the overall goal here is to improve the probability that a typical user will experience excellent WiFi performance. In this light, I think it's hard to avoid the fact that some kind of 5 GHz preference is going to benefit performance for the typical user. I realize that any preference for the 5 GHz band will create some edge cases where a user might experience decreased performance ("cost"), but I see this as an issue of balancing the cost/benefit ratio.</div><div><br></div><div>I would suggest that we step back and take some time to devise an actually intelligent algorithm for 5 GHz preference. Done properly, this should significantly minimize the number of cases where typical users will experience decreased performance, while maximizing the potential benefit. There are some very important considerations in devising this algorithm:</div><div><br></div><div>* SNR is a very poor metric. There's no way to reasonably model a relationship between SNR and data rate, with varying channel widths and bands. SNR has to be used, at best, as a very limited heuristic in the decision making process.</div><div><br></div><div>* Channel widths are a huge consideration. 40 MHz channel widths in the 5 GHz band are common, while relatively rare in the 2.4 GHz band. </div><div><br></div><div>* Using actual rate selection data might be a good consideration. This is a far better measure that accounts for both channel width and SNR.</div><div><br></div><div>It seems like a good approach to this issue would be to "try" the 5 GHz network first if the SNR is anywhere near sane, measure the data rate, and then jump to the 2.4 GHz network if the data rate is proving too low. Given the typical 40 MHz at 5 GHz / 20 MHz at 2.4 GHz scenario, it is possible to use any of the 16-QAM data rates on the 5 GHz band and get throughputs greater than all but the highest data rates on the 40 MHz channel. It is even possible for the 40 MHz channel to have an inferior SNR and achieve superior throughput simply because of the channel width - remember that the noisy channel coding theorem dictates the relationship between bitrate and SNR, and the relationship is exponential, not linear, thus higher bitrates require a significantly better SNR than lower bitrates.</div><div><br></div><div><div>In my experiences deploying WiFi networks, I've never seen a WiFi client where the 5 GHz band preference has been too strong. For example, Apple has implemented a preference for the 5 GHz networks and even with those settings, and even increased the strength of this preference in later releases of their OS, yet I still find lots of real-world situations with WiFi deployments where I split the networks into 5 GHz and 2.4 GHz SSIDs so I can force clients onto the 5 GHz because the built-in preference for 5 GHz is not strong enough.</div><div><br></div><div>I also believe that facilitating a robust 5 GHz preference is good practice for the larger community. By supporting 5 GHz properly (and by default) we can help support the wider deployment of dual-band WiFi networks, which will be a big win for everybody.</div></div><div><br></div><blockquote type="cite"><div class="gmail_quote"><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: arial, sans-serif; font-size: 13px; background-color: rgb(255, 255, 255); ">Can we get agreement on this?</span> <blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">
<div class="im"><br>
> Also, specifying a preference on a per-netblock basis seems odd; when<br>
> would you want to control band preferences only for a specific SSID?<br>
<br>
</div>I've had this request come up periodically. If your institution uses<br>
the same SSID between the 5GHz and 2.4GHz wifi networks, but you'd like<br>
to always be on the 5GHz segment because it's less loaded. But other<br>
places you may not want to be on the 5GHz network. It really is a<br>
per-SSID (ie per network) preference.<br>
<div class="im"><br>
> You can lock down a netblock using bssid= and assign priority though<br>
> it might be painful to list all the AP's in an ESS. If we really want<br>
> to add this complexity it seems like it belongs per-interface or<br>
> global (or at compile-time).<br>
<br>
</div>I disagree. It's not global to the entire decision, it's specific to<br>
the netblock. You may not always want to prefer 5GHz networks<br>
everywhere you are. The problem with the freq= parameter is that to<br>
achieve this behavior you'd have to list *all* the frequencies in the<br>
5GHz and 2.4GHz range, while using bssid= is a no-go because the<br>
situation where you want this behavior is one where there are a ton of<br>
APs around.<br>
<span class="HOEnZb"><font color="#888888"><br>
Dan<br><br></font></span></blockquote></div></blockquote></div></body></html>