Thanks for the modifications. Most of the changes were just reasoned
about e.g. we don't necessarily want to roam to an AP with est.
throughput 5k higher because that's often not a significant
difference. Take 138000 to 143000 for example.
In any case, I don't have hard evidence that either version of the
patch is better than the other, but I'll submit another patch if
something comes up.
On Thu, Jan 2, 2020 at 12:32 AM Jouni Malinen <j@xxxxx> wrote:
>
> 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
