[Server-devel] Testing 200 XO's in two weeks time for Nepal's pilot

[Michail Bletsas]

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 model
> that meets this criteria?

Bryan,

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 stock
> >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 previous
> question, is their an off-the-shelf AP where WDS can be disabled w/out
> 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 just
> 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 great
> distances. Is this dream currently not a reality? If it is not currently
> a reality, when can we expect it to work?

When we started OLPC, we thought that the mesh would have two main uses:

* extending the range of access points (via multihopping)
* enabling p2p ad-hoc collaboration for small groups without any 
infrastructure

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 
interface.
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 so
> 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.


M.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/server-devel/attachments/20080305/84490518/attachment.htm