<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">&lt;<a href="mailto:dcbw@redhat.com">dcbw@redhat.com</a>&gt;</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>
&gt; On Mon, Aug 15, 2011 at 3:41 PM, Dan Williams &lt;<a href="mailto:dcbw@redhat.com">dcbw@redhat.com</a>&gt; wrote:<br>
&gt; &gt; On Fri, 2011-08-05 at 16:23 -0700, Gary Morain wrote:<br>
&gt; &gt;&gt; In scan.c, merge a channel&#39;s noise value into the scan results.  When comparing<br>
&gt; &gt;&gt; scan results, compute the signal-to-noise ratio and use it when available.<br>
&gt; &gt;&gt; Prefer a 5 GHz network if its SNR is really big (&gt; 30) or if its SNR is<br>
&gt; &gt;&gt; relatively close to the other network&#39;s.<br>
&gt; &gt;<br>
&gt; &gt; Honestly I&#39;d rather have something like a &quot;bands&quot; option on a<br>
&gt; &gt; per-netblock basis, so you could do this:<br>
&gt; &gt;<br>
&gt; &gt; bands=5<br>
&gt; &gt; bands=5,2<br>
&gt; &gt; bands=2,5<br>
&gt; &gt; bands=2<br>
&gt; &gt;<br>
&gt; &gt; ie, the connection manager can set whichever band it prefers, or leave<br>
&gt; &gt; it out entirely to let the supplicant do whatever it&#39;s already doing.<br>
&gt; &gt; The problem with micro-optimizations like this are that they often<br>
&gt; &gt; break, and they aren&#39;t necessarily clear.  I&#39;d advocate for simpler,<br>
&gt; &gt; clearer rules here, with behavior set by the connection manager, rather<br>
&gt; &gt; than continually more complicated matching rules in the supplicant<br>
&gt; &gt; itself...<br>
&gt;<br>
&gt; I&#39;m trying to understand how this would be used.  The point of Gary&#39;s<br>
&gt; change is to prefer the 5GHz band only when two AP&#39;s have equivalent<br>
&gt; signal quality. (5GHz is considered better because it has<br>
&gt; non-overlapping channels, less likely to have interference, etc.)<br>
&gt; This is meant to improve the algorithm by which a BSS is selected.<br>
<br>
</div></div>Yeah, I guess that&#39;s different than I&#39;m proposing.  But making this<br>
decision is still a policy decision that I&#39;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&#39;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><div><br></div>
</span><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); ">Can we get agreement on this?</span> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im"><br>
&gt; Also, specifying a preference on a per-netblock basis seems odd; when<br>
&gt; would you want to control band preferences only for a specific SSID?<br>
<br>
</div>I&#39;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&#39;d like<br>
to always be on the 5GHz segment because it&#39;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>
&gt; You can lock down a netblock using bssid= and assign priority though<br>
&gt; it might be painful to list all the AP&#39;s in an ESS.  If we really want<br>
&gt; to add this complexity it seems like it belongs per-interface or<br>
&gt; global (or at compile-time).<br>
<br>
</div>I disagree.  It&#39;s not global to the entire decision, it&#39;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&#39;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><br>