[Olsr-dev] OLSR on OLPC?

[Aaron Kaplan]

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:
>
ok

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

yup.

>
>  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  
bandwidth.
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.

Thanks.

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.

a.