[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
books.
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
think...
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
you.
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
needed.
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 127.0.0.1
More information about the Olsr-dev
mailing list