[PATCH 00/11] Initial sched_scan support in wpa_supplicant

[Luciano Coelho]

Hi Matt,

On Fri, 2011-09-30 at 09:45 -0400, Matt Causey wrote: 
> On Tue, Sep 27, 2011 at 3:21 PM, Luciano Coelho <coelho at ti.com> wrote:
> > Known issues:
> > -------------
> >
> > * I have implemented a rather simple algorithm that is used when we
> >  need to scan for more than the maximum SSIDs supported by the
> >  driver.  In this case, we need to eventually stop the sched_scan and
> >  start a new one with the remaining SSIDs.  In this implementation, I
> >  always start with a timeout of max_sched_scan_ssids * 2 seconds and
> >  an interval of 2 seconds.  After the timeout, I double the scan
> >  interval and halve the timeout.  This backing off algorithm is used
> >  because the SSIDs are supposedly sorted in order of importance, so
> >  we spend less time and with longer intervals when scanning lower
> >  priority SSIDs.
> 
> I know you mentioned that sched_scan only happens at start, fail, and
> disconnect, but in your testing, what is the impact of the scanning to
> traffic that's passing over the wireless card?  In my experience more
> time spent scanning means more time that user traffic is delayed or
> dropped, so I was just wondering if you have seen similar results.

We are not currently scanning while connected.  So this is not
implemented for roaming and thus there is not traffic to be disturbed.

I don't know how this would effect an existing connection, because the
wl12xx firmware (which is the only one that currently supports
sched_scan at all) doens't support sched_scans while associated.  So
what happens in this case is that any ongoing sched_scan is stopped
before associating.

-- 
Cheers,
Luca.