[Olsr-dev] Freifunk Testing

L. Aaron Kaplan (spam-protected)
Sun Jun 15 13:20:14 CEST 2008

Elektra ,

==== re: emotional =====
I want to - since you discussed that publicly - clarify something  
about the batman/olsr bounty (old story) since there public  
accusations here.
1) I *tried* to help you batman folks with our olsr-ng grant (which  
we shared on a bounty principle with the world) since at that time I  
believed that you were working on something interesting.
I therefor tried to define it into our scope of work. 2) the work  
that you delivered was delivered *after* the financial closing of the  
The grant was already *over*. I *had* to present the final  
calculations and your work was not finished at that time.
And it was a bounty principle: the first one to deliver good work  
gets it. I tried to help you even afterwards but made no promise on  
it. Then Marek asked me again and I said - sorry: over, publish your  
draft just like that. And you did (which is ok).
So: this discussion is over. I believe you did not have the most up  
to date info. Ask Marek, Simon and or Axel they will be able to  
confirm this conversation.

Short answer: OLSR-NG bounty for batman? -> SORRY! You were too late.

BUT: the public accusations and emotions really don't belong here!
Presenting your experience and impressions as "facts" (MPR 7  
discussion, "olsr does not scale - to much CPU load", etc ) when  
actually it turns out that the problems observed in Berlin Freifunk  
were *implementation* deficiencies (which to a big part are fixed  
now) and not something intrinsically bad in olsrd, that makes me  

So, my proposal: get your FACTS together.
In case you have objections to something in olsrd: prove it! But get  
rid of the dogma and the personal attacks.

    Let the light of knowledge and reason shine in, be gone middle  
ages of "this works because it works" dogma!

    Because dogma leads to blind belief, followers and ignorance.
    And that I consider harmful. There is no single way , no silver  
bullet. There are multiple ways.

    We should be discussing technical things here - not your personal  
emotional outbreaks.

==== facts =====

Back to the facts.

1) CPU performance:

let me remind you that for example the high CPU load was considered
an "inherent" property of olsrd - it was "bad" and "olsr was bad" for  
Well, it turned out that once people looked at it with fresh eyes,  
that simply
the Dijkstra shortest path calculation was brilliantly inefficient  
until we fixed it.
Proof: It went from O(n^2) to O(n*log n)

Furthermore it was memory trashing (Bernd and Hannes solved a lot here)
and overall it had lots of places to be optimized. We now believe that -
in opposition to batman - olsr scales *much higher* (and the proof is  
in the production networks).

2) MPR 7 , spamming and amount of packets:

The next big step will be to reduce the amount of messages in the air  
(which you helped to create!
By setting MPR to 7 as default).

Hannes with his 10+ years of routing daemon experience proposed a  
very interesting solution: CSN
This will basically send over differences to routing tables only when  
This is IMHO the way to go. We need to reduce the number of messages  
in the air!
The spectrum is only that wide and we can only cramp a certain  
maximum number of bits/sec into the channels.
Proof: http://en.wikipedia.org/wiki/Shannon–Hartley_theorem

3) code cleanup:

So my main point of reason is that over the last 2 years over here  
people have been
cleaning up a big mess. And cleaning up involves very careful  
inspection, lots of testing, a *very* smart brain and the will to  
follow things thru and not to have a quick fix (which makes things  
worse in the long run).

=== ending part ===
Now your bashing of myself (as somebody who amongst others started to  
take an interest in olsrd
once tlopatic and andreto did not have time for it anymore) and of  
olsrd is pretty
awkward since it really is on a personal level and not objective.
Don't bash the folks who have achieved great progress, please!
I have no problem with the other folks from batman.

On Jun 15, 2008, at 9:26 AM, elektra wrote:

> Hi -
> yes, there is.
> http://zolder.scii.nl/~elektra/olsr-thomas-elektra-web-quality.pdf
> https://www.open-mesh.net/misc/optimized-link-state-routing-deamon/ 
> olsr-story.txt/view
> Fisheye was not introduced with HSLS, it was also present in MMRP
> (Mobile Mesh Routing Protocol) and possibly others.
> @Aaron: May I pick up the occasion and publicly remind you that you
> still owe 3000€ to the B.A.T.M.A.N. team for finalizing the IEEE  
> draft?
> I think that it is fine and justified to do so now, because everybody
> involved in that bounty has quietly given up on the money already. You
> were supposed to pay last year. At the CCC-Congress 2007/2008 you told
> us that you already had spent the money (on what?) and that we may get
> paid in January/February. And don't give me this 'Elektra is bashing
> OLSR'-shit again. Without the work that Thomas Lopatic and I  
> contributed
> OLSR wouldn't be as established as it is today. I think you and your
> ******* ego are messing up things big time.

> I have seen that presentation at the WCW 2008 with this embarrassing
> header "R.O.B.I.N= Routing Olsr Better Inside", that you made. Hey  
> man,
> OLSR is an old shoe, but it is not so bad that it would need such
> childish chicken-shit behavior.
> Couldn't resist - and not feeling sorry
> elektra
>> Hi
>> On Sat, Jun 14, 2008 at 10:47:01PM +0200, elektra wrote:
>>> Btw: There should be an option to disable the MPR algorithm  
>>> completely.
>>> It is superfluous anyway for Freifunk-like configurations since  
>>> Wizard
>>> of OS 2004. Setting MPR redundancy to 7 in the config is just a  
>>> dirty
>>> hack to get rid of the negative effects of  MPR selection and the
>>> problems that are growing out of it.
>> Is there somewhere we can read why/how MPR is bad for freifunk-like
>> configurations?
>> regards,
>> Jan
> -- 
> Olsr-dev mailing list
> (spam-protected)
> http://lists.olsr.org/mailman/listinfo/olsr-dev

there's no place like

More information about the Olsr-dev mailing list