Configurable scan dwell time?

Configurable scan dwell time?

[Ben Greear]

It looks to me like the channel dwell time when scanning (SW scanning, mac80211)
is fixed at 1/9 of a second.  I'd like to make this configurable...is that something
that might be welcome upstream?

My plan is to add to the netlink API around starting a scan and allow user-space to
configure a dwell time in milliseconds.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Configurable scan dwell time?

[Michal Kazior]

On 5 November 2015 at 00:58, Ben Greear <greearb@candelatech.com> wrote:
> It looks to me like the channel dwell time when scanning (SW scanning,
> mac80211)
> is fixed at 1/9 of a second.  I'd like to make this configurable...is that
> something
> that might be welcome upstream?
>
> My plan is to add to the netlink API around starting a scan and allow
> user-space to
> configure a dwell time in milliseconds.

I've actually tried doing something like this some time ago:

 - http://thread.gmane.org/gmane.linux.kernel.wireless.general/111255
 - http://thread.gmane.org/gmane.linux.kernel.wireless.general/111251


Michał

Re: Configurable scan dwell time?

[Johannes Berg]

On Thu, 2015-11-05 at 07:41 +0100, Michal Kazior wrote:
> On 5 November 2015 at 00:58, Ben Greear <greearb@candelatech.com>
> wrote:
> > It looks to me like the channel dwell time when scanning (SW
> > scanning,
> > mac80211)
> > is fixed at 1/9 of a second.  I'd like to make this
> > configurable...is that
> > something
> > that might be welcome upstream?
> > 
> > My plan is to add to the netlink API around starting a scan and
> > allow
> > user-space to
> > configure a dwell time in milliseconds.
> 
> I've actually tried doing something like this some time ago:
> 
>  - http://thread.gmane.org/gmane.linux.kernel.wireless.general/111255
>  - http://thread.gmane.org/gmane.linux.kernel.wireless.general/111251
> 

And as I said back then, I'm rather opposed to this. We risk adding API
that either nobody uses, or that ends up getting used in ways that
weren't intended (say for certain measurements) and then will break
things when scanning is changed in firmware, etc.

Let the scanning be. It's intended to find networks, not really
something else. Piggy-backing survey onto it was mostly a mistake. For
other things, do some more reasonable measurement commands.

johannes

Re: Configurable scan dwell time?

[Ben Greear]

On 11/04/2015 11:56 PM, Johannes Berg wrote:
> On Thu, 2015-11-05 at 07:41 +0100, Michal Kazior wrote:
>> On 5 November 2015 at 00:58, Ben Greear <greearb@candelatech.com>
>> wrote:
>>> It looks to me like the channel dwell time when scanning (SW
>>> scanning,
>>> mac80211)
>>> is fixed at 1/9 of a second.  I'd like to make this
>>> configurable...is that
>>> something
>>> that might be welcome upstream?
>>>
>>> My plan is to add to the netlink API around starting a scan and
>>> allow
>>> user-space to
>>> configure a dwell time in milliseconds.
>>
>> I've actually tried doing something like this some time ago:
>>
>>   - http://thread.gmane.org/gmane.linux.kernel.wireless.general/111255
>>   - http://thread.gmane.org/gmane.linux.kernel.wireless.general/111251
>>
>
> And as I said back then, I'm rather opposed to this. We risk adding API
> that either nobody uses, or that ends up getting used in ways that
> weren't intended (say for certain measurements) and then will break
> things when scanning is changed in firmware, etc.
>
> Let the scanning be. It's intended to find networks, not really
> something else. Piggy-backing survey onto it was mostly a mistake. For
> other things, do some more reasonable measurement commands.

My issue is that APs can be set to beacon at longer beacon times, and
then passive scanning at ~110ms intervals is not going to find the APs
very often (and with bad luck, technically it could *never* find the AP
due to scanning at unlucky periodic intervals).

So, when I know that I am doing passive scan, I would like the option
to set the dwell time larger.

And, for active scanning, maybe 33ms is a lot longer that is actually
needed?

I read through some of your comments from before.  I think we could
treat this as a hint to the driver, and it could ignore it as needed.

