Patchwork wpa_supplicant: Issue with long scan times on startup.

login
register
mail settings
Submitter Ben Greear
Date May 22, 2013, 3:09 a.m.
Message ID <519C36EB.3080201@candelatech.com>
Download mbox | patch
Permalink /patch/245486/
State New
Headers show

Comments

Ben Greear - May 22, 2013, 3:09 a.m.
When you have lots of stations, the initial scan time logic
goes a bit haywire, causing long delays before the initial scan
is attempted.

The patch below works better for me:



Any interest in pushing something like this upstream?

Thanks,
Ben
Jouni Malinen - May 22, 2013, 8:07 a.m.
On Tue, May 21, 2013 at 08:09:31PM -0700, Ben Greear wrote:
> When you have lots of stations, the initial scan time logic
> goes a bit haywire, causing long delays before the initial scan
> is attempted.
> 
> The patch below works better for me:

> diff --git a/wpa_supplicant/wpa_supplicant.c b/wpa_supplicant/wpa_supplicant.c
> @@ -2420,9 +2420,9 @@ int wpa_supplicant_driver_init(struct wpa_supplicant *wpa_s)
> -                       wpa_supplicant_req_scan(wpa_s, interface_count,
> +                       wpa_supplicant_req_scan(wpa_s, interface_count % 3,
>                                                 100000);
>                 interface_count++;

> Any interest in pushing something like this upstream?

That's probably fine. When you go beyond tens of stations, all bets are
off on scanning anyway ;-). I'd make that value a bit higher, though,
since some concurrent cases are starting to show up with larger number
of interfaces. Say, five would sound fine to use in upstream and I'd
assume it wouldn't make much of difference for you either.
Ben Greear - May 22, 2013, 2:52 p.m.
On 05/22/2013 01:07 AM, Jouni Malinen wrote:
> On Tue, May 21, 2013 at 08:09:31PM -0700, Ben Greear wrote:
>> When you have lots of stations, the initial scan time logic
>> goes a bit haywire, causing long delays before the initial scan
>> is attempted.
>>
>> The patch below works better for me:
>
>> diff --git a/wpa_supplicant/wpa_supplicant.c b/wpa_supplicant/wpa_supplicant.c
>> @@ -2420,9 +2420,9 @@ int wpa_supplicant_driver_init(struct wpa_supplicant *wpa_s)
>> -                       wpa_supplicant_req_scan(wpa_s, interface_count,
>> +                       wpa_supplicant_req_scan(wpa_s, interface_count % 3,
>>                                                  100000);
>>                  interface_count++;
>
>> Any interest in pushing something like this upstream?
>
> That's probably fine. When you go beyond tens of stations, all bets are
> off on scanning anyway ;-). I'd make that value a bit higher, though,
> since some concurrent cases are starting to show up with larger number
> of interfaces. Say, five would sound fine to use in upstream and I'd
> assume it wouldn't make much of difference for you either.

The logic that shares scan results helps a lot, and the kernel will reject
(EBUSY I think) duplicate scan attempts.  As long as supplicant backs off
in some way, I don't think the initial scan time that this patch modifies
matters too much.  I'm tempted to decrease it down to % 2, in fact...

The patch I put in recently to allow scan-on-channel when 1+ VIFS is associated is
also a big help in this case.  At least for ath9k, there is basically zero
overhead to scanning just on the working channel (we can continue processing
normal frames during the scan process).

Another reason why I don't like the initial timer is that we may
have 100 stations associated, and then we add the 101'st.  There is no
reason not to scan right away..or at least very quickly, since it will
be the only station scanning....

Thanks,
Ben


>
>

Patch

diff --git a/wpa_supplicant/wpa_supplicant.c b/wpa_supplicant/wpa_supplicant.c
index 4b8d0d0..a398bb8 100644
--- a/wpa_supplicant/wpa_supplicant.c
+++ b/wpa_supplicant/wpa_supplicant.c
@@ -2420,9 +2420,9 @@  int wpa_supplicant_driver_init(struct wpa_supplicant *wpa_s)
         wpa_s->prev_scan_wildcard = 0;

         if (wpa_supplicant_enabled_networks(wpa_s)) {
-               if (wpa_supplicant_delayed_sched_scan(wpa_s, interface_count,
+               if (wpa_supplicant_delayed_sched_scan(wpa_s, interface_count % 3,
                                                       100000))
-                       wpa_supplicant_req_scan(wpa_s, interface_count,
+                       wpa_supplicant_req_scan(wpa_s, interface_count % 3,
                                                 100000);
                 interface_count++;
         } else