Patchwork Prefer 5 GHz channels more aggressively?

login
register
mail settings
Submitter Lukas Ribisch
Date June 4, 2014, 1:52 p.m.
Message ID <20140604135252.GB33679@ZEDAT.FU-Berlin.DE>
Download mbox | patch
Permalink /patch/355986/
State New
Headers show

Comments

Lukas Ribisch - June 4, 2014, 1:52 p.m.
Hello,

I'm using wpa_supplicant to connect to my university's campus network.
Our access points use BSSIDs on both 2,4 GHz and 5 GHz; obviously, the 5
GHz APs are far less crowded and susceptible to interference than the
2,4 GHz ones. Additionally, we are now deploying 802.11ac, but only on 5
GHz.

Unfortunately, it seems that wpa_supplicant's heuristic to select the
best BSSID almost exclusively prefers the access points on 2,4 GHz,
because their RSSI is almost always a bit better than the 5 GHz one.
I've compared this to other operating systems (on the same as well as on
different machines); the other drivers seem to prefer 5 GHz APs in a lot
more cases than wpa_supplicant.

I've located the code responsible for selecting the best AP, and
modified the maximum difference in RSSI for a 5 GHz AP to still be
preferred over a 2,4 GHz one from 5 dBm to 30 dBm, but only if the RSSI
is not lower than -85 dBm. (By the way: Should that actually be -85 in
the code in order to do what I want?) I've attached the patch; it has
worked very well for me in the past few days, and my laptop now
consistenly attaches to the 5 GHz APs, which increases the quality and
the data rate of the connection, for the new 802.11ac APs as well as for
the old a/g devices.

Of course, the threshold of -85 dBm is quite arbitrary (it is the level
at which my specific 802.11 device starts becoming unreliable), but I
suspect that a larger allowable difference in RSSI between 2,4 GHz and 5
GHz would allow many more clients to use the better 5 GHz network.

What are your opinions on changing the hardcoded limit from 5 dBm to
something like 20-30 dBm, possibly capped at some conservative value
like -50 to -60 dBm? Or is this something that should be configurable?

Thanks,
Lukas Ribisch
Ed W - June 6, 2014, 9:09 a.m.
On 04/06/2014 14:52, Lukas Ribisch wrote:
> Hello,
>
> I'm using wpa_supplicant to connect to my university's campus network.
> Our access points use BSSIDs on both 2,4 GHz and 5 GHz; obviously, the 5
> GHz APs are far less crowded and susceptible to interference than the
> 2,4 GHz ones. Additionally, we are now deploying 802.11ac, but only on 5
> GHz.
>
> Unfortunately, it seems that wpa_supplicant's heuristic to select the
> best BSSID almost exclusively prefers the access points on 2,4 GHz,
> because their RSSI is almost always a bit better than the 5 GHz one.
> I've compared this to other operating systems (on the same as well as on
> different machines); the other drivers seem to prefer 5 GHz APs in a lot
> more cases than wpa_supplicant.
>
> I've located the code responsible for selecting the best AP, and
> modified the maximum difference in RSSI for a 5 GHz AP to still be
> preferred over a 2,4 GHz one from 5 dBm to 30 dBm, but only if the RSSI
> is not lower than -85 dBm. (By the way: Should that actually be -85 in
> the code in order to do what I want?) I've attached the patch; it has
> worked very well for me in the past few days, and my laptop now
> consistenly attaches to the 5 GHz APs, which increases the quality and
> the data rate of the connection, for the new 802.11ac APs as well as for
> the old a/g devices.
>
> Of course, the threshold of -85 dBm is quite arbitrary (it is the level
> at which my specific 802.11 device starts becoming unreliable), but I
> suspect that a larger allowable difference in RSSI between 2,4 GHz and 5
> GHz would allow many more clients to use the better 5 GHz network.
>
> What are your opinions on changing the hardcoded limit from 5 dBm to
> something like 20-30 dBm, possibly capped at some conservative value
> like -50 to -60 dBm? Or is this something that should be configurable?

I think the heuristic should be along the lines of:

- Estimate the speed/throughput of the various radio channels at the 
different signal levels
- That heuristic would ideally be based on device characteristics, how 
congested each channel is, etc
- For now that heuristic could be as simple as you describe, eg
     throughput_on_5ghz = (signal > -85db) ? lots_and_lots : 0

This then gives you a framework to do more in the future, eg 
distinguishing between 802.11ac and 802.11N on the 5Ghz.  At least for 
2.4Ghz cards, their performance is fairly tightly linked to the signal 
level (sure there is some 2-5 db variance between cards, but they seem 
to fairly closely cluster).  I guess it might even be possible to 
eventually consider channel congestion, etc...

I agree that any simple heuristic would be better for now, but I think 
break it out and call it what it is, even if it's just a simple level test?

Ed

Patch

Index: wpa-2.1/wpa_supplicant/scan.c
===================================================================
--- wpa-2.1.orig/wpa_supplicant/scan.c	2014-02-04 12:23:35.000000000 +0100
+++ wpa-2.1/wpa_supplicant/scan.c	2014-06-02 19:32:29.311056818 +0200
@@ -1411,6 +1411,7 @@ 
 {
 #define IS_5GHZ(n) (n > 4000)
 #define MIN(a,b) a < b ? a : b
+#define MAX(a,b) a > b ? a : b
 	struct wpa_scan_res **_wa = (void *) a;
 	struct wpa_scan_res **_wb = (void *) b;
 	struct wpa_scan_res *wa = *_wa;
@@ -1448,7 +1449,7 @@ 
 	}
 
 	/* best/max rate preferred if SNR close enough */
-        if ((snr_a && snr_b && abs(snr_b - snr_a) < 5) ||
+        if ((snr_a && snr_b && MAX(snr_a, snr_b) < 85 && abs(snr_b - snr_a) < 30) ||
 	    (wa->qual && wb->qual && abs(wb->qual - wa->qual) < 10)) {
 		maxrate_a = wpa_scan_get_max_rate(wa);
 		maxrate_b = wpa_scan_get_max_rate(wb);
@@ -1467,6 +1468,7 @@ 
 		return wb->qual - wa->qual;
 	return snr_b - snr_a;
 #undef MIN
+#undef MAX
 #undef IS_5GHZ
 }