Re: [PATCH 2/6] Rewrite roaming logic

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

 



On Tue, Jun 23, 2020 at 02:41:19PM -0700, Matthew Wang wrote:
> Thanks for the response. I ran the prefer_ht20_during_roam test and it
> looks like it expects a roam from a non-HT AP at -30 dBm with 54 Mbps
> est_tpt to an HT AP at -30 dBm with 65 Mbps est_tpt. I'm not too clear
> on all the phy layer details of HT, but in my opinion, roaming from an
> AP at such a strong signal level (-30 dBm) needs a fairly strong
> justification, and a 20% increase (54 -> 65) in estimated throughput
> is not that strong. That being said, if there are benefits to moving
> from non-HT to HT that aren't captured in the {signal, est_tpt} pair,
> then I'd advocate for using a flag that behaves similarly to the
> to_{2,5}ghz flags, which adjusts the roaming difficulty up/down 2 dBm
> depending on the direction of the roam. We can assign some value for
> {to,from}_ht flags that subtracts from or adds to the roaming
> difficulty depending on how valuable HT vs non-HT is. Does this make
> sense?

That behavior is not limited to so high signal strength value. Same
happens with all other values and the impact is much more severe in some
cases. For example, with both APs at -86 dBm non-HT AP gets 2 Mbps
est_tpt and HT AP gets 8.666 Mbps. Still, roaming is prevented ("Skip
roam - too small difference in signal level (0 < 4)"). In other words,
even that min_diff -= 2 style adjustment that is given for to_5ghz would
not help here. In fact, it looks like this patch would make it
impossible to roam to an AP that shows better throughput estimate
(regardless of how large a difference) on the same band unless there is
also at least 4 dB increase in the signal level when cur_level < -85.
That does not look reasonable.

And yes, HT does come with possibility of using A-MPDU and A-MSDU
aggregation which can result in significant improvement in throughput
and airtime efficiency and that is in addition to the estimated
throughput values from TX rates. So it might indeed make sense to
add/subtract difficulty for roaming, but still, the main issue I see
here is in that behavior that seems to completely prevent roaming unless
signal level increases significantly regardless of other factors.

-- 
Jouni Malinen                                            PGP id EFC895FA

_______________________________________________
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