Re: [PATCH RFC 3/3] station: improve roam scan strategy

[Alexander Ganslandt <alexander.ganslandt@axis.com>]

Hello James and Denis,

Thank you both for the feedback! I want to focus on the overall idea 
here and will look at the code details later.

On 4/16/25 18:46, James Prestwood wrote:
 > Won't this start reusing the same frequencies after a few scans? Say
 > your first N scans take more than 3 seconds, you'd then begin using
 > those frequencies again on subsequent scans since their ages are under
 > the threshold?
 >
 > Rather than a hard threshold simply sorting by age seems like the best
 > way to do this:
 >
 >   - Sort the frequencies by least recently used -> Take the first N
 > frequencies -> Scan
 >   - No candidates found? -> Repeat ^^^

Yes, it will start reusing frequencies and might never reach the less 
common frequencies depending on how long time the scans take. That's 
definitely not ideal. Looking at the age as you suggest has the problem 
that it will eventually spend time scanning uncommon frequencies when 
that time would have been better spent scanning common frequencies that 
are getting old.

Maybe this is an impossible task to solve perfectly as there will always 
be a trade-off, maybe it's better left as configs for the user? In my 
livestream use case the APs should be configured such that most good 
frequencies are in "neighbor" or "known", so I would like to spend most 
time on these frequencies. However, for a use case where the network 
setup is unknown, having more exploration of uncommon frequencies might 
be better.

We could have configs instead where users can define the subsets and age 
threshold. If they don't set anything, the default is the current 
behavior. If they set subsets, the roaming algorithm will pick 
frequencies from those in the prioritized order, just like this patch 
does. It could still get stuck scanning the same frequencies if the age 
threshold is too low, but then it would be a user configuration error. 
We then also get rid of hard-coding frequencies in IWD and all problems 
that causes, but still give users the possibility to do so if needed. 
Does this make more sense?

On 4/16/25 19:19, Denis Kenzior wrote:
> Have you considered maintaining a scan_freq_set of all the frequencies 
> scanned
> by the neighbor and known-frequency stages instead of maintaining an 
> hashtable
> based on age?

I don't completely follow what you mean here. The reason for having the 
hashtable is to know how long ago a certain frequency was scanned in 
order to not scan it again too soon. So that info will have to be stored 
somehow, or did you have some other approach in mind?

> So the idea is to add up to STATION_MAX_SCAN_FREQS to a new set, 
> starting in
> order of preference with:
>         1. neighbor frequency set
>         2. known network set
>         3. scan frequency ordering set
> 
> while filtering the frequencies already scanned.
> 
> How do you know when to give up the current attempt?

Yes, correct. Do you mean when to give up on the roaming attempt 
completely? The current approach is to never give up, it will continue 
scanning frequencies in the subsets until it finds a better BSS, or 
until the current BSS signal goes above the threshold and roaming stops. 
I believe this is also what IWD does today, except it uses full scans 
continuously.

Regards,
Alexander