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

[Denis Kenzior <denkenz@gmail.com>]

Hi James,

On 10/24/23 07:32, James Prestwood wrote:
> Hi Denis/Simonas,
> 
>>
>> Now the question is, how do we make sure iwd is estimating the HE rate if 
>> available?  Also, how do we tweak the estimation logic with sensitivity 
>> numbers (obtained from a spec sheet, or through experimentation) for specific 
>> hardware being used.
> 
> Trying to catalog different hardware performance and act on it for ranking is an 
> impossible task :)

We can actually have our own hwdb of sorts for this.  Hardware sensitivity is a 
differentiator (think marketing), so should be fairly easy to find.  Also, it 
doesn't have to be absolutely perfect, just reflect the hw capability a bit more 
closely.

> 
> The only simple solution I can think of would be to add a user-option for some 
> threshold RSSI in the rate calculation. If set and the RSSI is below the lowest 
> of ht_vht_he_base_rssi just use the last index (-82) (and maybe force a 20MHz 
> channel width?). This would at least let the rate logic return _something_, 
> albeit maybe not accurate. But again, those RSSI thresholds were sorta made up 
> anyways :)

They are not made up, they're direct from 802.11.  But again, they're the 
_minimum_ specified sensitivity.  Hardware typically does better.

> 
> 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

Regards,
-Denis