[B.A.T.M.A.N.] IP Aggregation

[B.A.T.M.A.N.] IP Aggregation

[Marek Lindner]

Hi,

die folgende Idee ist auf dem Kongress in diversen Diskussionen entstanden und 
bei weitem noch nicht ausgereift. Mich würde eure Meinung dazu interessieren. 

Bisher rebroadcastet jeder batman Knoten alle batman Pakete (wir ignorieren 
die Ausnahmen jetzt mal). Können wir einen geschickten Algorithmus 
entwickeln / anwenden, der es uns gestattet an Stelle des Rebroadcasts der 
Nachbar-Nachrichten HNA informationen in unserem Paket mitzusenden ?

So könnte das funktioneren: Mein batman Knoten merkt, dass er 3 one Hop 
Nachbarn hat, welche keine anderen Nachbarn hinter sich haben. Daher nehme 
ich diese Nachbarn als HNA auf. Meine anderen Nachbarn erhalten nun das Paket 
und können feststellen, dass meine IP und die IPs meine Nachbarn ziemlich 
dicht beieinander sind und stopfen uns alle in eine HNA Nachricht.

Die Vorteil liegt auf der Hand: Weniger batman Pakete und weniger 
Routeneinträge.

Wir müssten das aber so geschickt machen, dass wir nicht unsere eigene 
Statistik fälschen. Wenn ich zu meinem aggregierten Nachbarn 50% packet loss 
habe, ihn aber in jeder meine OGMs erwähne, könnte der Eindruck entstehen, 
dass der Link recht gut ist ?!

Was meint ihr ?

Gruß,
Marek

Re: [B.A.T.M.A.N.] IP Aggregation

[elektra]

Hi Marek -
> Die Vorteil liegt auf der Hand: Weniger batman Pakete und weniger 
> Routeneinträge.
>   
der Nachteil ist erhöhte Komplexizität der Sache. Der Vorschlag geht in 
die Richtung Methoden aus Linkstate Protokollen zu übernehmen. 
Prinzipiell spricht nichts dagegen.

Ich würde vorschlagen alle notwendigen Schritte zu machen, so dass der 
Code tendenziell die bestmöglichen Entscheidungen beim Routing trifft. 
Wenn Uns Linkstate-Komponenten dabei helfen (ETX-Werte zu 
Single-Hop-Nachbarn) können wir gerne darauf zurückgreifen. Bislang sehe 
Ich die Notwendigkeit jedoch nicht. Wenn der Code dann beim Routing sein 
Bestes gibt können wir schauen wie wir ihn in Richtung Skalierbarkeit 
optimieren.

Was die Abstürze angeht kann Ich die Aussage von Lui nur bestätigen -  
wir haben ein Memory-Leak. Der Speicherverbrauch stieg auf der Zwingli 
mit etwa 0.2% des Gesamtspeichers pro Stunde. Ich habe den Daemon 
daraufhin wieder abgeschaltet, da Ich ungern die Zwingli lahmlegen 
möchte - ein Neustart geht leider nicht remote. Auf dem WRT in der 
Wagenburg läuft der Daemon seit Tagen durch - der Speicherverbauch 
beträgt konstant 2,7 %.

Ziemlich ominös das Ganze...

Was haltet Ihr davon auf der Liste in English zu schreiben? Bislang ist 
Deutsch ok - aber wir bauen damit potentiell eine Barriere auf.

cu elektra

Re: [B.A.T.M.A.N.] IP Aggregation

[Marek Lindner]

Hi,

> Ich würde vorschlagen alle notwendigen Schritte zu machen, so dass der
> Code tendenziell die bestmöglichen Entscheidungen beim Routing trifft.
> Wenn Uns Linkstate-Komponenten dabei helfen (ETX-Werte zu
> Single-Hop-Nachbarn) können wir gerne darauf zurückgreifen. Bislang sehe
> Ich die Notwendigkeit jedoch nicht. Wenn der Code dann beim Routing sein
> Bestes gibt können wir schauen wie wir ihn in Richtung Skalierbarkeit
> optimieren.

schön. Wollte das nicht sofort einbauen, aber solche Ideen brauchen ein 
bisschen Zeit.  ;-)


> Was die Abstürze angeht kann Ich die Aussage von Lui nur bestätigen -
> wir haben ein Memory-Leak. Der Speicherverbrauch stieg auf der Zwingli
> mit etwa 0.2% des Gesamtspeichers pro Stunde. Ich habe den Daemon
> daraufhin wieder abgeschaltet, da Ich ungern die Zwingli lahmlegen
> möchte - ein Neustart geht leider nicht remote. Auf dem WRT in der
> Wagenburg läuft der Daemon seit Tagen durch - der Speicherverbauch
> beträgt konstant 2,7 %.
> Ziemlich ominös das Ganze...

In der Tat eigenartig. Gibt es irgendwelche bekannten Unterschiede wie: 
Startparameter, Nachbarkonstellation, etc ?

Um den Memory Leaks auf die Schliche zu kommen habe ich unseren internen 
MemoryChecker so umgebaut, dass er nun etwas brauchbares Auspuckt. An den 
Problemorten einfach mit Debuglevel > 0 starten, eine Weile laufen lassen und 
den Speicherverbrauch beobachten. Wenn dieser ansteigt, muss batman beendet 
werden und dann sollte ein solcher Output erscheinen:

Memory leak detected, malloc tag = 7
Memory leak detected, malloc tag = 7
Memory leak detected, malloc tag = 7
Memory leak detected, malloc tag = 7
Memory leak detected, malloc tag = 6
Memory leak detected, malloc tag = 2
Memory leak detected, malloc tag = 1

Schickt mir den dann einfach.
Es ist durchaus denkbar, dass ihr diesen Output *nicht* seht. Der 
MemoryChecker kann nur "richtige" MemoryLeaks finden (benutzer Speicher, der 
nicht freigegeben wurde). Möglicherweise handelt es sich aber um "logische" 
MemoryLeaks (es wird immer mehr und mehr Speicher angefordet, beim Beenden 
aber alles wieder freigegeben). Letzteres wäre im Output natürlich nicht 
sichtbar.

Gruß,
Marek