On Tue, Jul 17, 2018 at 10:56:21AM -0700, Matthew Wang wrote:
> Currently, wpa_supplicant roams too aggressively; the need_to_roam()
> function will return early with a roaming decision if the difference
> in signal level or throughput between the current and selected APs
> is "sufficiently large." In particular, if the selected AP's
> estimated throughput is more than 5k greater than the current AP's
> estimated throughput, supplicant will decide to roam. Otherwise, if
> the selected AP's signal level is less than the current AP's signal
> level, or the selected AP's estimated throughput is at least 5k
> less than the current AP's estimated throughput, supplicant will
> skip the roam. These decisions are based only on one factor and can
> lead to poor roaming choices (e.g. a roam should not happen if the
> selected AP's estimated througput meets the threshold but the
> current signal and throughput are already good, whereas a roam
> should happen if the signal is slightly worse but the estimated
> throughput is significantly better).
>
> This change standardizes the roaming heuristic and will hopefully
> improve user WiFi experience. The change can be summarized as
> follows: based on the current signal level, a certain roaming
> difficulty is assigned. Based on the selected AP's estimated
> throughput relative to the current AP's estimated throughput, the
> difficulty is adjusted up or down. If the difference in signal
> level meets the threshold, a roam happens.
>
> The hard-coded values were selected purely based on the previous
> version of this function. They may eventually need to be fine-tuned
> for optimal performance.
Thanks. I applied some parts of this, but for others, I'd like to see
more justification for the change, e.g., in a form of a debug log
showing undesired roaming behavior.
> diff --git a/wpa_supplicant/events.c b/wpa_supplicant/events.c
> @@ -1683,27 +1683,8 @@ static int wpa_supplicant_need_to_roam(struct wpa_supplicant *wpa_s,
> - if (selected->est_throughput > current_bss->est_throughput + 5000) {
> - wpa_dbg(wpa_s, MSG_DEBUG,
> - "Allow reassociation - selected BSS has better estimated throughput");
> - return 1;
> - }
I did not apply this one and this seems to be against the first part of
the commit message as well, i.e., the roam should be allowed with worse
signal strength if these is a significant improvement to the estimated
throughput. It should also be noted that the estimated throughput values
are not based on a single factor.
> - if (current_bss->level < 0 &&
> - current_bss->level > selected->level + to_5ghz * 2) {
> - wpa_dbg(wpa_s, MSG_DEBUG, "Skip roam - Current BSS has better "
> - "signal level");
> - return 0;
> - }
I did not remove this condition completely, but I did change this to not
apply if there is a significant improvement in the estimated throughput.
> - if (current_bss->est_throughput > selected->est_throughput + 5000) {
> - wpa_dbg(wpa_s, MSG_DEBUG,
> - "Skip roam - Current BSS has better estimated throughput");
> - return 0;
> - }
I did not remove this either. It does not sound reasonable to roam to a
BSS that is estimated to result in worse throughput.
The exact definition of what exactly is significantly improve throughput
is likely worth additional consideration, though, since the current
implementation (5 kbps difference or 20% improvement) is not really
based on any real study.
--
Jouni Malinen PGP id EFC895FA
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
