[Commotion-discuss] HIgh volume performance

Ben West ben at gowasabi.net
Fri Mar 20 14:26:15 EDT 2015


I'm afraid the beacon interval tip is entirely empirical, anecdotal, and
likely apocryphal.  The reasoning is that common wifi client
implementations (i.e. driver in your phone or laptop) will wait some round
number of ms (10, 50, 100) after an unsuccessful connection attempt to the
AP and try again.  There really isn't a specific reason I'm aware to set
the interval to a round number, besides basically "not too often to chew up
airtime and not too seldom so that clients miss beacons."

Conference venues tends to present all the worst case conditions, i.e.
quickly slapped together and poorly tuned wifi AP deployment, along with
*many* simultaneous (and impatient) clients wanted to connect.

The proposed sequence of events to channel collapse is ...

1. A group of conference attendants complain they can't connect
2. Conference organizer reboots the AP, while all attendants' client radios
remain on
3. The AP broadcasts the first beacon to all listening clients, some of
whom promptly try to connect roughly at the same time, with some failing
4. The failing clients wait whatever interval their implementation
dictates, with a good chance of their subsequent attempts becoming
synchronized
5. The AP beacons a second time, now with a sporting chance of that event
aligning with a multiple of the wait time of the unconnected clients, who
try again (at roughly the same time)
6. Additionally, those clients who didn't see 1st beacon do see the 2nd
beacon, and they jump on the bandwagon too
7. This situation worsens, conference attendants complain again, the AP is
rebooted again
8. Rinse, lather, repeat

The theory is that setting the beacon interval to not coincide with a
multiple of clients' assumed wait time helps avoid progressing from step 4
to 5.


On Fri, Mar 20, 2015 at 12:50 PM, Adam Longwill <adam.longwill at metamesh.org>
wrote:

> Ben,
>
> Can you elaborate on this prime number beacon timing phenomenon? What
> terminology should I use to read more about this? tBeacon interval syncing
> among clients?
> like this? http://www.dslreports.com/forum/remark,14241618
>
> On Fri, Mar 20, 2015 at 1:45 PM, Ben West <ben at gowasabi.net> wrote:
>
>> Other helpful tips:
>>
>>    - Conference venue wifi will always suck, per some divine decree and
>>    despite mere mortals' best efforts.  It is best to accept this this fact
>>    and proceed with humility.
>>
>>    - Unless other list members indicate otherwise you likely will want
>>    to set unique SSIDs (Conference_AP1, Conference_AP2, ...) for all nodes to
>>    deter client roaming.  Commotion doesn't presently support moving a
>>    client's session from one node to another, so clients will be bounced back
>>    to the splash page if they associate with another node (i.e. unwittingly if
>>    roaming is permitted).  Making the SSIDs unique lets the clients knowingly
>>    associate with a new signal while moving thru the conference venue, so they
>>    can know to click thru the splash page again.
>>
>>    - Per a tip from a McAfee employee unwillingly conscripted to deploy
>>    conference wifi, try setting the beacon interval to some prime number, e.g
>>    337ms or better yet 97ms.  This is the "beacon_int" option available in
>>    advanced wifi config under OpenWRT.  The theory is that having the nodes
>>    beacon at a weird interval will deter clients from accidentally
>>    synchronizing with each other in their attempts to connect, which can
>>    happen in very crowded environments and cause channel collapse.
>>
>>
>> On Fri, Mar 20, 2015 at 12:32 PM, Grady Johnson <
>> grady at opentechinstitute.org> wrote:
>>
>>> Hi David!
>>>
>>> Totally agree with Adam and Ben's advice.
>>>
>>> Please let us know how it works out. We'd love to feature your
>>> experience on the Commotion site!
>>>
>>> On 03/20/2015 01:19 PM, David Banks wrote:
>>> > This has all been extremely helpful thank you all so much.
>>> >
>>> > On Fri, Mar 20, 2015 at 1:02 PM, Adam Longwill <
>>> adam.longwill at gmail.com>
>>> > wrote:
>>> >
>>> >> Agreed with Mr. West.
>>> >>
>>> >> On Fri, Mar 20, 2015 at 1:00 PM, Ben West <ben at gowasabi.net> wrote:
>>> >>
>>> >>> Echoing Adam's recommendation to distribute the load of 100+ clients
>>> over
>>> >>> multiple nodes set to non-overlapping channels, with each node wired
>>> back
>>> >>> to whatever gateway device with cat-5 lines.  That is, don't bother
>>> with
>>> >>> wireless meshing if you can avoid it.  A single 802.11 channel won't
>>> >>> sustain that many clients, much less the meshing OLSR traffic.  So,
>>> say 10
>>> >>> nodes spaced evenly throughout the conference venue, where
>>> immediately
>>> >>> adjacent nodes are set to furthest possible channels (e.g channel 1
>>> and
>>> >>> 11).  Apply similar reasoning for dual-band access points; adjacent
>>> devices
>>> >>> need to not have their radios on adjacent frequencies.
>>> >>>
>>> >>> Also, you probably will want to turn the TX power on each node *down
>>> as
>>> >>> much as possible*, as they will be operating in a very noisy
>>> environment
>>> >>> at close spacing.  RX sensitivity is preferred over trying to drown
>>> out
>>> >>> noise with TX power.
>>> >>>
>>> >>> Finally, you'd want generous RAM available on the access points, so
>>> that
>>> >>> the firmware can service many clients.  Something like UBNT Rocket
>>> M2 (64MB
>>> >>> RAM), UBNT UniFi AP (64MB RAM), or even TP-Link TL-WDR4300 (128MB).
>>> The
>>> >>> UBNT stuff would permit easier mounting on walls/poles, since the
>>> TP-Link
>>> >>> is only an indoor consumer-grade unit.
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Fri, Mar 20, 2015 at 10:32 AM, Adam Longwill <
>>> adam.longwill at gmail.com>
>>> >>> wrote:
>>> >>>
>>> >>>> There will be issues with any device accepting more than 35
>>> connection
>>> >>>> requests at a time due to the nature on 802.11 in general. You're
>>> going to
>>> >>>> have plenty of congestion with more than that and probably have
>>> hidden node
>>> >>>> problem issues without RTS/ CTS in that situation.
>>> >>>>
>>> >>>> Commotion is is OpenWRT with some configurations and OLSR running
>>> on the
>>> >>>> mesh interface which will reduce airtime overall. If anything, you
>>> should
>>> >>>> mitigate this by having multiple radios on multiple channels with
>>> ethernet
>>> >>>> meshing instead of a wireless mesh interface.
>>> >>>> On 20 Mar 2015 11:11, "David Banks" <david.adam.banks at gmail.com>
>>> wrote:
>>> >>>>
>>> >>>>> Hello Everyone,
>>> >>>>>
>>> >>>>> Has anyone  had experience using routers running commotion in high
>>> >>>>> volume, single building settings? I'm organizing a conference set
>>> for next
>>> >>>>> month and thought this would be an interesting application. Anyone
>>> know of
>>> >>>>> good commotion-compatible hardware that's capable of accepting 100+
>>> >>>>> connection requests at a time?
>>> >>>>>
>>> >>>>> --
>>> >>>>> -db
>>> >>>>>
>>> >>>>> _______________________________________________
>>> >>>>> Commotion-discuss mailing list
>>> >>>>> Commotion-discuss at lists.chambana.net
>>> >>>>> https://lists.chambana.net/mailman/listinfo/commotion-discuss
>>> >>>>>
>>> >>>>>
>>> >>>> _______________________________________________
>>> >>>> Commotion-discuss mailing list
>>> >>>> Commotion-discuss at lists.chambana.net
>>> >>>> https://lists.chambana.net/mailman/listinfo/commotion-discuss
>>> >>>>
>>> >>>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Ben West
>>> >>> http://gowasabi.net
>>> >>> ben at gowasabi.net
>>> >>> 314-246-9434
>>> >>>
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > Commotion-discuss mailing list
>>> > Commotion-discuss at lists.chambana.net
>>> > https://lists.chambana.net/mailman/listinfo/commotion-discuss
>>> >
>>>
>>> --
>>> Grady Johnson
>>> Open Technology Institute | New America
>>> @geekwrights
>>> D6AE 65CE 141B 8DBC 7B5F 99AA 6BCC 0833 8B28 833B
>>> _______________________________________________
>>> Commotion-discuss mailing list
>>> Commotion-discuss at lists.chambana.net
>>> https://lists.chambana.net/mailman/listinfo/commotion-discuss
>>>
>>
>>
>>
>> --
>> Ben West
>> http://gowasabi.net
>> ben at gowasabi.net
>> 314-246-9434
>>
>> _______________________________________________
>> Commotion-discuss mailing list
>> Commotion-discuss at lists.chambana.net
>> https://lists.chambana.net/mailman/listinfo/commotion-discuss
>>
>>
>


-- 
Ben West
http://gowasabi.net
ben at gowasabi.net
314-246-9434
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chambana.net/pipermail/commotion-discuss/attachments/20150320/ce356222/attachment.html>


More information about the Commotion-discuss mailing list