<div dir="ltr"><div><div><div><div><div><div><div><div><div><div>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."<br><br></div>Conference venues tends to present all the worst case conditions, i.e. quickly slapped together and poorly tuned wifi AP deployment, along with <b>many</b> simultaneous (and impatient) clients wanted to connect.<br><br>The proposed sequence of events to channel collapse is ...<br><br></div>1. A group of conference attendants complain they can't connect<br></div>2. Conference organizer reboots the AP, while all attendants' client radios remain on<br></div>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<br></div>4. The failing clients wait whatever interval their implementation dictates, with a good chance of their subsequent attempts becoming synchronized<br></div>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)<br></div>6. Additionally, those clients who didn't see 1st beacon do see the 2nd beacon, and they jump on the bandwagon too<br></div>7. This situation worsens, conference attendants complain again, the AP is rebooted again<br></div>8. Rinse, lather, repeat<br><br></div>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.<br><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 20, 2015 at 12:50 PM, Adam Longwill <span dir="ltr"><<a href="mailto:adam.longwill@metamesh.org" target="_blank">adam.longwill@metamesh.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Ben, <br><br></div>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?<br></div>like this? <a href="http://www.dslreports.com/forum/remark,14241618" target="_blank">http://www.dslreports.com/forum/remark,14241618</a><br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 20, 2015 at 1:45 PM, Ben West <span dir="ltr"><<a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Other helpful tips:<br></div><ul><li>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.<br><br></li><li>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.<br><br></li><li>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.<br></li></ul></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 20, 2015 at 12:32 PM, Grady Johnson <span dir="ltr"><<a href="mailto:grady@opentechinstitute.org" target="_blank">grady@opentechinstitute.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi David!<br>
<br>
Totally agree with Adam and Ben's advice.<br>
<br>
Please let us know how it works out. We'd love to feature your<br>
experience on the Commotion site!<br>
<span><br>
On 03/20/2015 01:19 PM, David Banks wrote:<br>
> This has all been extremely helpful thank you all so much.<br>
><br>
> On Fri, Mar 20, 2015 at 1:02 PM, Adam Longwill <<a href="mailto:adam.longwill@gmail.com" target="_blank">adam.longwill@gmail.com</a>><br>
> wrote:<br>
><br>
>> Agreed with Mr. West.<br>
>><br>
>> On Fri, Mar 20, 2015 at 1:00 PM, Ben West <<a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a>> wrote:<br>
>><br>
>>> Echoing Adam's recommendation to distribute the load of 100+ clients over<br>
>>> multiple nodes set to non-overlapping channels, with each node wired back<br>
>>> to whatever gateway device with cat-5 lines.  That is, don't bother with<br>
>>> wireless meshing if you can avoid it.  A single 802.11 channel won't<br>
>>> sustain that many clients, much less the meshing OLSR traffic.  So, say 10<br>
>>> nodes spaced evenly throughout the conference venue, where immediately<br>
>>> adjacent nodes are set to furthest possible channels (e.g channel 1 and<br>
>>> 11).  Apply similar reasoning for dual-band access points; adjacent devices<br>
>>> need to not have their radios on adjacent frequencies.<br>
>>><br>
</span>>>> Also, you probably will want to turn the TX power on each node *down as<br>
>>> much as possible*, as they will be operating in a very noisy environment<br>
<div><div>>>> at close spacing.  RX sensitivity is preferred over trying to drown out<br>
>>> noise with TX power.<br>
>>><br>
>>> Finally, you'd want generous RAM available on the access points, so that<br>
>>> the firmware can service many clients.  Something like UBNT Rocket M2 (64MB<br>
>>> RAM), UBNT UniFi AP (64MB RAM), or even TP-Link TL-WDR4300 (128MB).  The<br>
>>> UBNT stuff would permit easier mounting on walls/poles, since the TP-Link<br>
>>> is only an indoor consumer-grade unit.<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> On Fri, Mar 20, 2015 at 10:32 AM, Adam Longwill <<a href="mailto:adam.longwill@gmail.com" target="_blank">adam.longwill@gmail.com</a>><br>
>>> wrote:<br>
>>><br>
>>>> There will be issues with any device accepting more than 35 connection<br>
>>>> requests at a time due to the nature on 802.11 in general. You're going to<br>
>>>> have plenty of congestion with more than that and probably have hidden node<br>
>>>> problem issues without RTS/ CTS in that situation.<br>
>>>><br>
>>>> Commotion is is OpenWRT with some configurations and OLSR running on the<br>
>>>> mesh interface which will reduce airtime overall. If anything, you should<br>
>>>> mitigate this by having multiple radios on multiple channels with ethernet<br>
>>>> meshing instead of a wireless mesh interface.<br>
>>>> On 20 Mar 2015 11:11, "David Banks" <<a href="mailto:david.adam.banks@gmail.com" target="_blank">david.adam.banks@gmail.com</a>> wrote:<br>
>>>><br>
>>>>> Hello Everyone,<br>
>>>>><br>
>>>>> Has anyone  had experience using routers running commotion in high<br>
>>>>> volume, single building settings? I'm organizing a conference set for next<br>
>>>>> month and thought this would be an interesting application. Anyone know of<br>
>>>>> good commotion-compatible hardware that's capable of accepting 100+<br>
>>>>> connection requests at a time?<br>
>>>>><br>
>>>>> --<br>
>>>>> -db<br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> Commotion-discuss mailing list<br>
>>>>> <a href="mailto:Commotion-discuss@lists.chambana.net" target="_blank">Commotion-discuss@lists.chambana.net</a><br>
>>>>> <a href="https://lists.chambana.net/mailman/listinfo/commotion-discuss" target="_blank">https://lists.chambana.net/mailman/listinfo/commotion-discuss</a><br>
>>>>><br>
>>>>><br>
>>>> _______________________________________________<br>
>>>> Commotion-discuss mailing list<br>
>>>> <a href="mailto:Commotion-discuss@lists.chambana.net" target="_blank">Commotion-discuss@lists.chambana.net</a><br>
>>>> <a href="https://lists.chambana.net/mailman/listinfo/commotion-discuss" target="_blank">https://lists.chambana.net/mailman/listinfo/commotion-discuss</a><br>
>>>><br>
>>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Ben West<br>
>>> <a href="http://gowasabi.net" target="_blank">http://gowasabi.net</a><br>
>>> <a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a><br>
>>> <a href="tel:314-246-9434" value="+13142469434" target="_blank">314-246-9434</a><br>
>>><br>
>><br>
>><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Commotion-discuss mailing list<br>
> <a href="mailto:Commotion-discuss@lists.chambana.net" target="_blank">Commotion-discuss@lists.chambana.net</a><br>
> <a href="https://lists.chambana.net/mailman/listinfo/commotion-discuss" target="_blank">https://lists.chambana.net/mailman/listinfo/commotion-discuss</a><br>
><br>
<br>
--<br>
</div></div><span><font color="#888888">Grady Johnson<br>
Open Technology Institute | New America<br>
@geekwrights<br>
D6AE 65CE 141B 8DBC 7B5F 99AA 6BCC 0833 8B28 833B<br>
</font></span><div><div>_______________________________________________<br>
Commotion-discuss mailing list<br>
<a href="mailto:Commotion-discuss@lists.chambana.net" target="_blank">Commotion-discuss@lists.chambana.net</a><br>
<a href="https://lists.chambana.net/mailman/listinfo/commotion-discuss" target="_blank">https://lists.chambana.net/mailman/listinfo/commotion-discuss</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div>Ben West<div><a href="http://gowasabi.net" target="_blank">http://gowasabi.net</a><br><a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a><br><a href="tel:314-246-9434" value="+13142469434" target="_blank">314-246-9434</a><br></div></div>
</div>
</div></div><br>_______________________________________________<br>
Commotion-discuss mailing list<br>
<a href="mailto:Commotion-discuss@lists.chambana.net" target="_blank">Commotion-discuss@lists.chambana.net</a><br>
<a href="https://lists.chambana.net/mailman/listinfo/commotion-discuss" target="_blank">https://lists.chambana.net/mailman/listinfo/commotion-discuss</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">Ben West<div><a href="http://gowasabi.net" target="_blank">http://gowasabi.net</a><br><a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a><br>314-246-9434<br></div></div>
</div>