Re: [PATCH] supplicant: Tune auto-roaming based on scan results, allow configuring thresholds.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 01/02/2020 12:38 AM, Jouni Malinen wrote:
On Fri, Mar 29, 2019 at 11:31:27AM -0700, greearb@xxxxxxxxxxxxxxx wrote:
While trying to force an .11r roam, I noticed that when I scanned, the station
went back to the original AP.  The RSSI was around -25 for one and -35 for
the other, but the RSSI threshold was 5, so it flipped.

I believe that the performance difference between RSSI 25 and 35 is negligible,
so I modified the algorithm to basically not auto-roam if both signals are
good.  I'm not certain my new automatic thresholds are perfect, so maybe
they need more tuning.  At the least, we should not auto roam between an RSSI 25
and RSSI 35 AP based on RSSI.

And, allow user overrides in case we want the thresholds even higher.

In addition, add a note regarding the estimated bandwidth calculation,
as it does not appear to take NSS into account.

I don't want to expose this type of very specific parameters in
configuration file since this can result in expectation of those values
being maintained in the future and that resulting in additional
constraints on the implementation. If something needs to be
configurable, I'd prefer to consider some higher level value to indicate
how aggressive roaming should be and then automatically convert from
that to internal parameters for the algorithm so that the design can be
changed without having to touch the definition of the configuration
parameter.

I'm guessing the vast majority of users never touch the config file
themselves...it is auto-generated by something at a higher level.  Maybe
let the higher level thing deal with the simplified setting value
and let it tune the more specific values in supplicant?


diff --git a/wpa_supplicant/events.c b/wpa_supplicant/events.c
@@ -1778,8 +1784,17 @@ static int wpa_supplicant_need_to_roam(struct wpa_supplicant *wpa_s,
 			min_diff = 3;
 		else if (current_bss->level < -70)
 			min_diff = 4;
-		else
+		else if (current_bss->level < -60)
 			min_diff = 5;
+		else if (current_bss->level < -50)
+			min_diff = 8;
+		else if (current_bss->level < -40)
+			min_diff = 10;
+		else if (current_bss->level < -30)
+			min_diff = 20;
+		else
+			min_diff = 30;

I'm not sure this is really needed. There is now a cur_snr > GREAT_SNR
check that will in practice skip roaming in cases where the signal level
from the current BSS is sufficiently good.

Based on my current understanding of things, I'd change the logic above
to keep the min_diff larger even at very weak signals since roaming is so
disruptive to user experience, and RSSI is likely to
fluctuate more than a few db.

Does the current code keep the station from roaming back and forth when there
are two APs at about -70?

Thanks,
Ben


diff --git a/wpa_supplicant/scan.c b/wpa_supplicant/scan.c
@@ -2383,6 +2383,7 @@ void scan_est_throughput(struct wpa_supplicant *wpa_s,
+	/* TODO: Take number of spatial streams into account */
 	/* TODO: channel utilization and AP load (e.g., from AP Beacon) */

I contribution to add such functionality and updates for HE related
items in this area would be welcome..


--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc  http://www.candelatech.com

_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap



[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux