[Olsr-dev] OLSR on OLPC?

Aaron Kaplan (spam-protected)
Thu Jun 5 16:42:50 CEST 2008

Hi Scott!

On Jun 4, 2008, at 7:26 PM, C. Scott Ananian wrote:

> The OLPC XO-1 has really nice and spiffy 802.11s hardware.
yes! :)

> Unfortunately, we're having some difficulty actually making it scale
> properly in dense or high-traffic scenarios.  I'm interested in:

>  a) consulting with you folks, who seem to have actual real-world
> experience deploying large scale mesh networks,


>  b) actually deploying olsrd as a fall-back mechanism on the XO --
> giving up the power benefits of running 802.11s autonomously in the
> wireless chip in exchange for perhaps better behavior in some
> scenarios,
>  c) finding out how well you are scaling these days: multiple  
> hundreds of nodes?

600+ in Vienna, 800+ (or more?) in Berlin, AFAIK ~ 2000 in Athens
(wind.awmn.net/?page=nodes) ((note: they also employ BGP AFAIK. Maybe  
Acinonyx can tell us more about it).
Anyway, olsrd now uses ~ <1% - 20% percent CPU in the 600+ Vienna  
mesh on a 200Mhz linksys (depends on the edgedegree). On my iPhone it  
uses < 1% CPU.

So we are very certain that it scales up. This *has* been the main  
critique point in the past against olsrd. But it is fixed now
thanks to Hannes and Henning and Bernd and Sven-Ola.

>  d) discovering your experience with OLSR in dense networks: if I put
> 100 machines in a single room running olsrd, does the network break
> down due to discovery traffic?

you will have a layer 1 problem anyway in one single room. The  
problem is the amount of interference.
I am pretty sure that this does not change - unless you use more  
2.4Ghz has just that many channels.

>  e) do you separate data and control traffic?  If not, do you have
> problems with interference causing routing instabilities under high
> traffic conditions?
Yes! (hehe, Henning probably did not know that).
In addition in the freifunk firmware olsr traffic is prioritized via tc.
(sven-ola : correct me if I have old info here). As Nortel already  
pointed out: yes, something like that is very reasonable to have.

>   f) your thoughts on the OLSR extensions to the 802.11s standard: are
> they worth implementing, or did you need to tweak the standard OLSR
> protocol to make it work in real life?

yes, olsr from olsr.org had a few extensions implemented over the years:
1) ETX from MIT roofnet .
2) hazy sighted link state routing from BBN/CUWin.net (a.k.a.  
"fisheye"): this tells a node that it should not send topology  
control packets all the time to all other nodes but more often to the  
immediate vicinity (TTL=1), less often to the outer rings (TTL=2, 4)  
and very seldomly to everyone (TTL=max).

New extensions are planned and under heavy discussion :))

>  g) the media access protocol in standard 802.11 doesn't seem to scale
> much past 30-or-so nodes wanting to talk at the same time.  Have you
> run into this problem in dense deployments?
correct. That is why we use also 802.11a in addition :))
we want it all (frequencies) , we want it all (bandwidth) and we want  
it now (dear FCC).


There is no other magic extension to the MAC afaik. Except some hacks  
to keep it from splitting into different BSSID cells .

>  h) there's some talk on the wiki about a new v2 rfc for olsr -- is
> there some place I could look at the work in progress?  what
> particular challenges does it aim to tackle?
currently AFAIK everybody seems to be pretty much in favor of going  
towards RFC v2.

> Y'all seem to be doing great work, and I hope to start trying out
> olsrd on the XO builds, which at the least would give us a way to give
> non-XO-using developers a way to play with some of the mesh networking
> features of our software.


Well, I believe that 802.11s is pretty neat already for a classroom.  
I don't believe we could have done much better than Michails. But I  
do believe that a two layered approach - olsr as a backbone mesh and  
802.11s as a classroom mesh - can be pretty neat.
Also - since olsrd is on layer 3 (and will get some infos from layer  
2 in the long run), it is quite portable.

Use more frequencies! That will solve most of your trouble.


More information about the Olsr-dev mailing list