Return-path: Received: from mgw-sa02.nokia.com ([147.243.1.48]:26694 "EHLO mgw-sa02.nokia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755479Ab0JFE7k (ORCPT ); Wed, 6 Oct 2010 00:59:40 -0400 Subject: RE: [PATCH 24/25] wl1271: Optimize scan duration From: Juuso Oikarinen To: "ext Gabay, Benzy" Cc: "Coelho Luciano (Nokia-MS/Helsinki)" , "linux-wireless@vger.kernel.org" In-Reply-To: <676FD6AA0F002F49B89E70F0C5EFD22C135AD3CB17@dlee04.ent.ti.com> References: <1285576669-8070-1-git-send-email-luciano.coelho@nokia.com> <1285576669-8070-25-git-send-email-luciano.coelho@nokia.com> <676FD6AA0F002F49B89E70F0C5EFD22C135AD3C603@dlee04.ent.ti.com> <1286257254.11177.224.camel@wimaxnb.nmp.nokia.com> <676FD6AA0F002F49B89E70F0C5EFD22C135AD3CB17@dlee04.ent.ti.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 06 Oct 2010 07:59:21 +0300 Message-ID: <1286341161.11177.254.camel@wimaxnb.nmp.nokia.com> Mime-Version: 1.0 Sender: linux-wireless-owner@vger.kernel.org List-ID: Hi, On Tue, 2010-10-05 at 17:42 +0200, ext Gabay, Benzy wrote: > Juuso, > > > > > > > > From: Juuso Oikarinen > > > > > > > > Currently then dwell times for each channel in scans is set to an > > > > overly > > > > long value, and excessive number of probe-requests are transmitted > > on > > > > each > > > > channel (for active scans.) > > > > > > > > Based on testing, comparable results can be received with smaller > > > > dwell-time, > > > > and, with fever probe-requests - in fact, reducing the number of > > probe- > > > > requests > > > > to 2 seems to increase the number of found results. > > > > > > I think that this does not making any sense. Less prob requests > > should give you back less results. As less beacons/prob responses are > > getting back to the station. > > > I think also that office with 70 AP is not a normal environment to > > test and optimize numbers. > > > I would suggest to re-test in a 1-6 AP environment which is making > > more sense for both home and enterprise environment. > > > > We have actually performed more testing than just mentioned here, in > > varied environments, and all of the testing seems to indicate that > > reducing the number of probe-reqs per channel is not reducing the > > number > > of acquired results. Instead, in some scenarios, it is increasing the > > number of acquired results. > > > > >> I don’t know if that is conventional request: can you share the full results and setup details? No, I don't have any formal documentation to share. The setup details are simple enough though. The tested this on command line using a simple script that flushes existing scan results, then performs two or three scans counting the number of scan results on the last round using grep and wc. We performed the testing in office environment and a shielded chamber, which only has selected AP's within it. Between test rounds we modified the driver parameters related to scanning, i.e. we modified the number of probe-reqs and the dwell time on each channel. -Juuso > > We did not see reduction in the probability of finding a specific AP in > > a few (one or two) AP environment either. > > > > The effect seems to be this way because reducing the number of > > probe-req's dramatically reduces the noise generated by probe-responses > > from AP's on neighbouring channels. > > > > -Juuso > >