Re: Is the data rate estimation for 5GHz channels overly pessimistic?

[Denis Kenzior <denkenz@gmail.com>]

Hi Simonas,

On 10/24/23 10:19, Simonas Kazlauskas wrote:
> Denis Kenzior wrote:
>> On 10/24/23 07:32, James Prestwood wrote:
>>> So you could set:
>>> [Rank].LowSignalRateThreshold=-90
>>>
>>> Any RSSI between -82 and -90 would use -82 for the rank calculation. No idea 
>>> how this would play out in practice, but its at least simple and not tied to 
>>> any given hardware.
>>
>> No, I was more thinking about:
>> /* Added to the rssi value prior to looking up in the ht_vht_he_base_rssi */
>> SensitivityFudgeFactor=4
>> /* Width penalty */
>> SensitivityWidthPenalty=0 (3 today)
>> /* NSS penalty */
>> SensitivityNSSPenalty=3
>> /* Same as SensitivityFudgeFactor, but for HE */
>> SensitivityHEFudgeFactor=10
> 
> My main worry then would be finding good defaults for these values. Ultimately, 
> unless `iwd` ends up in a place where people install it and get a great 
> experience in anything that involves ranking (roaming, initial association, 
> etc.), the WiFi experience on Linux may have a hard time shaking off its stigma. 
> If many has to modify some config variables to get a good experience, the 
> experience will continue staying subpar for the large majority still. Although 
> having the knobs will at least enable a minority to extract a reasonably good 
> experience.

Well, WiFi on Linux is plain terrible.  iwd tries to make it better, but 
ultimately we're down to only two people.  There's only so much that can be 
done.  The goal here was to describe the parameters we could use to 'tweak' the 
current calculation.  These can then be stored per vid/pid/driver or whatever 
and added onto over time.  If the parameters are not provided, then fall back to 
the (very pessimistic) calculation we use now.  Still better than what we used 
to have.

> 
> What worries me in parituclar here is that if we tune these defaults too high 
> (i.e. estimate rate better than it might end up being in practice) then we might 
> end up associating with the AP that is too far away/weak to provide a 
> serviceable connection.
> 
> I wonder if there’s any place in here for some dynamic component that would 
> monitor how the NSS, MCS and other bandwidth affecting parameters behave for a 
> given SSID/BSSID/etc. as the RSSI varies, and transparently learn these 
> parameters throughout a… session (is that a term?) That way even if the 
> estimation for the very first association is too pessimistic, `iwd` can do 
> better when it needs to estimate again for e.g. a romaing decision or a new 
> association after a sleep.
> 
> With such a scheme in place “training” IWD would also be pretty easy to explain 
> to the users (walk around the area with your device connected to the network) if 
> they encountered problems with a particular AP.
> 

Patches are always welcome.  ML isn't my area of expertise, so I can't really 
help here.

Regards,
-Denis