On 11/10/2010 1:42 PM, Juuso Oikarinen wrote:
On Wed, 2010-11-10 at 12:36 +0100, ext Gery Kahn wrote:
On 11/10/2010 01:21 PM, Juuso Oikarinen wrote:
On Wed, 2010-11-10 at 12:18 +0100, ext Gery Kahn wrote:
On 11/10/2010 12:27 PM, juuso.oikarinen@xxxxxxxxx wrote:
From: Juuso Oikarinen<juuso.oikarinen@xxxxxxxxx>
This reverts commit fa21c7a9e4be439e217fe72edbd39b643b643791.
The reverted patch caused more harm than benefit.
Signed-off-by: Juuso Oikarinen<juuso.oikarinen@xxxxxxxxx>
Just couple words what harm it was?
The harm is that the supported channels are reported to user-space in
the order they are registered in the driver. The result of that is quite
messy in userspace PoV.
-Juuso
Thank you for answer.
The reason of doing such channel sorting was channel overlapping.
Let's say for 11a (bandwidth 20MHz) it is not a problem.
While 11g, preferred channel sorting would be 1,6,11,...
Gery
Yes, this is why we had this reordering in the first place.
One benefit of sorting channels would be to get faster results for the
whole band, as there are responses from the overlapping channels too.
Another benefit is to have max band coverage with minimum prob reqs.
The overlapping answers have collisions, which discard all packets and
if timeout scan -
no responce from AP or even silence in channel.
Currently the the scanning code however waits for all channels to be
scanned before sending results to userspace, so this benefit is not
utilized, and removing this patch makes no difference in that sense.
To take advantage of channel reordering, some other changes are needed
too. And the reordering needs to be performed in the mac80211/cfg80211
level (I actually earlier submitted a RFC patch doing just this.)
-Juuso
--
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
--
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
