From: Simonas Kazlauskas <iwd.lists.linux.dev@kazlauskas.me>
To: James Prestwood <prestwoj@gmail.com>
Cc: iwd@lists.linux.dev, Denis Kenzior <denkenz@gmail.com>
Subject: Re: Is the data rate estimation for 5GHz channels overly pessimistic?
Date: Sun, 22 Oct 2023 02:23:32 +0300 [thread overview]
Message-ID: <sebayhpora5e5ispmp5nnjesihoewc74ohygd3orxp7k22ky4c@tt225sdpjrxm> (raw)
In-Reply-To: <ncmtsi42vkdimzxsuktgfblp66agskivhuntdjlooyp7gglhgo@kwuxknllo527>
[-- Attachment #1: Type: text/plain, Size: 3107 bytes --]
Hey,
I finally got around to figuring out the test specifications (I think.) At least
the test results I’m seeing are the same as the output from `iwd -d`.
See the attached patch (feel free to merge it, or not to merge it – entirely up
to you.)
72Mbps appears to be coming from the table for 80MHz rates (NSS=2 so 36MHz in
the table itself), but this *should* be a 40MHz ordeal. My APs are set up for
40MHz 5GHz channels and 160MHz 6GHz channels, but it seems like it might still
be sending capabilities that include 80MHz support…? Weird.
[1]: https://semfionetworks.com/blog/mcs-table-updated-with-80211ax-data-rates/
Anyhow, besides the 80MHz weirdness, this all seems to ultimately come down to
the `ht_vht_he_base_rssi` table (as you both have pointed out in the very
beginning!) After the `width_adjust` in `band_he_rate` is applied, -76dBm is the
bare minimum for it to pick out even the lowest 36MHz rate from the 80MHz table.
Meanwhile in practice I’m getting MCS anywhere from 4 to 10 (seems to be fairly
random regardless of the signal strength, which varies between -72dBm and -79dBm
this particular evening.) The only caveat is that for very high MCS values (8,
9, 10), NSS appears to drop down to 1 (thus making them roughly equivalent to
MCS 4-to-5).
I’m not sure if this stellar MCS behaviour is Ubiquiti’s doing something fancy,
or if its a result of those aforementioned thick walls, which *also* happen to
block out any interference from the neighbours as well (making my APs literally
the only transmitter in the 5GHz band devices bother noticing…)
I have no clue if there’s anything actionable here, but I’m happy to help with
testing the observed behaviour at various signal strengths if coming up with a
better `ht_vht_he_base_rssi` table is… on the table :)
Have a great weekend,
S.
Simonas Kazlauskas wrote:
>James,
>
>Thank you for implementing the display of HE capabilities in `iwmon` –
>these do indeed show up in my scans now, false alert there.
>
>>HE Capabilities: len 34
>> HE supported channel width set: bit 1: 40MHz/80MHz supported (5GHz/6GHz)
>> Rx HE-MCS Map <= 80MHz 1 Streams: MCS 0-11 supported
>> Rx HE-MCS Map <= 80MHz 2 Streams: MCS 0-11 supported
>> Rx HE-MCS Map <= 80MHz 3 Streams: MCS 0-11 supported
>> Rx HE-MCS Map <= 80MHz 4 Streams: MCS 0-11 supported
>> Tx HE-MCS Map <= 80MHz 1 Streams: MCS 0-11 supported
>> Tx HE-MCS Map <= 80MHz 2 Streams: MCS 0-11 supported
>> Tx HE-MCS Map <= 80MHz 3 Streams: MCS 0-11 supported
>> Tx HE-MCS Map <= 80MHz 4 Streams: MCS 0-11 supported
>> 0d 01 08 9a 40 10 04 60 48 88 1f 43 81 1c 11 08 ....@..`H..C....
>> 00 aa ff aa ff 7b 1c c7 71 1c c7 71 1c c7 71 1c .....{..q..q..q.
>> c7 71 .q
>
>I’ve sent you and Denis both the pcap of the scan. I, unforunately,
>don’t think I’ll be able to hack on the test and/or data rate
>investigation much further before the weekend, but I’m happy to test
>out patches and such at any time.
>
>Thanks,
>S.
[-- Attachment #2: 0001-test-band-HE-band-test-with-real-world-capabilities.patch --]
[-- Type: text/plain, Size: 2590 bytes --]
From 6961629e93d9e74f5760c5be00393459ad55c0b5 Mon Sep 17 00:00:00 2001
From: Simonas Kazlauskas <git@kazlauskas.me>
Date: Sun, 22 Oct 2023 00:46:38 +0300
Subject: [PATCH] test-band: HE band test with real-world capabilities
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
I've been observing that the rate estimations in the real world usage
end up being quite a bit different from the rates that end up being used
after the association. In this commit I’m adding a test case with the
capabilities from two physical devices, if only to demonstrate the
how the rate estimation behaves in such circumstances.
---
unit/test-band.c | 29 ++++++++++++++++++++++++++++-
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/unit/test-band.c b/unit/test-band.c
index e27531f7..fec09e61 100644
--- a/unit/test-band.c
+++ b/unit/test-band.c
@@ -294,7 +294,7 @@ struct he_test_data {
/* Own capabilities */
struct band_he_capabilities capabilities;
/* Peer HE Capabilities IE */
- uint8_t he_capabilities[31];
+ uint8_t he_capabilities[36];
};
@@ -366,6 +366,31 @@ const struct he_test_data he_test_5_20mhz_mcs_7_nss_1 = {
},
};
+/* 5GHz, 40MHz With data from a real-world Unifi’s U6 Enterprise AP and a client
+ * with the Intel AX201 card.
+ */
+const struct he_test_data he_test_5_40mhz_unifi_ap_and_ax201 = {
+ .freq = BAND_FREQ_5_GHZ,
+ .rssi = -76,
+ // In practice seems to be more like 275_200_000ULL instead...
+ .expected_rate = 72000000ULL,
+ .capabilities = {
+ .he_mcs_set = {
+ HE_MCS_SET(MCS11, 2), HE_MCS_SET(MCS11, 1), MCS_UNSUP
+ },
+ .he_phy_capa = {
+ 0x0e, 0x3f, 0x0e, 0x09, 0xfd, 0x09, 0x8c, 0x16, 0x0f, 0xf0, 0x01
+ },
+ .iftypes = 1 << NETDEV_IFTYPE_STATION,
+ },
+ .he_capabilities = {
+ 0x22, IE_TYPE_HE_CAPABILITIES - 256,
+ 0x0d, 0x01, 0x08, 0x9a, 0x40, 0x10, 0x04, 0x60, 0x48, 0x88, 0x1f, 0x43,
+ 0x81, 0x1c, 0x11, 0x08, 0x00, 0xaa, 0xff, 0xaa, 0xff, 0x7b, 0x1c, 0xc7,
+ 0x71, 0x1c, 0xc7, 0x71, 0x1c, 0xc7, 0x71, 0x1c, 0xc7, 0x71,
+ },
+};
+
/* 5GHz, 80MHz, MCS 7, NSS 1 */
const struct he_test_data he_test_5_80mhz_mcs_7_nss_1 = {
.freq = BAND_FREQ_5_GHZ,
@@ -698,6 +723,8 @@ int main(int argc, char *argv[])
&he_all_mcs_unsupported);
l_test_add("/band/HE/test/low RSSI", band_test_he,
&he_test_5_low_rssi);
+ l_test_add("/band/HE/test/5GHz/40MHz/Unifi+AX201", band_test_he,
+ &he_test_5_40mhz_unifi_ap_and_ax201);
l_test_add("/band/oci2freq 1", test_oci2freq, &oci2freq_data_1);
l_test_add("/band/oci2freq 2", test_oci2freq, &oci2freq_data_2);
--
2.41.0
next prev parent reply other threads:[~2023-10-21 23:23 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 [this message]
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=sebayhpora5e5ispmp5nnjesihoewc74ohygd3orxp7k22ky4c@tt225sdpjrxm \
--to=iwd.lists.linux.dev@kazlauskas.me \
--cc=denkenz@gmail.com \
--cc=iwd@lists.linux.dev \
--cc=prestwoj@gmail.com \
/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.