[XSCE] Re: Large groups of XO-1 do not work with access points

[Tim Moody]

Hi James,

These are valuable statistics.

Does it matter if the xo has previously connected to the ap and stored 
connection info?  Could we avoid the scan by pre-populating the connection 
info?  (I think you did this in tinycore.  This would also eliminate the 
variable of relying on NN to show us the AP.)

Since we are regularly reflashing, could we turn off mesh and prepopulate a 
connection to a standard SSID; in Haiti we used 'lekol'?  I have the 
impression that mesh must be turned off at each boot, so we would need to 
add something in the boot process.  Can you recommend the best place to do 
this.

If this strategy increases the likelihood of connection would it be possible 
to get fancier and have our boot script check for a connection to the known 
ap and if not found turn mesh back on?

Tim

>-----Original Message----- 
>From: James Cameron
>Sent: Friday, February 07, 2014 8:16 PM
>To: xsce-devel at googlegroups.com
>Cc: server-devel ; OLPC Devel
>Subject: [XSCE] Re: Large groups of XO-1 do not work with access points
>
>There seems to be a lot of speculation, so I'll add more technical
>details on what Terry and I have been investigating.
>
>1.  sometimes, an active scan by the XO-1 does not have the access
>point listed in the scan results, despite the XO-1 transmitting an
>acknowledgement to the access point,
>
>2.  an active scan by the XO-1 is done only twice during boot before
>Sugar starts, and is repeated every 30 seconds,
>
>3.  if these two active scans do not contain the access point, Sugar
>waits 10 seconds before it decides that we don't have any access point
>available, and commits to using mesh.
>
>Therefore all it takes is for two active scans to miss the access
>point.  This can be easily reproduced with "sudo iwlist eth0 scan" and
>looking at the "Last beacon" time for the access point.
>
>--
>
>The probability of failure in step 1 has considerable variance across
>the test populations.  Here are some determinants:
>
>a.  the probability varies by access point, even the same model access
>point with the same firmware.  We see an extreme variation across
>access points.  I see 5%, 23% and 32% with unused XO-1.  Terry sees
>worse with his used XO-1 stock.
>
>b.  the probability is higher if mesh is enabled in the firmware; my
>32% fail rate drops down to 5.8% by turning off mesh using lbs_mesh,
>and making no other changes.
>
>c.  the probability is higher if many XO-1 are present and connected.
>
>d.  the probability is higher if antennas or coax are broken (because
>the two antennas are used at different times).
>
>e.  the probability is much higher if there are other access points
>present on the same channel at some distance.
>
>f.  the probability is unchanged with or without encryption, with or
>without power limits on the access point, and with or without 802.11n
>enabled.
>
>I'm interested to know if anybody has any ideas as to what else to
>vary in the experiments.
>
>The test method is to place "sudo iwlist eth0 scan" in a loop, with a
>five second repeat cycle, and count the number of scans where a
>previous scan result was used.  Here's an example test:
>
>--
>
>#!/bin/bash
>MA=5C:63:BF:D8:F6:C0
>while true; do
>    T0=$(date +%s)
>    if [[ $(( $T0 % 5 )) != 0 ]]; then
>        sleep 0.1
>        continue
>    fi
>    R0=$(sudo iwlist eth0 scan 2>/dev/null | awk "BEGIN{x=0;m=1} 
> /$MA/{x=1;m=0} /Last beacon/{gsub(\"ms\",\"\"); if (x) print \$4} /IE: 
> Unknown/{x=0} END{if(m) print \"missed\"}")
>    if [[ "$R0" == "missed" ]]; then
>        echo missed
>        sleep 3
>        continue
>    fi
>    echo $T0 $R0
>    echo $T0 $R0 >> scan.log
>    sleep 3
>done
>
>--
>
>To generate the percentage failure:
>
>awk 'BEGIN {p=0;f=0} { if ($2 > 1000) { f++ } else { p++ } } END { print p, 
>f, f * 100 / p }' scan.log
>

-- 
Sig inserted by AutoHotkey ver. 1.1.11.01 (signature - first line)
WLMail QuoteFix -> http://www.dusko-lolic.from.hr/ (signature - second line)