[Berlin-wireless] CPU-Laster

Mo Jan 2 21:42:34 CET 2006

Sven-Ola,
> 
> sowas hatte ich mir schon gedacht. Die Standardkonfigs mit FFF1.1 sind (mit 
> Default-Zeitbasis==5 Sek, das ist mittlerweiler aenderbar, z.B. ist 
> Fish-TCINT=$(( 1 + 1 * SPEED / 2 ))):
> 
> <nofish>
> LinkQualityWinSize      100
> MprCoverage             3
> HelloInterval           5.0
> HelloValidityTime       90.0
> TcInterval              10.0
> TcValidityTime          90.0
> </nofish>
> 
> <fish>
> LinkQualityWinSize      100
> MprCoverage             7
> HelloInterval           5.0
> HelloValidityTime       90.0
> TcInterval              3.0
> TcValidityTime          180.0
> </fish>
> 
> Da steckt an sich die Ueberlegung drin: Lieber etwas vorsichtiger damit es 
> uebergangsweise laeuft. Default ist ausserdem FishOff. Mir scheint, dass fuer 
> die lokal verbrauchte Rechenleistung immer die Nachbar-Konfigs wichtig sind. 
> Rund ums ND haben sich 11 Nodes versammelt - die haemmern mit TCs nur so auf  
> die104.0.0.14 ein. Das macht 60-75% CPU. Ich mach nachher mal eine 
> Fisch-Probe auf den BBB-Cubes und teste mal was dann passiert...

Wenn sich der Fisch weiter im Netz verbreitet müssen die Werte für die 
TC-Validity-Time natürlich noch stark vergrössert werden, weil die 
Fische auf die Entfernung weniger oft von sich hören lassen ;-D

Immerhin sind es bei einem TC-Intervall von 3 sec dann 13 x 3 Sekunden 
bis sich ein Fischeye-Node zu einem einzigen Rundspruch bequemt. Wenn es 
bis zum 10ten Hop 90% Packetloss gibt bleibt kommt da statistisch 
verteilt alle 390 sec mal ein heiles TC an...

Es ist gar nicht mal unwahrscheinlich, dass das letzte TC mitunter 10 
Minuten alt ist bevor es ein neues gibt...

Andererseits hat das den witzigen Effekt das sich die Grösse des Netzes 
und damit die CPU-Last anhand der Benutzbarkeit der Routen dann 
organisch regelt. Lange Routen die wohl eher theoretisch vorhanden sind 
verschwinden dann aus der Routingtabelle - benutzbar sind sie sowieso nicht.

Gibt es eine benutzbare Route - tauchen die Nodes wieder in der 
Routingtabelle auf.

Spannend, spannend!

cu elektra

> Grusz, Sven-Ola
> 
> Am Montag, 2. Januar 2006 17:09 schrieb 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
> 
> 
> 
> _______________________________________________
> 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