From: Simonas Kazlauskas <iwd.lists.linux.dev@kazlauskas.me>
To: James Prestwood <prestwoj@gmail.com>
Cc: iwd@lists.linux.dev
Subject: Re: Is the data rate estimation for 5GHz channels overly pessimistic?
Date: Sat, 14 Oct 2023 20:42:12 +0300 [thread overview]
Message-ID: <bg4jb3gdt6xwuqxc2y2sbnaqs3ruh4mvavml5njyi66dvgsx7j@du4n43ujxerb> (raw)
In-Reply-To: <5780e1b2-8956-46bb-8116-b513cc564cea@gmail.com>
Hey,
James Prestwood wrote:
>Hi Simonas,
>
>The signal strength for the 5GHz BSS's are very low. Anything below -80dbm is
>_really_ bad. So it makes sense why IWD is choosing 2.4GHz instead. IWD's
>estimation is based on data from the 802.11 spec, and capabilities advertised
>by the APs.
The RSSI is an unfortunate combination of my walls being quite thick (and
really good at attenuating 5GHz), the AP being right across said wall and, I
believe, Ubiquiti’s automatic signal strength algorithm not picking the
maximum transmit strength[^1] in order to avoid the sticky client problem.
[^1]: At the maximum allowed 20dBm transmit power the AverageRSSI is -72dBm.
Is -80dBm really that bad? In my experience even -85dBm felt quite serviceable
in terms of speed and stability. Looking at Unifi’s own client diagnostics, I
see that the connection to the machine in question does have an increased “TX
Retries” metric at around 15%. But it is comparable to some other devices with
RSSIs in the neighbourhood of -70dBm and retries still at around 13%, so I'm
not quite sure if I should be paying much of my attention to that metric.
I unfortunately am not able to add more APs without tearing down the ceiling,
and my experience with -80dBm really didn’t feel bad enough to justify maxing
out the transmit power and thus incapacitating roaming elsewhere.
>Band steering should be done after authentication. APs shouldn't refuse
>connections like that, otherwise what would be the point of having a 2.4GHz
>network anyways if its impossible to connect to. Something else must be going
>on here.
Got it, I’ll investigate the authentication failures further. Though any
suggestions on what I should be looking at would be appreciated, as the only
idea I have right now is to disable band steering and see if the
authentication failures in the 2.4GHz band go away.
>This is probably because IWD doesn't take into account any of the newer
>802.11ax IEs when estimating the data rate. So its estimation is based on VHT
>and not the newest EHT rates.
Is taking into account the EHT rates something that *should* be implemented,
or is this something that cannot be implemented (and thus this misestimation
cannot be fixed?) I could dedicate some effort implementing this if its the
former (though, again, any links to relevant resources or docs would be
greatly appreciated to save me the effort looking for good ones myself, if you
have any on hand.) If it is the latter, I would love to learn more about why
that’s the case.
>Since the 2.4GHz BSS's are giving you such problems you could try a recently
>added feature to disable the 2.4GHz band entirely. You can set
>[Rank].BandModifier2_4Ghz=0.0.
Right. I don’t necessarily want to disable 2.4GHz entirely. The device in
question is a laptop, and I use it sometimes in locations around my house
where I don’t anticipate 5GHz channels to be a good choice at all. I could try
fine-tuning for my experience by fiddling with these ranking modifiers, but my
experience today isn’t *that* terrible that I wouldn’t be able to address it
by other means.
>Also your BandModifier5Ghz setting has a typo, its using an uppercase 'H'.
>Someone else got hit by this recently, we need to add support for both.
ACK
>Thanks,
>James
Thank you,
S.
prev parent reply other threads:[~2023-10-14 17:42 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
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 [this message]
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=bg4jb3gdt6xwuqxc2y2sbnaqs3ruh4mvavml5njyi66dvgsx7j@du4n43ujxerb \
--to=iwd.lists.linux.dev@kazlauskas.me \
--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.