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

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 [off-list ref] 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 [off-list ref]
wrote:

quoted

On Thu, 2013-08-01 at 11:14 +0200, Michal Kazior wrote:

quoted

quoted

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.

quoted

quoted

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.

quoted

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html