[RFC 1/3] nl/cfg80211: add chan_time for scan request

[Sunil Dutt]

Hi Johannes and Michal ,
In this context I would also like to mention that there are also some
use cases ( Ex WiFi Positioning) ,  where good performance shall
result from using signals from as many Access Points as possible, a
fixed dwell / chan time in the host driver shall result in the poor
discovery efficiency of the Access Points,negatively impacting WiFi
positioning performance.

I would say such applications shall benefit by configuring a chan (dwell)_time.
Also,an attribute corresponding to the mode of the scan ( active /
passive ) , along with chan_time would benefit such applications with
more configurable options. Isn't it ?
Please correct me .

Regards,
Sunil

On Fri, Aug 2, 2013 at 6:00 PM, Sunil Dutt <usdutt at gmail.com> wrote:
> Hi Johannes and Michal ,
> In this context I would also like to mention that there are also some use
> cases ( Ex WiFi Positioning) ,  where good performance shall result from
> using signals from as many Access Points as possible, a fixed dwell / chan
> time in the host driver shall result in the poor discovery efficiency of the
> Access Points,negatively impacting WiFi positioning performance.
>
> I would say such applications shall benefit by configuring a chan
> (dwell)_time.
> Also,an attribute corresponding to the mode of the scan ( active / passive )
> , along with chan_time would benefit such applications with more
> configurable options. Isn't it ?
> Please correct me .
>
> Regards,
> Sunil
>
>
>
>
> On Fri, Aug 2, 2013 at 4:55 PM, Johannes Berg <johannes at sipsolutions.net>
> wrote:
>>
>> On Thu, 2013-08-01 at 11:14 +0200, Michal Kazior wrote:
>>
>> > > This seems a bit iffy - you don't differentiate between active/passive
>> > > scans?
>> >
>> > Is there a reason this should be differentiated?
>>
>> Well they don't usually have the same timing, passive channel dwell time
>> usually needs to be longer than on active channels.
>>
>> > > This also interferes a bit with some other scan optimisations that
>> > > could
>> > > be done at a low firmware level, so I think we should be careful and
>> > > actually say that this is really more intended for measurement use
>> > > cases
>> > > and not for normal scans?
>> > >
>> > > Or maybe we should have a separate measurement command with similar
>> > > semantics? This all doesn't seem very clear to me yet :)
>> >
>> > Motivation behind this patchset is to simplify ACS implementation and
>> > depend on scan. This also allows easier fallback from survey-based ACS
>> > to BSS-based one.
>>
>> Sure, I understand.
>>
>> > Other use cases are a side-effect so perhaps clarifying the intent in
>> > the docs is enough.
>>
>> I'm just saying that this is a fundamentally different usage than actual
>> scanning. Let's say for the sake of the argument I find a way to scan
>> channels quicker and implement that in my device (hw_scan). I don't
>> think this is too far-fetched, imagine I have an 80MHz capable device
>> and can send probe request 4x transmissions on all the subchannels, if
>> somehow I manage to separate the receive then I could scan 4x as
>> quickly. I don't think this particular thing is possible but I could
>> imagine scan optimisations like it.
>>
>> Now this comes along - and suddenly the API requires that you stay on
>> each specified channel for the given period of time. Any such
>> "non-traditional" scan optimisations would have to be given up, so in a
>> sense this fundamentally alters the semantics of the scan primitive,
>> where before it was "give me the list of networks (with these SSIDs) on
>> these channels" it now becomes "go to each channel, stay there for this
>> amount of time and ..."
>>
>> That's what I'm worried about - the implicit semantic change here.
>>
>> johannes
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>