[PATCH] wpa_supplicant: Prefer 5 GHz networks over 2.4 GHz networks.

[Jouni Malinen]

On Fri, Aug 05, 2011 at 04:23:12PM -0700, Gary Morain wrote:
> In scan.c, merge a channel's noise value into the scan results.  When comparing
> scan results, compute the signal-to-noise ratio and use it when available.
> Prefer a 5 GHz network if its SNR is really big (> 30) or if its SNR is
> relatively close to the other network's.

Thanks! Applied with some changes.

I agree that it is useful to do this type of increased preference for 5
GHz networks in practice regardless of how other areas mentioned in this
thread for configuring behavior etc. are addressed.

I managed to get to a 2.4 GHz network couple of times in my test setup
(three dualband concurrent APs around the house), but 5 GHz band was
selected most of the time. That 2.4 GHz selection could have been
avoided by a bit smaller GREAT_SNR value (I think I was seeing something
like 26 or so at that point), but there keeping this a bit more on the
conservative side seems reasonable as long as we do not use more
complete information like whether HT is used and whether it is 20/40 MHz
BSS.

By the way, it could be nice to extend this type of use of SNR to
wpa_supplicant_need_to_roam() and to the partial scan reporting that has
been discussed on linux-wireless to allow reminder of the scan to be
skipped if a "good enough" AP is found.

> diff --git a/src/drivers/driver.h b/src/drivers/driver.h
>  	/**
> +	 * get_noise_for_scan_results - Sets the 'noise' field of struct
> +	 * wpa_scan_res
> +	 * @priv: private driver interface data
> +	 * @scan_results: Can results obtained through get_scan_results2.
> +	 *
> +	 * This function gets the survey results from the driver.  For each
> +	 * frequency in the scan results, the noise is updated if the survey
> +	 * results have a noise value for that frequency.
> +	 *
> +	 * Returns: 0 on success. -1 on failure.
> +	 */
> +	int (*get_noise_for_scan_results)(void *priv,
> +					  struct wpa_scan_results *scan_results);

This sounds unnecessary as a separate driver_ops and I dropped it and
just made driver_nl80211.c do this automatically whenever
get_scan_results2() handler is called.

> diff --git a/wpa_supplicant/scan.c b/wpa_supplicant/scan.c
> @@ -711,23 +715,36 @@ static int wpa_scan_result_compar(const void *a, const void *b)
> -	/* best/max rate preferred if signal level close enough XXX */
> -	if ((wa->level && wb->level && abs(wb->level - wa->level) < 5) ||
> +	snr_a = MIN(wa->level - wa->noise, GREAT_SNR);
> +	snr_b = MIN(wb->level - wb->noise, GREAT_SNR);

I changed this to be a bit more careful on when to use the SNR option..
If the driver claims that the noise value is not valid or if the level
value is not in dBm, it sounds like a better idea not to do this. Some
drivers are actually reported wa->level values like 160 or so and this
GREAT_SNR limit would make them pretty strange results here..

> +        wpa_printf(MSG_DEBUG, "Channel a: freq:%d level:%d noise:%d snr:%d",
> +		   wa->freq, wa->level, wa->noise, snr_a);
> +        wpa_printf(MSG_DEBUG, "Channel b: freq:%d level:%d noise:%d snr:%d",
> +		   wb->freq, wb->level, wb->noise, snr_b);

These are at way to high debut level priority. In addition, interim
results from qsort are not really that helpful and even if it is O(n log
n) algorithm on average, this dumps way too much data in areas where
there is a large number of APs.

> +/*
> + * Channels with a great SNR can operate at full rate.  What is a great SNR?
> + * This doc https://supportforums.cisco.com/docs/DOC-12954 says, "the general
> + * rule of thumb is that any SNR above 20 is good."  This one
> + * http://www.cisco.com/en/US/tech/tk722/tk809/technologies_q_and_a_item09186a00805e9a96.shtml#qa23
> + * recommends 25 as a minimum SNR for 54 Mbps data rate.  30 is chosen here as a
> + * conservative value.
> + */
> +#define GREAT_SNR 30

It should be noted that HT at higher MCS indexes (especially if multiple
streams are used) will require quite a bit higher SNR than legacy 54
Mbps rate. Anyway, 30 sounds like a fair value for now.

-- 
Jouni Malinen                                            PGP id EFC895FA