Change the WiFi scan duration time

Hi @Loic,

Board used: custom board based on APQ8016E (G2 board)
SW: Linaro 18.01
WiFi chip: WCN3660B

How can we change the WiFi channel scan duration time from the WCN36xx driver in Linaro-20.07?

Can we use the same macros mentioned on the below patch.
https://git.linaro.org/people/loic.poulain/linux.git/commit/?h=qcomlt-5.7-wifi&id=d063c541b4fdbbe7926b12c33f3503accf0b6a3c

Regards,
Parth Y Shah

You can, but It’s not recommended to change these values, which have been defined to scan efficiently. (related lkml topic: Re: [PATCH] wcn36xx: Fix software-driven scan (Linux Wireless))

@loic,

Could you please add some description to these values ?

We see that when the device is connected to the network the scan duration is 15 seconds which is very big and we wanted to reduce that. How can we use these parameters to achieve the same?

Regards.

That depends on how many channels you scan, and how many are scanned passively or activly. CHANNEL_TIME is the time to listen on a channel during active scan (probe request / probe response), PASSIVE_CHANNEL_TIME is the time to listen on a channel during passive scan (listening for beacon). for the last, given than APs usually send beacon every 100ms (or even 200ms), reducing it below 100ms increse the risk to miss APs. Moreover, normal data traffic handling is interleaved with scanning, which explains the scan duration.

Hi @Loic,

We have checked this patch with some different values.
It reduces the scan time from 15 seconds to 12 seconds, BUT it finds like a half of the networks in the air.

Without this change the scan result returns X networks. With this patch it returns x/2 .

So, however this change reduces the scan time, it breaks the scan functionality.

As these values are not related to the issue, the questions are:

  • What is the reason to such high scan duration in Linarp-20.07 compared to Linaro-18.01?
  • Where is exactly it’s configured ?

Regards.

Is that not what you would expect to happen?

We wanted to reduce the scan interval time but not at the cost of reduced networks list as mentioned above.

@Loic: Can you please help to understand, in Linaro-18.01 scan interval was around 2-3 seconds but now in Linaro-20.07 it is around 15 seconds?
We need to understand which architectural change leads to increase in the scan interval?

Regards,
Parth Y Shah

Don’t understand that point, that should not depend on the release but on if you’re using offloaded scan or software scan, if you’re connected to an AP and how much channels you’re actually want to scan.

Now you can try to play with scan vs data interleaving, by adjusting the amount of time to listen on opertational channel between each channel scan (E.g. 50ms HZ/20), that will reduce the total scanning time (when connected to AP), but on the other side will reduce the data throughput during scanning. (scan.c « mac80211 « net - loic.poulain/linux.git - [no description])

@loic, we have did below change in Linaro-18.01 in order to enable SW scan. In this case passive scan took 2-3 seconds.

--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -652,7 +652,7 @@ static int wcn36xx_hw_scan(struct ieee80211_

        mutex_unlock(&wcn->scan_lock);

-       if (!get_feat_caps(wcn->fw_feat_caps, SCAN_OFFLOAD)) {
+       if (get_feat_caps(wcn->fw_feat_caps, SCAN_OFFLOAD)) {
                /* legacy manual/sw scan */
                schedule_work(&wcn->scan_work);
                return 0;

In Linaro-20.07 also, WCN36xx is doing SW scan only. Here, the passive scan takes ~15 seconds (No change have been done separately).

We want to understand what is the difference between these two SW scans, why the latter takes much time for scan.

because 18.01 software scan was not implemented in the right way and has been fixed, you should get work that has been pushed upstream. 18.01 scan causes connection drop and does not support active scan.

Got your point here @Loic.

Here, you mean HW scan, right?

Our customer is asking in Linaro-18.01 they observed 2/3 seconds of scan but now with Linaro-20.07 they are observing ~15 seconds of time. They want to understand, why this huge delay is there? what are those significant changes in Linaro-20.07 cause this huge change in scanning interval?

Regards,
Parth Y Shah

I don’t understand, 20.07 contains patches that enable software scanning, which is used for scanning 5Ghz channels, and this software scan takes time, yes. 18.01 does nor support 5Ghz scanning.

Hi @Loic,

On the below thread,
https://www.spinics.net/lists/linux-wireless/msg201935.html

We saw that you are discussing about the SW scan time has been reduced using wcn36xx_flush(), is it working now and do you have any stable patch for the same? If yes, can you please provide us the same?

Regards,
Parth Y Shah

Hi @Loic,

Any update here?

Can below comments can help us?

If we implement ops->flush() we can slash that idle time down significantly

static void ieee80211_scan_state_resume(struct ieee80211_local *local,
                                          unsigned long *next_delay)
{

          if (local->ops->flush) {
                  ieee80211_flush_queues(local, NULL, false);
                  *next_delay = 0;
          } else
                  *next_delay = HZ / 10;
}

Trivial hack example:

+void wcn36xx_flush(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
+                  u32 queues, bool drop)
+{
+}
+
   static const struct ieee80211_ops wcn36xx_ops = {
          .start                  = wcn36xx_start,
          .stop                   = wcn36xx_stop,
@@ -1187,7 +1192,7 @@ static const struct ieee80211_ops wcn36xx_ops = {
          .sta_add                = wcn36xx_sta_add,
          .sta_remove             = wcn36xx_sta_remove,
          .ampdu_action           = wcn36xx_ampdu_action,
-
+       .flush                  = wcn36xx_flush,
          CFG80211_TESTMODE_CMD(wcn36xx_tm_cmd)
   };

Interestingly, we could indeed get rid of this extra 100ms. Maybe a way to implement this would be to wait for the TX ring to be empty in dxe.

> That ~ 20 seconds is cut to just 4 ! Which to be fair seems to be the kind of time it took to do the old version of the software scan.