[Server-devel] Testing 200 XO's in two weeks time for Nepal's pilot
bryan.berry at gmail.com
Thu Mar 6 05:07:01 EST 2008
thanks Michailis, this was very helpful
On Wed, 2008-03-05 at 22:46 -0500, Michail Bletsas wrote:
> Bryan Berry <bryan.berry at gmail.com> wrote on 03/05/2008 03:07:12 AM:
> > Michailis, thanks for your quick reply
> > > small schools, the school server is all that you need. In the
> > > meantime, APs with controllable WDS behavior are recommended.
> > I am not an expert on access points. Can you suggest a particular
> > that meets this criteria?
> The problem is mostly obvious on consumer APs with Broadcom radios
> (the Linksys WRT54 being the most common) and is not an XO specific
> problem anymore.
> Any application that generates multicast traffic will trigger storms
> in environments where many such access points are deployed in the
> vicinity of each other.
> Most enterprise Access Points will work just fine because they allow
> for fine control of WDS.
> Since we assume a limited budget here, I will stick to consumer and
> prosumer grade gear.
> A good starting point should be the DLINK DWL-2100AP which uses an
> Atheros Chipset.
> > >The solution to that problem is to be able to turn off WDS. The
> > >Linksys firmware doesn't do it, however OpenWRT and its variants
> can do
> > >it.
> > I am not familiar w/ OpenWRT and its variants. Similar to my
> > question, is their an off-the-shelf AP where WDS can be disabled
> > having to load OpenWRT?
> The reason that I mentioned OpenWRT, DD-WRT etc. is that the Linksys
> WRT54Gx is the most popular AP that I know off.
> Avoiding them completely will be hard ;-) In many models (the ones
> with 8MB of RAM) loading DD-WRT is trivial.
> > To Mesh or not to Mesh?
> > Using regular access points, is there actually a mesh network at
> all? It
> > sounds like we are back to using a regular 802.11 g network. Jabber
> > emulates the features of a mesh over a regular network.
> Let's separate the mesh transport (802.11s-like layer-2 transport)
> from the collaboration middleware (jabber, avahi, telepathy).
> They are completely indepedent and as you point out the applications
> will run on any transport.
> > We were really excited about kids using the mesh to connect to the
> > Internet from their own homes to and each other via the mesh at
> > distances. Is this dream currently not a reality? If it is not
> > a reality, when can we expect it to work?
> When we started OLPC, we thought that the mesh would have two main
> * extending the range of access points (via multihopping)
> * enabling p2p ad-hoc collaboration for small groups without any
> We had the first scenario working very early on. Every time one XO
> connects to an AP, it acts as a gateway for other XOs via its mesh
> Then we disabled that functionality (by means of stopping the gateway
> script from running in the XOs - very easy to reenable) for a variety
> of reasons, the most important being that we wanted to focus on school
> server operation and having multiple gateways (MPPs - mesh portals)
> under the same roof, doesn't agree with the current state of the
> collaboration software.
> The second scenario works very well now for small groups (<10). Since
> it relies heavily on multicast and since the mesh currently implements
> multicast as a controlled flooding, it won't scale to larger numbers
> of nodes until we address one of the two (or better both) issues.
> Add to that the fact that the mesh is inherently more chatty due to
> its control traffic, and you realize that when you care about how to
> stuff the maximum number of nodes under one roof (pushing the limits
> of what people can do with WiFi in general), using the mesh where you
> can easily use access points is a very suboptimal choice. There is no
> need for multihopping inside the school.
> > Two Networks?
> > Should we use AP's for the school but then also use Active Antennas
> > that kids can connect to the Internet from home via the mesh?
> You could do that, you can also enable MPP functionality on the
> laptops, so that the kids who are closer to the school connect via
> WiFi to the school and via the mesh interface to other XOs downstream
> from them.
> What is ironic is that we didn't want to offer many choices to the
> users (so that they don't get confused) and that lack of control is
> giving us many headaches right now... People who are command-line
> jockeys can do very ellaborate setups with the XOs. We have to expose
> those capabilities to the GUI too.
More information about the Server-devel