On 12/20/2022 6:36 PM, Marcel Holtmann wrote:
Hi Manikanta,
Currently, time taken to scan all supported channels on WCN6750
is ~8 seconds and connection time is almost 10 seconds. WCN6750
supports three Wi-Fi bands (i.e., 2.4/5/6 GHz) and the numbers of
channels for scan come around ~100 channels (default case).
Since the chip doesn't have support for DBS (Dual Band Simultaneous),
scans cannot be parallelized resulting in longer scan times.
Among the 100 odd channels, ~60 channels are in 6 GHz band. Therefore,
optimizing the scan for 6 GHz channels will bring down the overall
scan time.
WCN6750 firmware has support to scan a 6 GHz channel based on co-located
AP information i.e., RNR IE which is found in the legacy 2.4/5 GHz scan
results. When a scan request with all supported channel list is enqueued
to the firmware, then based on WMI_SCAN_CHAN_FLAG_SCAN_ONLY_IF_RNR_FOUND
scan channel flag, firmware will scan only those 6 GHz channels for which
RNR IEs are found in the legacy scan results.
In the proposed design, based on NL80211_SCAN_FLAG_COLOCATED_6GHZ scan
flag, driver will set the WMI_SCAN_CHAN_FLAG_SCAN_ONLY_IF_RNR_FOUND flag
for non-PSC channels. Since there is high probability to find 6 GHz APs
on PSC channels, these channels are always scanned. Only non-PSC channels
are selectively scanned based on cached RNR information from the legacy
scan results.
If NL80211_SCAN_FLAG_COLOCATED_6GHZ is not set in the scan flags,
then scan will happen on all supported channels (default behavior).
is this really a good idea? The interpretation on what scan results will
be reported would be preferable the same no matter what hardware is
present. Why would ath11k now have a different behavior?
And more important, why is this something driver or even Linux kernel
specific. Let userspace select the frequencies to scan.
By the way, userspace itself selects the frequencies to scan, not the
driver.
If we see the split scan implementation in cfg80211, this is the how it
is implemented. If NL80211_SCAN_FLAG_COLOCATED_6GHZ is set, it selects
all PSC channels and those non-PSC channels where RNR IE information is
found in the legacy scan results. If this flag is not set, all channels
in 6 GHz are included in the scan freq list. It is upto userspace to
decide what it wants.
Looks like that iwd and wpa_supplicant set this flag regardless which
means to me that a driver should respect the requested frequencies to
be scanned.
Anyhow, if you worry about time-to-connect, then fix userspace to be
smart with scanning. I am also confused on how a savings of 1.5 seconds
out of 8 seconds is significant.
Most of the times, we see ~2 seconds of savings. 2 seconds of scan time
improvement out of 8 seconds is about 25% improvement and this is indeed
significant.
8 seconds of time I'm talking here is for passive scan when the
regdomain is set to WORLD. If correct regdomain is set and channel flags
are proper, then the time it takes to complete scan & connection is much
lesser with this change. It is around 4 seconds.
It still means you spent 6+ seconds
in the 2.4 GHz and 5 GHz bands. I assume that you spent most time in
5 GHz right now.
I highly doubt that a 6+ seconds plus 2 seconds connection time is
anywhere acceptable
As I said before, this is the worst case scenario. Active scan and
connection on legacy band takes less than 4 seconds in normal usecase.
Have you tried using iwd and see what the
connection time actually is after initial connection.
Not really, I'll try it out. Thanks for the suggestion.
Thanks,
Manikanta