Firmware implementations I'm aware of are already limited in a million
different ways, and of course if someone cared, they could propagate
the dwell time into the firmware if they cared.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Configurable scan dwell time?

[Johannes Berg]

On Thu, 2015-11-05 at 08:01 -0800, Ben Greear wrote:

> My issue is that APs can be set to beacon at longer beacon times, and
> then passive scanning at ~110ms intervals is not going to find the APs
> very often (and with bad luck, technically it could *never* find the AP
> due to scanning at unlucky periodic intervals).

Which is probably why hardly anyone ever uses longer beacon intervals
(also the added latency with powersave, of course)

> So, when I know that I am doing passive scan, I would like the option
> to set the dwell time larger.
> 
> And, for active scanning, maybe 33ms is a lot longer that is actually
> needed?

There are some (WFA?) requirements to answer within 30ms, but not
faster, so I think that's the reason for this value.

> I read through some of your comments from before.  I think we could
> treat this as a hint to the driver, and it could ignore it as needed.
> 
> Firmware implementations I'm aware of are already limited in a million
> different ways, and of course if someone cared, they could propagate
> the dwell time into the firmware if they cared.
> 

The thing though is that there are now use cases in the standard(s)
that want/require doing this. So just adding it as a hint will run the
risk of userspace (like wpa_s) using this "hint" for implementing newer
spec functionality, testing on ath9k and hwsim and declaring that it
works :-) And then we're stuck with this feature being used/advertised
on older devices where it doesn't actually work.

Now, having those standard use cases is actually a good argument *for*
adding them in the standard API, but I think we need to be more careful
around these issues - perhaps having drivers indicate that they support
it, maybe even with valid ranges, etc.

johannes

Re: Configurable scan dwell time?

[Ben Greear]

On 11/05/2015 08:06 AM, Johannes Berg wrote:
> On Thu, 2015-11-05 at 08:01 -0800, Ben Greear wrote:
>
>> My issue is that APs can be set to beacon at longer beacon times, and
>> then passive scanning at ~110ms intervals is not going to find the APs
>> very often (and with bad luck, technically it could *never* find the AP
>> due to scanning at unlucky periodic intervals).
>
> Which is probably why hardly anyone ever uses longer beacon intervals
> (also the added latency with powersave, of course)
>
>> So, when I know that I am doing passive scan, I would like the option
>> to set the dwell time larger.
>>
>> And, for active scanning, maybe 33ms is a lot longer that is actually
>> needed?
>
> There are some (WFA?) requirements to answer within 30ms, but not
> faster, so I think that's the reason for this value.

An AP could (and in my experience, does) answer probes much faster.

(With ath9k and ath10k AP, I see probe response within 1ms in a sniff I just did).

So, doing active scans you could *often* do an entire spectrum
scan 10 times faster than what we see today.

A supplicant could request a fast time, and then if that didn't find anything,
the next scan could be slower as needed.

>> I read through some of your comments from before.  I think we could
>> treat this as a hint to the driver, and it could ignore it as needed.
>>
>> Firmware implementations I'm aware of are already limited in a million
>> different ways, and of course if someone cared, they could propagate
>> the dwell time into the firmware if they cared.
>>
>
> The thing though is that there are now use cases in the standard(s)
> that want/require doing this. So just adding it as a hint will run the
> risk of userspace (like wpa_s) using this "hint" for implementing newer
> spec functionality, testing on ath9k and hwsim and declaring that it
> works :-) And then we're stuck with this feature being used/advertised
> on older devices where it doesn't actually work.

Scanning is already best effort.  Someone implementing this new hint
can just be aware of the limitations.  If nothing else, start a scan on
a known number of channels (or single channel), see how long it takes..then you know if the
driver is ignoring your hint or not.

> Now, having those standard use cases is actually a good argument *for*
> adding them in the standard API, but I think we need to be more careful
> around these issues - perhaps having drivers indicate that they support
> it, maybe even with valid ranges, etc.

I think that is vastly over-engineering the problem, but truth is, it
can always be added later if there is an actual need for that knowledge.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Configurable scan dwell time?

[Johannes Berg]

> > The thing though is that there are now use cases in the standard(s)
> > that want/require doing this. So just adding it as a hint will run the
> > risk of userspace (like wpa_s) using this "hint" for implementing newer
> > spec functionality, testing on ath9k and hwsim and declaring that it
> > works :-) And then we're stuck with this feature being used/advertised
> > on older devices where it doesn't actually work.
> 
> Scanning is already best effort.  Someone implementing this new hint
> can just be aware of the limitations.  If nothing else, start a scan on
> a known number of channels (or single channel), see how long it takes..then you know if the
> driver is ignoring your hint or not.

But if you were asked to measure something on that channel, for a given
amount of time while scanning, you could reasonably implement it that
way. If you don't really know how long the device is *actually* going
to do this, then you can't rightfully say you implement that spec.

You can't really start a scan and measure the time either since there's
no guarantee the scan will start right away.

> > Now, having those standard use cases is actually a good argument *for*
> > adding them in the standard API, but I think we need to be more careful
> > around these issues - perhaps having drivers indicate that they support
> > it, maybe even with valid ranges, etc.
> 
> I think that is vastly over-engineering the problem, but truth is, it
> can always be added later if there is an actual need for that knowledge.
> 

Well, not really. The only way for this to work would be to outright
reject requests that weren't within the advertised ranges; doing this
after already having the API would break existing clients thereof.

johannes

Re: Configurable scan dwell time?

[Ben Greear]

On 11/05/2015 08:25 AM, Johannes Berg wrote:
>
>>> The thing though is that there are now use cases in the standard(s)
>>> that want/require doing this. So just adding it as a hint will run the
>>> risk of userspace (like wpa_s) using this "hint" for implementing newer
>>> spec functionality, testing on ath9k and hwsim and declaring that it
>>> works :-) And then we're stuck with this feature being used/advertised
>>> on older devices where it doesn't actually work.
>>
>> Scanning is already best effort.  Someone implementing this new hint
>> can just be aware of the limitations.  If nothing else, start a scan on
>> a known number of channels (or single channel), see how long it takes..then you know if the
>> driver is ignoring your hint or not.
>
> But if you were asked to measure something on that channel, for a given
> amount of time while scanning, you could reasonably implement it that
> way. If you don't really know how long the device is *actually* going
> to do this, then you can't rightfully say you implement that spec.
>
> You can't really start a scan and measure the time either since there's
> no guarantee the scan will start right away.

Grep for 'dwell_time' in ath10k driver dir...it is already using different
values (active 50, passive 150) than what mac80211 does, so anyone assuming scan time is exactly some
duration is already confused.

>>> Now, having those standard use cases is actually a good argument *for*
>>> adding them in the standard API, but I think we need to be more careful
>>> around these issues - perhaps having drivers indicate that they support
>>> it, maybe even with valid ranges, etc.
>>
>> I think that is vastly over-engineering the problem, but truth is, it
>> can always be added later if there is an actual need for that knowledge.
>>
>
> Well, not really. The only way for this to work would be to outright
> reject requests that weren't within the advertised ranges; doing this
> after already having the API would break existing clients thereof.

It wouldn't break clients if the value is known to just be a hint
from the beginning..ie clients cannot ever expect that this value
is guaranteed to be used.

But, if it would help this feature get upstream, then I will work on
adding a driver flag.  Would that make it acceptable for upstream?

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Configurable scan dwell time?

[Johannes Berg]

On Thu, 2015-11-05 at 08:42 -0800, Ben Greear wrote:

> Grep for 'dwell_time' in ath10k driver dir...it is already using
> different values (active 50, passive 150) than what mac80211 does, so
> anyone assuming scan time is exactly some duration is already
> confused.

Sure, you can even grep more carefully and notice that in certain cases
iwlwifi/mvm doesn't even have control over the dwell times as they're
handled entirely in firmware, and the firmware might do stranger things
still.

In the future, with FILS, scanning is going to get more complicated and
will likely have to jump around channels, hitting each one two or more
times.

But that's kinda my point - we have lots of different ways to do
scanning today. Assuming anything about it, other than that'll
eventually return scan results, is pointless.

You're arguing though that dwell time should be controllable. This can
be a problem:

> It wouldn't break clients if the value is known to just be a hint
> from the beginning..ie clients cannot ever expect that this value
> is guaranteed to be used.

