On Thu, 2014-01-09 at 17:23 +0100, Laudin Alessandro Molina T wrote: > As M. Stewart said in a previous mail, there are some scenarios where > the scanning algorithms depends on the application priorities, to add > another examples: > > - A mobile station is moving (for example someone is walking on the > street with some available community networks) so, to take advantage > of an eventual connection the scanning needs to be very fast, then it > might need a list of candidate APs ASAP, no matter if the list in > incomplete. In this scenario the values for Min/MaxChannelTime should > be short enough to accomplish time restrictions. > > - On the other side, the same station could arrive to one specific > place (for example an office or home) so the user might prefer the > full AP list, so it could choose to connect to the best one. I'm not convinced that the completeness of the scan list would be the main concern here. Additionally, it will be difficult for anyone to tell whether the device is moving or not. I think for this particular use case, trying to adjust dwell times is probably not a good idea. Having some form of continuous background scan, so a roaming candidate is always available, would probably be a better solution to the first scenario. As far as the second scenario goes, the user is probably not connected anyway, and in that case most devices/drivers wouldn't really be concerned with traffic (which usually drives optimisations.) > > Agreed. I was thinking of adding some limits on how large a value could > > be set, but could not come up with any specific, justifiable value. (And > > the standard was not very helpful either with the "N/A" as the valid > > range ;-). > > We have seen Probe Responses arriving after 300ms, although in a city > center spontaneous deployment ~90% of the Probe Responses arrive > before 50ms. Anyway, I would only suggest to check for positive > values. 300ms is far too long for that AP to be useful at all, most likely :) > Another questions: > > - What about IEEE80211_PROBE_DELAY (Probe Delay)? Why won't allow to > adjust this value? I'm not sure about the definition/use of this > delay. Could any of you help me with an explanation of this? We don't have proper CCA in software scans, so this is needed. It's fairly implicit in the standard, but you can find it (somewhere) 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
