On Wed, 2010-10-06 at 07:21 +0200, ext Gabay, Benzy wrote:
> 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) ?
In the office environment we have a variety of brands, including D-link,
Buffalo, Telewell, TP-link and linksys, cisco etc.
In the shielded chamber we are using linksys wrt610n AP's.
-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
> > > >
> >
>
> ï{.nï+ïïïïïïï+%ïïlzwmïïbïëïïrïïzXïï "ïï^ïÈïïïÜ}ïïïÆzï&j:+vïïïïïïïzZ+ïï+zfïïïhïïï~ïïïïiïïïzï ïwïïï?ïïïï&ï)ßf
--
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