Then I fail to see the use-case for this. If there's an actual
requirement to do scanning with a changed dwell time, then you really
will need to know that it is going to work/has worked. If you don't
really care, why would you specify a hint?

This isn't really an optimisation that you can safely ignore. It has
massive impact on the scan scheduling/timing.

> But, if it would help this feature get upstream, then I will work on
> adding a driver flag.  Would that make it acceptable for upstream?

I think you really should more clearly define the use case for this
first. If it's just a debug (or similar) thing, why even bother, we can
just put it into ath10k debugfs?

I'll agree that many of the software implementation are pretty simple
today and could implement this fairly easily, but I don't want us to
cut off the path towards other things like FILS in the future by using
something like this. Especially without a well-defined use-case.

Jouni mentioned once to me that there is actually a spec use case for
something like that, but I'm not sure if it's really scanning or
measurement? In any case, even if that's scanning, it should really be
understood to apply to those use cases only, and not be used
indiscriminately, since using it will cut off the ability of using
current and future optimisations.

johannes

Re: Configurable scan dwell time?

[Ben Greear]

On 11/20/2015 04:05 AM, Johannes Berg wrote:
> On Thu, 2015-11-05 at 08:42 -0800, Ben Greear wrote:
>
>> Grep for 'dwell_time' in ath10k driver dir...it is already using
>> different values (active 50, passive 150) than what mac80211 does, so
>> anyone assuming scan time is exactly some duration is already
>> confused.
>
> Sure, you can even grep more carefully and notice that in certain cases
> iwlwifi/mvm doesn't even have control over the dwell times as they're
> handled entirely in firmware, and the firmware might do stranger things
> still.
>
> In the future, with FILS, scanning is going to get more complicated and
> will likely have to jump around channels, hitting each one two or more
> times.
>
> But that's kinda my point - we have lots of different ways to do
> scanning today. Assuming anything about it, other than that'll
> eventually return scan results, is pointless.
>
> You're arguing though that dwell time should be controllable. This can
> be a problem:
>
>> It wouldn't break clients if the value is known to just be a hint
>> from the beginning..ie clients cannot ever expect that this value
>> is guaranteed to be used.
>
> Then I fail to see the use-case for this. If there's an actual
> requirement to do scanning with a changed dwell time, then you really
> will need to know that it is going to work/has worked. If you don't
> really care, why would you specify a hint?

What about this for a use case:

Goal is to scan very quickly and get onto a network much faster than today's
scan allows.

Implementation:  If supplicant is so configured, do first scan with
the configured scan time (assume it is short, maybe 3-5ms).

If no scan results are found, scan at default rates.  Supplicant
could alternate between fast and slow as desired.

For any driver that can implement fast scanning, and for APs that
can answer probes quickly, then we are likely to get onto the
network with the first fast scan.

And if not, then the subsequent slower scans should do the trick.

Second use case is with passive scanning when the user knows or suspects APs
may be configured with longer than normal beacon times.  Implementation
is to configure longer-than-default scan dwell times in order to
more likely see the beacons on the first scan attempt.


> This isn't really an optimisation that you can safely ignore. It has
> massive impact on the scan scheduling/timing.
>
>> But, if it would help this feature get upstream, then I will work on
>> adding a driver flag.  Would that make it acceptable for upstream?
>
> I think you really should more clearly define the use case for this
> first. If it's just a debug (or similar) thing, why even bother, we can
> just put it into ath10k debugfs?
>
> I'll agree that many of the software implementation are pretty simple
> today and could implement this fairly easily, but I don't want us to
> cut off the path towards other things like FILS in the future by using
> something like this. Especially without a well-defined use-case.
>
> Jouni mentioned once to me that there is actually a spec use case for
> something like that, but I'm not sure if it's really scanning or
> measurement? In any case, even if that's scanning, it should really be
> understood to apply to those use cases only, and not be used
> indiscriminately, since using it will cut off the ability of using
> current and future optimisations.

To be honest, I am having a hard time figuring out any real downside
to my suggestion.  If you need to implement something different in
the future, then just do that and deprecate configurable dwell time
(or just configure it to defaults in supplicant) if that conflicts
with your new and better feature.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com