On Thu, 21 May 2026 23:05:40 +0200,
Stefan Sperling <stsp@stsp.name> wrote:
> 
> On Thu, May 21, 2026 at 10:35:13PM +0200, Kirill A. Korinsky wrote:
> > On Thu, 21 May 2026 22:31:03 +0200,
> > Stefan Sperling <stsp@stsp.name> wrote:
> > > 
> > > On Thu, May 21, 2026 at 10:19:49PM +0200, Marcus Glocker wrote:
> > > > On Wed, May 20, 2026 at 01:02:13AM +0200, Kirill A. Korinsky wrote:
> > > > 
> > > > > tech@,
> > > > > 
> > > > > I think that Report RSSI as percentage, it is more user friendly than dBm.
> > > > > 
> > > > > So, here I've used the same conversion logic as iwx for both qwz and qwx.
> > > > > 
> > > > > Ok?
> > > > 
> > > > I prefer the % display as well, and the diff works fine with my qwz.
> > > > So basically ok mglocker@, but maybe it would be good to have stsp@'s
> > > > feedback as well before we go ahead committing it.
> > > 
> > > What is most important here is that the values reported to the stack
> > > make sense relative to the background scan / roaming thresholds:
> > > 
> > > #define IEEE80211_RSSI_THRES_2GHZ		(-60)	/* in dBm */
> > > #define IEEE80211_RSSI_THRES_5GHZ		(-70)	/* in dBm */
> > > #define IEEE80211_RSSI_THRES_RATIO_2GHZ		60	/* in percent */
> > > #define IEEE80211_RSSI_THRES_RATIO_5GHZ		50	/* in percent */
> > > 
> > > Do you have multiple APs that share an SSID to test roaming with?
> > >
> > 
> > Yes, I do, that you would like to test?
> 
> My main point is that this change isn't just cosmetic. The change
> could have a real impact on roaming behavior and some attention
> to that fact is warranted. At least confirming that roaming still
> works as expected would be good.
> 
> > > > >  /* Antenna noise floor */
> > > > >  #define ATH11K_DEFAULT_NOISE_FLOOR -95
> > > > > +#define QWX_MIN_DBM	-100
> > > > > +#define QWX_MAX_DBM	-33	/* realistic guess */
> > > 
> > > Is this really just a guess? Or did you get this number from somewhere?
> > >
> > > I don't think this number is unreasonable (the theoretical max was -20dBm
> > > if I recall correctly?) But we should be sure that the range makes sense
> > > for this device, which may behave differently to the Intel ones since
> > > RSSI is a vendor-specific heuristic. If we now end up always reporting
> > > 50% or less then we would constantly be trying to roam. And if we never
> > > fall below 50% anymore then we will never try to roam. If we're somewhere
> > > between those two extremes that's ok and we can keep tweaking it if needed.
> > 
> > This numbers came from iwx with exact comment :-)
> 
> So -33 maximum should be correct for what Intel devices are reporting.
> I believe we unfortunately cannot rely on RSSI reported by other
> vendor's devices to use the same range.
> 
> If no documented range can be found for these devices, one way might be
> to print the values while doing range tests against several APs (since
> AP TX power will also affect this, trying multiple APs would be good).
> Then pick a maximum based on observed values.
> 
> Or just pick a number, and pay some attention to how it works out
> with roaming in practice. Roaming cannot be implemented perfectly
> for everyone at all times anyway because real conditions vary.
> 

In direct view of AP it reports -30 dBm, in quite long distance from AP I
was able to see -90 dBm.

Next, roaming. It doesn't work. It never jumped to AP in direct view of
laptop when I saw -90 dBm. And iwx laptop jumped to it.

Is it sane numbers? Probably. I haven't find anything better.

-- 
wbr, Kirill