From: James Prestwood <prestwoj@gmail.com>
To: Denis Kenzior <denkenz@gmail.com>,
Simonas Kazlauskas <iwd.lists.linux.dev@kazlauskas.me>
Cc: iwd@lists.linux.dev
Subject: Re: Is the data rate estimation for 5GHz channels overly pessimistic?
Date: Tue, 24 Oct 2023 08:06:46 -0700 [thread overview]
Message-ID: <8a9039e3-1db3-459f-874b-e53d8dcdc16d@gmail.com> (raw)
In-Reply-To: <3d2c3d76-e08c-4d71-8a72-7193dd51cbfc@gmail.com>
Hi Simonas,
On 10/24/23 7:26 AM, Denis Kenzior wrote:
> 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.
I shouldn't have said impossible, just quite an undertaking. It would
rely near 100% on community support to add various cards, in addition to
the "hwdb" framework being committed to the project. But we're open to
contributions!
>
>>
>> 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.
The rates/MCS table (ht_vht_rates) is from 802.11, but the mapping from
RSSI to MCS index's (ht_vht_he_base_rssi) is not. The spec just has a
formula for calculating the rate using a given MCS/channel width. IWD
just chooses what it thinks the MCS will be for a given RSSI.
I don't remember exactly where I got those values from but this seems to
match:
https://wlanprofessionals.com/mcs-table-and-how-to-use-it/
So ultimately its a bit "hand-wavy" but so far has served us pretty
well. Whats happening in your case is the RSSI is below the lowest
threshold so its not calculating a rate for HT/VHT/HE (at least I think
thats whats happening). So my idea is we just force it to use the lowest
MCS if some threshold is set. That will calculate _something_ at least
rather than failing.
>
>>
>> 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
next prev parent reply other threads:[~2023-10-24 15:06 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-14 9:23 Is the data rate estimation for 5GHz channels overly pessimistic? Simonas Kazlauskas
2023-10-14 16:02 ` James Prestwood
2023-10-14 17:36 ` Denis Kenzior
2023-10-14 17:45 ` Simonas Kazlauskas
2023-10-14 18:07 ` Denis Kenzior
2023-10-15 19:40 ` Simonas Kazlauskas
2023-10-16 11:35 ` James Prestwood
2023-10-16 12:38 ` James Prestwood
2023-10-16 19:12 ` Denis Kenzior
2023-10-16 20:20 ` Simonas Kazlauskas
2023-10-21 23:23 ` Simonas Kazlauskas
2023-10-22 20:14 ` Denis Kenzior
2023-10-24 12:32 ` James Prestwood
2023-10-24 14:26 ` Denis Kenzior
2023-10-24 15:06 ` James Prestwood [this message]
2023-10-24 15:32 ` Denis Kenzior
2023-10-24 15:40 ` James Prestwood
2023-10-24 15:19 ` Simonas Kazlauskas
2023-10-24 15:29 ` Denis Kenzior
2023-10-16 18:36 ` Denis Kenzior
2023-10-14 17:42 ` Simonas Kazlauskas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8a9039e3-1db3-459f-874b-e53d8dcdc16d@gmail.com \
--to=prestwoj@gmail.com \
--cc=denkenz@gmail.com \
--cc=iwd.lists.linux.dev@kazlauskas.me \
--cc=iwd@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.