Re: [SOFTMAC] Reduce scan dwell time
On Fri, Mar 24, 2006 at 11:28:05PM +0100, Johannes Berg wrote: On Fri, 2006-03-24 at 09:48 -0800, Jouni Malinen wrote: Is battery use more important than accuracy of results and the amount of time needed to perform the operation? You're going to be using *more* battery when doing a passive scan because the dwell time is much much larger, and you can't power down the rx component during scan. So much for a power issue. Is this issue resolved? Shall I merge David's patch? John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SOFTMAC] Reduce scan dwell time
On Mon, 2006-03-27 at 11:53 -0500, John W. Linville wrote: On Fri, Mar 24, 2006 at 11:28:05PM +0100, Johannes Berg wrote: On Fri, 2006-03-24 at 09:48 -0800, Jouni Malinen wrote: Is battery use more important than accuracy of results and the amount of time needed to perform the operation? You're going to be using *more* battery when doing a passive scan because the dwell time is much much larger, and you can't power down the rx component during scan. So much for a power issue. Is this issue resolved? Shall I merge David's patch? Yes, merge the patch. Dan - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SOFTMAC] Reduce scan dwell time
On Mon, Mar 27, 2006 at 12:24:37PM -0500, Dan Williams wrote: On Mon, 2006-03-27 at 11:53 -0500, John W. Linville wrote: On Fri, Mar 24, 2006 at 11:28:05PM +0100, Johannes Berg wrote: On Fri, 2006-03-24 at 09:48 -0800, Jouni Malinen wrote: Is battery use more important than accuracy of results and the amount of time needed to perform the operation? You're going to be using *more* battery when doing a passive scan because the dwell time is much much larger, and you can't power down the rx component during scan. So much for a power issue. Is this issue resolved? Shall I merge David's patch? Yes, merge the patch. Merged to the 'upstream' branch of wireless-2.6. Thanks! John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SOFTMAC] Reduce scan dwell time
On Thu, 2006-03-23 at 20:16 -0500, Dan Williams wrote: Ok, that's cool. Wasn't apparent to me from the initial message. But does that mean that softmac is doing the scanning with _probe_ requests on each channel? It's not doing passive scanning? Right. It's an active scan. -- dwmw2 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SOFTMAC] Reduce scan dwell time
On Fri, 2006-03-24 at 07:58 -0500, Dan Williams wrote: Ok, so why is softmac doing an active scan, per my previous email message? Why is it not doing passive scan for normal SIOCSIWSCAN like most every other driver? (to be honest, I'm not entirely sure what ipw is doing here, but I think its passive along with the rest of the drivers) Because no one bothered to fix it yet, and we needed active scanning for when you want to associate with a hidden network. johannes signature.asc Description: This is a digitally signed message part
Re: [SOFTMAC] Reduce scan dwell time
On Fri, 2006-03-24 at 14:08 +0100, Johannes Berg wrote: On Fri, 2006-03-24 at 07:58 -0500, Dan Williams wrote: Ok, so why is softmac doing an active scan, per my previous email message? Why is it not doing passive scan for normal SIOCSIWSCAN like most every other driver? (to be honest, I'm not entirely sure what ipw is doing here, but I think its passive along with the rest of the drivers) Because no one bothered to fix it yet, and we needed active scanning for when you want to associate with a hidden network. Well, that's an application-defined decision, NOT a driver decision. And if you want active scanning, then softmac needs to implement SIOCSIWMLME, not do it in SIOCSIWSCAN. Drivers don't know what the user's power settings and preferences are. And they shouldn't. Lets try to be consistent among drivers here, and not balkanize the already wireless driver situation more than it already is. I'm not objecting to softmac going upstream here, but there's got to be an understanding that softmac is doing the _wrong_ thing in SIOCSIWSCAN. And that eventually that wrong thing will be fixed. Again, if you want active scans, implement SIOCSIWMLME. Dan - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SOFTMAC] Reduce scan dwell time
On Thu, Mar 23, 2006 at 08:16:04PM -0500, Dan Williams wrote: fixed it. Active scanning has been out of vogue as the default scan method for like 2 years with wireless-tools/WE, I'm not sure why softmac thinks it should be different here. Active scanning takes more power anyway, since you have to power up the card to transmit the probe requests. That's why wireless-tools and Wireless Extensions switched to passive scanning. Can you please point to some documentation/email thread/etc. describing this preference to use passive scanning? I was not aware of such a preference and have assumed that active scanning would be the preferred default because it is quite a bit faster and provides more complete results. I'd have issues with softmac doing active scanning unless _specifically_ requested to do so, by using the SIOCGIWMLME with a iw_scan_req structure requesting IW_SCAN_TYPE_ACTIVE. But _only_ then... Normal SIOCGIWSCAN shouldn't do active scanning. SIOCGIWSCAN does not request scanning, SIOCSIWSCAN does.. I don't understand what SIOCGIWMLME would have to do with this. SIOCSIWSCAN can use an optional iw_scan_req to control scan request. If this data is not present, I would assume that the drivers would do whatever they want and in many cases I would expect this to be active scan. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SOFTMAC] Reduce scan dwell time
On Fri, 2006-03-24 at 08:28 -0800, Jouni Malinen wrote: On Thu, Mar 23, 2006 at 08:16:04PM -0500, Dan Williams wrote: fixed it. Active scanning has been out of vogue as the default scan method for like 2 years with wireless-tools/WE, I'm not sure why softmac thinks it should be different here. Active scanning takes more power anyway, since you have to power up the card to transmit the probe requests. That's why wireless-tools and Wireless Extensions switched to passive scanning. Can you please point to some documentation/email thread/etc. describing this preference to use passive scanning? I was not aware of such a preference and have assumed that active scanning would be the preferred default because it is quite a bit faster and provides more complete results. I'd have issues with softmac doing active scanning unless _specifically_ requested to do so, by using the SIOCGIWMLME with a iw_scan_req structure requesting IW_SCAN_TYPE_ACTIVE. But _only_ then... Normal SIOCGIWSCAN shouldn't do active scanning. SIOCGIWSCAN does not request scanning, SIOCSIWSCAN does.. I don't Right, typo on my part. Had considered sending mail correcting this, but that would have been pointless for 1 word. understand what SIOCGIWMLME would have to do with this. SIOCSIWSCAN can use an optional iw_scan_req to control scan request. If this data is not present, I would assume that the drivers would do whatever they want and in many cases I would expect this to be active scan. My fault here too. In my quick reading of wireless.h, I confused some of the comments regarding iw_scan_req and SIOCSIWSCAN. So you're correct here, that iw_scan_req should be used with SIOCSIWSCAN, and my comments about MLME are wrong. However, the problem with active scanning is that you have to power up the transmit components of the radio, while passive scanning, even though it takes a bit longer, doesn't necessarily require that. Active scanning takes more power. So what I'm arguing for here is that drivers should _default_ to passive scanning when given a scan request with no scan type information. But they should be able to do so when they get a request for an active scan using IW_SCAN_TYPE_ACTIVE. Drivers should default to using less power, and more only when the app requests so. However: It's somewhat unfortunate that wireless.h defines ACTIVE scan type as 0 since then, that's what non-WE-18 apps would inadvertently set. And apps that are power-aware would be setting that bit anyway. Most drivers that are FullMAC do passive scanning without sending probe requests, AFAIK, and so do OK here. In short, since WE already defines ACTIVE to be 0, and we're not going to change that, consider my arguments here withdrawn. We should just note that if an application wants the card to be power-conservative, that the _app_ needs to set the correct bits in the scan. Were ACTIVE defined as 1, the story would be different, but it's not. So be it. Dan - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SOFTMAC] Reduce scan dwell time
On Fri, Mar 24, 2006 at 12:38:40PM -0500, Dan Williams wrote: However, the problem with active scanning is that you have to power up the transmit components of the radio, while passive scanning, even though it takes a bit longer, doesn't necessarily require that. Active scanning takes more power. For some class of devices, that is certainly correct. For other classes, it does not really matter much (e.g., my laptop has large enough battery for me not to care about active scan). So what I'm arguing for here is that drivers should _default_ to passive scanning when given a scan request with no scan type information. But they should be able to do so when they get a request for an active scan using IW_SCAN_TYPE_ACTIVE. Drivers should default to using less power, and more only when the app requests so. Is battery use more important than accuracy of results and the amount of time needed to perform the operation? It's somewhat unfortunate that wireless.h defines ACTIVE scan type as 0 since then, that's what non-WE-18 apps would inadvertently set. And apps that are power-aware would be setting that bit anyway. Most drivers that are FullMAC do passive scanning without sending probe requests, AFAIK, and so do OK here. Please note that this field is in struct iw_scan_req and non-WE-18 apps do not know about that in the first place. In other words, it does not really matter what the value of IW_SCAN_TYPE_ACTIVE is.. The only open question I see here is what should happen if struct iw_scan_req is not included and my current understanding is that the driver is allowed to do either active or passive scanning based on its default and I just happen to think that the default would more likely be active scanning unless somehow (driver specific parameter) it has been modified to do something else. Have you actually observed that FullMAC drivers are using passive scanning (i.e., used a wireless sniffer to see what they are doing)? Most drivers I've looked at at this level are sending out probe request frames.. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: [SOFTMAC] Reduce scan dwell time
Jouni Malinen wrote : On Thu, Mar 23, 2006 at 08:16:04PM -0500, Dan Williams wrote: That's why wireless-tools and Wireless Extensions switched to passive scanning. Can you please point to some documentation/email thread/etc. describing this preference to use passive scanning? I was not aware of such a preference and have assumed that active scanning would be the preferred default because it is quite a bit faster and provides more complete results. I was scratchig my head over that one, I'm glad I'm not the only one. Prior to WE-18, the API did not specify anything, so it was left to the discretion of the driver/card. With WE-18, you can specify what you want, but most apps don't, so effectively we are in the pre-WE-18 situation. I think that active scanning is preferred is most case because it's faster. The power issue is likely overblown, as scanning doesn't occur that frequently and generate a minimal number of packets. If scanning had a real impact on power, it would have the same impact on throughput, and people would complain about it (I almost wrote a paper on the parallel between power and throughput optimisation). The first type of card are cards that do scanning in the background. Thos cards need to interrupt traffic on a periodic basis to perform scanning, the less time they spend scanning, the less impact it will have on throughput and latency. If the card detect that there is no traffic, it could use passice scanning. The second type of card are cards that don't do scanning in the background. In that case, scanning is triggered at the time of the request, and both the user and the app are waiting for the result (well, except those wasteful apps that do periodic scans). You don't want the user to wait. Jouni Malinen wrote : On Fri, Mar 24, 2006 at 12:38:40PM -0500, Dan Williams wrote: However, the problem with active scanning is that you have to power up the transmit components of the radio, while passive scanning, even though it takes a bit longer, doesn't necessarily require that. Active scanning takes more power. For some class of devices, that is certainly correct. For other classes, it does not really matter much (e.g., my laptop has large enough battery for me not to care about active scan). Thinking about it some more... In most cards, the difference of power consumption between Tx and Rx is not that much, less than an order of magnitude. Unfortunately, my link to number is 404. If you do active scanning, you are done much faster and thefore can switch your receiver off and go back to full power saving much earlier. Which means that you may actually consume less power... Let pull hypothetical numbers, for the sake of the argument, let say Tx = 1W, Rx = 200mW, idle = 20mW. Let say active scanning is 20ms per channel (2ms Tx, 18ms Rx), passive scanning is 200ms per channel. Let say we scan 10 channels. Over a 2 sec period, active scanning is 72mW. Over a 2 sec period, passive scanning is 200mW. Actually, it's a well known fact that in wireless networking, it's not Tx that kill your battery, but Rx. Have fun... Jean - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: [SOFTMAC] Reduce scan dwell time
On Fri, Mar 24, 2006 at 03:38:50PM -0500, Dan Williams wrote: On Fri, 2006-03-24 at 12:12 -0800, Jean Tourrilhes wrote: Jouni Malinen wrote : On Thu, Mar 23, 2006 at 08:16:04PM -0500, Dan Williams wrote: That's why wireless-tools and Wireless Extensions switched to passive scanning. Can you please point to some documentation/email thread/etc. describing this preference to use passive scanning? I was not aware of such a preference and have assumed that active scanning would be the preferred default because it is quite a bit faster and provides more complete results. I was scratchig my head over that one, I'm glad I'm not the only one. Don't worry, it's hard not to scratch your head when somebody (ie, me) is on large amounts crack. Want some? It makes everything so much clearer :) Dan We are all bringing different expertise and viewpoint to the party, which are often complementary. Don't underestimate what you have achieved, you have contributed a lot in term of normalising the API between drivers and user-space. All this wireless stuff is quite tricky. Jean - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SOFTMAC] Reduce scan dwell time
On Fri, 2006-03-24 at 09:48 -0800, Jouni Malinen wrote: Is battery use more important than accuracy of results and the amount of time needed to perform the operation? You're going to be using *more* battery when doing a passive scan because the dwell time is much much larger, and you can't power down the rx component during scan. So much for a power issue. johannes signature.asc Description: This is a digitally signed message part
[SOFTMAC] Reduce scan dwell time
It currently takes something like 8 seconds to do a scan, because we
spend half a second on each channel. Reduce that time to 20ms per
channel.
Signed-off-by: David Woodhouse [EMAIL PROTECTED]
--- linux-2.6.16.ppc/net/ieee80211/softmac/ieee80211softmac_priv.h~
2006-03-21 23:50:00.0 +
+++ linux-2.6.16.ppc/net/ieee80211/softmac/ieee80211softmac_priv.h
2006-03-22 11:20:26.0 +
@@ -176,7 +176,7 @@ static inline int ieee80211softmac_scan_
) || ieee80211softmac_scan_handlers_check_self(sm);
}
-#define IEEE80211SOFTMAC_PROBE_DELAY HZ/2
+#define IEEE80211SOFTMAC_PROBE_DELAY HZ/50
#define IEEE80211SOFTMAC_WORKQUEUE_NAME_LEN(17 + IFNAMSIZ)
struct ieee80211softmac_network {
--
dwmw2
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SOFTMAC] Reduce scan dwell time
On Thu, 2006-03-23 at 14:00 +, David Woodhouse wrote:
It currently takes something like 8 seconds to do a scan, because we
spend half a second on each channel. Reduce that time to 20ms per
channel.
Are we talking about (1) the active probe response timeout after
transmitting the probe frame, or (2) the default passive scan channel
dwell time?
If (2), I'd have to NAK this patch, as 20ms that seems really low. I
think most FullMAC drivers and firmware tend towards the 150 - 200ms
range for channel dwell time. I'm not entirely sure that's the number,
but that's what I've seen in a couple places.
For reference, the WRT54G's default beacon interval is 100ms. A more
enterprise class WLAN switch, the 3Com 3CRWXR10095A, has a default 90ms
beacon interval. It seems unlikely that that dwelling on a channel for
only 20ms while the AP's beacon is usually 100ms would yield
consistently useful results...
Dan
Signed-off-by: David Woodhouse [EMAIL PROTECTED]
--- linux-2.6.16.ppc/net/ieee80211/softmac/ieee80211softmac_priv.h~
2006-03-21 23:50:00.0 +
+++ linux-2.6.16.ppc/net/ieee80211/softmac/ieee80211softmac_priv.h
2006-03-22 11:20:26.0 +
@@ -176,7 +176,7 @@ static inline int ieee80211softmac_scan_
) || ieee80211softmac_scan_handlers_check_self(sm);
}
-#define IEEE80211SOFTMAC_PROBE_DELAY HZ/2
+#define IEEE80211SOFTMAC_PROBE_DELAY HZ/50
#define IEEE80211SOFTMAC_WORKQUEUE_NAME_LEN (17 + IFNAMSIZ)
struct ieee80211softmac_network {
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SOFTMAC] Reduce scan dwell time
On Thu, Mar 23, 2006 at 02:40:16PM -0500, Dan Williams wrote: On Thu, 2006-03-23 at 14:00 +, David Woodhouse wrote: It currently takes something like 8 seconds to do a scan, because we spend half a second on each channel. Reduce that time to 20ms per channel. Are we talking about (1) the active probe response timeout after transmitting the probe frame, or (2) the default passive scan channel dwell time? If (2), I'd have to NAK this patch, as 20ms that seems really low. I think most FullMAC drivers and firmware tend towards the 150 - 200ms range for channel dwell time. I'm not entirely sure that's the number, but that's what I've seen in a couple places. I'm going to pull this one out of wireless-2.6 for the time being as well. John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SOFTMAC] Reduce scan dwell time
On Thu, 2006-03-23 at 14:40 -0500, Dan Williams wrote: Are we talking about (1) the active probe response timeout after transmitting the probe frame, or (2) the default passive scan channel dwell time? If (2), I'd have to NAK this patch, as 20ms that seems really low. It's only (1). I consistently measured response times of within 1ms from my WAP54G. -- dwmw2 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
