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@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
