Hello there,<br>Iīm writing you from Plan Ceibal - Uruguay. Here Iīve been doing some test on this subject trying to see what was happening with this "jumping" of the XO from one to another AP.<br><br>Basically what I did was configure two AP with identical SSID, so the XO would see them both under the same balloon. The APīs were distribute in the testing room so that I would have basically 4 regions:<br>
<br> 1. one place were the signal strength seen by an XO from both AP was the same (-40 dBm).<br> 2. the same as before but with lower str (-52dBm).<br> 3. one place with signal isolation of 14dBm (one signal at 42dBm and the other one at 56dBm).<br>
4. one place with signal isolation of 40dBm (one signal at 18dBm and the other one at 58dBm).<br><br>After having the scenario prepared I put 60 XO (with 801) making some traffic to the server and start monitoring, on one XO in each region, the MAC (from the AP) to witch they were associated.<br>
<br>Basically the results in this was that in regions 1, 2 and 3 the jumping was about 50 % of the time, staying something between 30 seconds to 20 min in the same AP. In region 4, 90% of the time the XO stayed on the same AP.<br>
<br>In other words I agree on you with the no smart dynamic selection on terms of quality of signal by the XO. I really donīt know yet the reason but it happens.<br><br>I didnīt check the blocks in the ~/,sugar/default/nm/networks.cfg, but as soon as I can run some more tests on this Iīll keep an eye on this.<br>
<br>I wasnīt able to find data witch allow me to say if the throughput was affected because of this behavior (I suspect that would be some decrease on congested nets), but I donīt like to have in a school half of the XO moving from an AP to another all the time. This kind of behavior I think would produce dynamical congestion in the net, basically because when many XO jumps to the same AP this is not going to be able to manage all that much connections and throughput, then the XO are going to keep trying and suddenly they will start connecting to the other. What Iīm afraid of is a mass effect, in witch big blocks of XO go from one to another AP sub-employing one of the AP and overcharging the other.<br>
<br>We expect to have more chances to study this problems, but now we need to move on, so meanwhile we are planing to use different SSID for different channels and keep a design in witch equal channels donīt step on each other.<br>
<br>Hope this help the rest of you on your own tests <br><br>If there is any suggestion on how to fix this, I will gladly run the tests and try it but wright now we are not sure were to search for this solution.<br><br>Keep up the spirit that a solution may appear for this.<br>
<br>Bye<br><br>Andres Nacelle<br>
<br><br>
<br>
<br><br>