* Configurable scan dwell time? @ 2015-11-04 23:58 Ben Greear 2015-11-05 6:41 ` Michal Kazior 0 siblings, 1 reply; 10+ messages in thread From: Ben Greear @ 2015-11-04 23:58 UTC (permalink / raw) To: linux-wireless 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Configurable scan dwell time? 2015-11-04 23:58 Configurable scan dwell time? Ben Greear @ 2015-11-05 6:41 ` Michal Kazior 2015-11-05 7:56 ` Johannes Berg 0 siblings, 1 reply; 10+ messages in thread From: Michal Kazior @ 2015-11-05 6:41 UTC (permalink / raw) To: Ben Greear; +Cc: linux-wireless 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ł ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Configurable scan dwell time? 2015-11-05 6:41 ` Michal Kazior @ 2015-11-05 7:56 ` Johannes Berg 2015-11-05 16:01 ` Ben Greear 0 siblings, 1 reply; 10+ messages in thread From: Johannes Berg @ 2015-11-05 7:56 UTC (permalink / raw) To: Michal Kazior, Ben Greear; +Cc: linux-wireless 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Configurable scan dwell time? 2015-11-05 7:56 ` Johannes Berg @ 2015-11-05 16:01 ` Ben Greear 2015-11-05 16:06 ` Johannes Berg 0 siblings, 1 reply; 10+ messages in thread From: Ben Greear @ 2015-11-05 16:01 UTC (permalink / raw) To: Johannes Berg, Michal Kazior; +Cc: linux-wireless 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Configurable scan dwell time? 2015-11-05 16:01 ` Ben Greear @ 2015-11-05 16:06 ` Johannes Berg 2015-11-05 16:21 ` Ben Greear 0 siblings, 1 reply; 10+ messages in thread From: Johannes Berg @ 2015-11-05 16:06 UTC (permalink / raw) To: Ben Greear, Michal Kazior; +Cc: linux-wireless 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Configurable scan dwell time? 2015-11-05 16:06 ` Johannes Berg @ 2015-11-05 16:21 ` Ben Greear 2015-11-05 16:25 ` Johannes Berg 0 siblings, 1 reply; 10+ messages in thread From: Ben Greear @ 2015-11-05 16:21 UTC (permalink / raw) To: Johannes Berg, Michal Kazior; +Cc: linux-wireless 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Configurable scan dwell time? 2015-11-05 16:21 ` Ben Greear @ 2015-11-05 16:25 ` Johannes Berg 2015-11-05 16:42 ` Ben Greear 0 siblings, 1 reply; 10+ messages in thread From: Johannes Berg @ 2015-11-05 16:25 UTC (permalink / raw) To: Ben Greear, Michal Kazior; +Cc: linux-wireless > > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Configurable scan dwell time? 2015-11-05 16:25 ` Johannes Berg @ 2015-11-05 16:42 ` Ben Greear 2015-11-20 12:05 ` Johannes Berg 0 siblings, 1 reply; 10+ messages in thread From: Ben Greear @ 2015-11-05 16:42 UTC (permalink / raw) To: Johannes Berg, Michal Kazior; +Cc: linux-wireless 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Configurable scan dwell time? 2015-11-05 16:42 ` Ben Greear @ 2015-11-20 12:05 ` Johannes Berg 2015-11-20 16:04 ` Ben Greear 0 siblings, 1 reply; 10+ messages in thread From: Johannes Berg @ 2015-11-20 12:05 UTC (permalink / raw) To: Ben Greear, Michal Kazior; +Cc: linux-wireless 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Configurable scan dwell time? 2015-11-20 12:05 ` Johannes Berg @ 2015-11-20 16:04 ` Ben Greear 0 siblings, 0 replies; 10+ messages in thread From: Ben Greear @ 2015-11-20 16:04 UTC (permalink / raw) To: Johannes Berg, Michal Kazior; +Cc: linux-wireless 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2015-11-20 16:04 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-11-04 23:58 Configurable scan dwell time? Ben Greear 2015-11-05 6:41 ` Michal Kazior 2015-11-05 7:56 ` Johannes Berg 2015-11-05 16:01 ` Ben Greear 2015-11-05 16:06 ` Johannes Berg 2015-11-05 16:21 ` Ben Greear 2015-11-05 16:25 ` Johannes Berg 2015-11-05 16:42 ` Ben Greear 2015-11-20 12:05 ` Johannes Berg 2015-11-20 16:04 ` Ben Greear
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.