[Berlin-wireless] CPU-Laster

[onelektra]

Hallo Sven, hallo alle -

welcher Wert ist jetzt für die Hellos und den TC-Intervall gesetzt?

Wir kommen nicht drumrum wieder eine neue Default-Config für Berlin 
auszuklamüsern.

500 msec TC-Intervall (wie in der olsr.org fisheye-default) ist 
wahrscheinlich für ein so grosses und dichtes Mesh etwas zu oft. Da 
Fish-Eye nur die TTLs variiert, sollte nur wegen der Verwendung des 
Fisches bei der gemischten Anwendung zusammen mit dem alten olsrd *an 
sich* keine höhere CPU-Last auftreten. Bekommen diese Grossväter und 
-Mütter eine TC mit kleiner TTL reichen sie diese ebenfalls nur wenige 
Hops oder gar nicht weiter (TTL=1). Es kann nur sein das wir lokal wo 
das Netz sehr dicht ist jetzt damit die CPU-Last erhöhen. Ausserdem 
kommen ja immer noch von überall her ständig TCs vom alten olsrd 
angerauscht die bei einem TC-Intervall jedes Mal das Mesh noch komplett 
fluten wollen.

Die Abfolge der TTL-Werte steht im Quelltext in lq_packet.c:
static int ttl_list[] = { MAX_TTL, 3, 2, 1, 2, 1, 1, 3, 2, 1, 2, 1, 1, 0 };

Die Single-Hop Nachbarn bekommen bei einem TC-Intervall-Wert von 0.5 sec 
also jede halbe Sekunde von jedem direkten Nachbarn eins aufs Auge. Jede 
13te TC-Nachricht wird demzufolge über das ganze Mesh geschickt, d.h. 
alle 6.5 sec. Alle 2.2 sec gibt es eine Nachricht die 3 Hops 
weitergereicht wird, und es vergeht statistisch etwas weniger als 1 sec 
bis eine 2-Hop-Nachricht eintrifft.

Das ist eine wunderbare Sache in einem olsr-Mesh, das nicht allzu riesig 
ist, könnte aber für Berlin gerade an den zentralen Knotenpunkten 
Overkill sein. Besonders da uns die 'alten' immer noch mit der TTL 255 
bombardieren.

Bei einem TC-Intervall von 1 sec sind es dann:

Single-Hop 1 sec
Two-Hop 1.86 sec
Three-Hop 4.4 sec
Flood 13 sec

TC-Intervall von 1.5 sec:

Single-Hop 1.5 sec
Two-Hop 2.8 sec
Three-Hop 6.6 sec
Flood 19.5 sec

TC-Intervall von 2 sec:

Single-Hop 2 sec
Two-Hop 3.72 sec
Three-Hop 8.8 sec
Flood 26 sec

Sinn der Übung ist unter den benachbarten Nodes bis 3 Hops die TCs öfter 
zu schicken als die Hellos - d.h. mehr Redundanz zu haben. Die Metriken 
sollen sich langsamer verändern als sich die Informationen über die 
Metriken verbreiten. Ausserdem gehen jede Menge TCs durch Kollisionen 
verloren.

Die Hello-Intervalle sollten also wesentlich länger sein als die 
TC-Intervalle.

Wie wäre es mit Hello Intervall 10 sec und TC-Intervall von 2 sec bei 
dem Berliner Fish? Die Hello- und besonders die TC-Validity-Time muss 
natürlich dann auch entsprechend lang sein, damit unser Mesh die 
Existenz der Nodes am Rand oder anderen Ende nicht "vergisst".

Dieses Problem dürfte all jene betreffen, die noch den alten olsrd mit 
der alten .conf haben - für sie werden die Routingtabellen kleiner, 
entfernte Nodes würden dann eher sporadisch auftauchen, da diese immer 
wieder gegen deren eingestellten TC-Validity-Timeout rennen.

Bei einem Flood alle 26 sec kann es schon sein, dass es mehrere Minuten 
dauert bis eine TC von JanzWeitDraussen es einmal erfolgreich durch das 
ganze Mesh schafft. Das ist an sich egal, wenn nur die Validity-Time 
lang genug ist.

Die Zeit bis sich in einem Node die gesamte Routingtabelle aufgebaut 
hat, wird dabei natürlich zunehmen. Das 'Einbuchen' in das Netz wird 
also für Leute die gerade mal kurz ihren Laptop einschalten etwas länger 
dauern... Andererseits sollte die CPU-Load signifikant heruntergehen und 
wir können HSH und Weissensee endlich mit anbinden ohne den 
Stromverbrauch der Stadt signifikant zu erhöhen ;-)

cu elektra


> ausserdem haben wir irrsinnig Last auf den Cubes - teilw. bis 80% obwohl 
> nur knapp 200 Routen. Es werden wohl schon einige den Fisch fliegen 
> lassen. Wir *muessen* offenbar umstellen. Leider habe ich mich gerade 
> verdaddelt und mich selbst aus der Bouche geworfen (ungeschicktes 
> spielen mit der Default-Route - wird erst nachher wieder gehen, wenn ich 
> von der Funkseite aus drankann).
> 
> Grusz, Sven-Ola
> 
> _______________________________________________
> Berlin mailing list
> Berlin at olsrexperiment.de
> https://olsrexperiment.de/cgi-bin/mailman/listinfo/berlin
> 
> 


_______________________________________________
Berlin mailing list
Berlin at olsrexperiment.de
https://olsrexperiment.de/cgi-bin/mailman/listinfo/berlin