On Fri, Jan 24, 2014 at 7:19 AM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > On Tue, 2014-01-07 at 09:04 -0800, Paul Stewart wrote: > > > I've seen situations where it'd be useful to distinguish in user-space > > between scan types. Here are a few scenarios: > > > > - Scanning for geo-location while associated (low-priority scan, tolerant > > to delayed/incomplete results, definitely not intended to interrupt or > > delay any inbound data traffic) > > - Background scan. If there is traffic during the scan, we should abort > > (NL80211_SCAN_FLAG_LOW_PRIORITY should help with this). If there is > > a history of traffic (e.g, an active data transfer) we might want to flag > > further that this scan should have shorter-than-usual dwell times as above. > > This makes sense, I'm not sure the first is all that much different from > the second, though the precise meaning of "low priority" isn't all that > well defined. > > > - User-initiated scanning while idle in extremely congested networks > > (may need to actually wait a full beacon interval on each channel since > > the APs contend with each other to respond to probe requests -- user > > initiated, so it behooves us to get a complete list). > > That's an interesting situation, but I'm not sure how you'd ever detect > which channels are extremely congested? Off the top of my head, I suppose one could devise a heuristic based on the ratio of beacons to probe-responses received on channel. Also, some drivers support the "channel busy time" or some such measure in the survey results. > > > johannes > -- 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
