From: James Prestwood <prestwoj@gmail.com>
To: Simonas Kazlauskas <iwd.lists.linux.dev@kazlauskas.me>,
Denis Kenzior <denkenz@gmail.com>
Cc: iwd@lists.linux.dev
Subject: Re: Is the data rate estimation for 5GHz channels overly pessimistic?
Date: Mon, 16 Oct 2023 04:35:20 -0700 [thread overview]
Message-ID: <f7ced477-6fa4-4efd-bf54-817b100041ef@gmail.com> (raw)
In-Reply-To: <tkizdohkwpz4nfgjczdzltr7qhvjtcyyk6x3543dht2gmm7ssc@q7m4rq3r3sqx>
Hi Somonas,
On 10/15/23 12:40 PM, Simonas Kazlauskas wrote:
> Hey,
>
> Denis Kenzior wrote:
>> It may be we screwed something up with HE since hardware was still
>> pretty rare when the feature was developed. But we do treat RSSI
>> values below -82 as almost unusable. Perhaps this needs to be tweaked
>> for newer hardware.
>>
>> If you want to get your hands dirty, it should be fairly easy to
>> modify unit/test-band.c to test what our estimate code does with your
>> specific circumstances.
>>
>> The local HE capabilities can be found via 'iw phy', looking at what
>> iwd prints at start, or using iwmon. Similarly, remote capabilities
>> can be sniffed using iwmon and running an iwd scan or 'iw scan trigger'.
>>
>> Me or James can walk you through all this if needed.
>
> Thanks for offering. I have cracked open the file, and just started
> playing around by adding a new `he_test_data` structure. Alas, I’m
> really hazy on what I ought to be filing into the `capabilities` and
> `he_capabilities` fields. My initial guess is something like this, based
> on one of the other tests around:
>
> +/* 5GHz, 40MHz, MCS 11, NSS 1 */
> +const struct he_test_data he_test_5_40mhz_mcs_5_nss_1 = {
> + .freq = BAND_FREQ_5_GHZ,
> + .rssi = -76,
> + .expected_rate = 275200000ULL,
> + .capabilities = {
> + .he_mcs_set = { HE_MCS_SET(MCS11, 1), MCS_UNSUP },
> + .he_phy_capa = { HE_PHY_CAPA(0x00) },
> + .iftypes = 1 << NETDEV_IFTYPE_STATION,
> + },
> + .he_capabilities = {
> + 22, IE_TYPE_HE_CAPABILITIES - 256, HE_MAC_CAPA,
> + HE_PHY_CAPA(0x00), MCS_UNSUP, HE_MCS_SET(MCS11, 1)
> + },
> +};
>
> This computes a rate of `25800000`, which I’m guessing corresponds to
> 25.8Mbps, perhaps? That’s fair I guess, since the only thing I really
> really changed in there compared to the other tests is the `MCS11`
> (that’s supported by AX201) and the `rssi`. There clearly are plenty of
> other fields that I should be filling in here, I feel, if I wanted to
> accurately represent my hardware.
>
> I think I managed to grab the capabilities of both the AP and the client
> using your instructions, but I’m really unclear on how to go from the
> output from `iwmon` to fields in this struct. My best guess right now is
> to actually run `iwd` under a gdb and place some breakpoints in the
> scanning code to extract the capabilities. Would that make sense, or is
> there a better way to fill in these fields?
>
> (As I’m writing this mail, I realize now that I probably want to somehow
> specify NSS=2 for `2x2` MIMO…?)
>
> Another thing that confuses me a great deal is the fact that the scan
> results with my APs don’t actually show any of the HE capabilities, only
> the HT and VHT ones (see attached sample from the `iwmon` output.) I
> also tried scanning an Android hotspot on a reasonably recent phone, and
> although the set of MCS supported were different, the output still
> contains only HT and VHT capabilities. I would love to attach my pcap
> here, but unfortunately I also have no clue how to sanitize it, so I’m
> going to attach an excerpt from `iwmon`’s output for the time being. Is
> this expected, or could this perhaps be at least part of the problem I’m
> seeing? Is it possible that an AP could not advertise HE capabilities at
> scan time, but for HE to still be used after authentication occurs?
Looks like iwmon doesn't actually print out the HE element, but that
doesn't explain the same behavior on the android device. If your more
comfortable you could send the pcap just to Me or Denis.
But as Denis pointed out maybe this needs another look as far as signal
strength any usability. The difficult part is one card could perform
much better at -85dbm than another. I'll take a closer look and see if
something got missed in the spec and do some testing myself (I think I
have an ax201, and definitely an ax210).
Thanks,
James
>
> Thank you,
> S.
next prev parent reply other threads:[~2023-10-16 11:35 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 [this message]
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
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=f7ced477-6fa4-4efd-bf54-817b100041ef@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.