Message ID | 519C36EB.3080201@candelatech.com |
---|---|
State | Accepted |
Headers | show |
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.
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 > >
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