[Server-devel] [XSCE] Large groups of XO-1 do not work with access points

Samuel Greenfeld samuel at greenfeld.org
Fri Feb 7 19:43:37 EST 2014


I would also point out that if you have 20+ clients at a location you
should consider using commercial or enterprise-grade access points.

Companies like Aruba Networks make APs which each can contain multiple
radios, and support handing off clients between radios and access points
depending on available load.

This functionality does not come cheap.  The last time I talked to someone
from Aruba at a trade show their cheapest access point that could
self-configure itself with others on the same network (to avoid paying for
a centralized controller) was a few hundred dollars per AP.



On Fri, Feb 7, 2014 at 5:22 PM, James Cameron <quozl at laptop.org> wrote:

> On Fri, Feb 07, 2014 at 09:29:46AM -0500, Tim Moody wrote:
> > [Don't forget that James wrote:]
> > >If you choose to deploy with interfering channels for some reason,
> >
> > Many routers support narrowing the band around channels.
>
> No, it is more correct to say that many routers support widening the
> band around channels, to achieve a higher data rate.
>
> Consider a spectrum; the X axis is frequency, the Y axis is signal
> strength.  The bandwidth of the transmitter is a curve shaped like a
> hill.  The bandwidth of the receiver is another curve.  The channel
> selects the centre X position of the hill.
>
> The certification defines an area as a rectangle, and routers and
> devices pass certification based on spectrum analysis of the
> transmission, not of reception.
>
> There is always an interference between all channels, but the standard
> defines the limits on the interference in quantifiable terms.  But
> these can be translated simply as:
>
> - the interference between 1 and 11 is trivial,
>
> - the interference between 1 and 6 is low,
>
> - the interference between 1 and 2 is significant.
>
> - the interference between 1 and 1 is extreme.
>
> The interference causes backoff, where a node that would transmit
> waits a bit longer, and collisions, where a node receives a corrupted
> transmission.  Both of these act to reduce total system data
> bandwidth.
>
> Given fixed channels, the interference increases as the distance
> between the interfering devices decreases.
>
> > Are you of the opinion that this is ineffective and that there is
> > always a 5 channel overlap?
>
> I'm of the opinion that widening the bandwidth used around channel 6
> will impact channel 1 more.
>
> > Of course, we do not always have control over the entire
> > environment, so 1, 6, and 11 may already be taken and we have no say
> > in the matter.
>
> It is more complex than that.  While you might see another access
> point on a channel, you might still be able to deploy your own access
> point on the same channel, and the two access points will cooperate in
> a limited fashion.  They listen before they transmit.  So too do the
> laptops.  The TCP/IP rates are reduced.
>
> If you are faced with 1, 6, and 11 all taken, and you wish to run
> one access point, then find which of 1, 6 and 11 have the least
> received power, and use that.
>
> If you are faced with 1, 6, and 11 all taken, and you wish to run two
> access points, then find which two of 1, 6 and 11 have the least
> received power, and use them.
>
> If you are faced with 1, 6, and 11 all taken, and you wish to run
> three access points, use 1, 6, and 11.
>
> If you wish to use a channel outside 1, 6, and 11, then you would do a
> more complex survey, to find the channel with the least received power
> for both your access point and your devices.  Then measure the TCP/IP
> rates you get.
>
> That survey is invalidated every time someone walks in with an Android
> or iOS phone or a portable hotspot; these act as an access point.
>
> --
> James Cameron
> http://quozl.linux.org.au/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/server-devel/attachments/20140207/315ae414/attachment.html>


More information about the Server-devel mailing list