Configurable scan dwell time?
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
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 9 lines · 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.
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ł
Quoted 15 lines · Michal Kazior
Quoted 8 lines · 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?Quoted 4 lines
My plan is to add to the netlink API around starting a scan and allow
user-space to
configure a dwell time in milliseconds.
Quoted 5 lines
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
Quoted 22 lines · Johannes Berg
Quoted 15 lines · Michal Kazior
Quoted 8 lines · 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?Quoted 4 lines
My plan is to add to the netlink API around starting a scan and allow
user-space to
configure a dwell time in milliseconds.Quoted 5 lines
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
Quoted 8 lines
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
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 4 lines · Ben Greear
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)
Quoted 5 lines
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.
Quoted 7 lines
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
Quoted 10 lines · Johannes Berg
Quoted 4 lines · Ben Greear
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)
Quoted 8 lines
Quoted 5 lines
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.
Quoted 8 lines
Quoted 7 lines
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.
Quoted 6 lines
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.
Quoted 4 lines
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
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 8 lines
Quoted 7 lines
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.
Quoted 4 lines
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.
Quoted 8 lines
Quoted 4 lines
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
Quoted 13 lines · Johannes Berg
Quoted 8 lines
Quoted 7 lines
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.Quoted 4 lines
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.
Quoted 7 lines
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.
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
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.
Quoted 7 lines
Quoted 3 lines
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
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 4 lines · Ben Greear
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:
Quoted 3 lines
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.
Quoted 2 lines
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
Quoted 23 lines · Johannes Berg
Quoted 4 lines · Ben Greear
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:
Quoted 8 lines
Quoted 3 lines
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.
Quoted 15 lines
This isn't really an optimisation that you can safely ignore. It has massive impact on the scan scheduling/timing.
Quoted 2 lines
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.
Quoted 6 lines
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
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com