Search Linux Wireless

RE: [PATCH 24/25] wl1271: Optimize scan duration

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Juuso,


> Sent: Tuesday, October 05, 2010 11:59 PM
> 
> Hi,
> 
> On Tue, 2010-10-05 at 17:42 +0200, ext Gabay, Benzy wrote:
> > Juuso,
> 
> > > > >
> > > > > From: Juuso Oikarinen <juuso.oikarinen@xxxxxxxxx>
> > > > >
> > > > > 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


Sounds great. Just one more: which AP brands (excluding Cisco) ?



> 
> > > 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
> > >
> 

ÿô.nlj·Ÿ®‰­†+%ŠË±é¥Šwÿº{.nlj·¥Š{±ÿ«zW¬³ø¡Ü}©ž²ÆzÚj:+v‰¨þø®w¥þŠàÞ¨è&¢)ß«a¶Úÿûz¹ÞúŽŠÝjÿŠwèf



[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux