[Berlin-wireless] CPU-Laster

Mo Jan 2 19:15:45 CET 2006

Elektra,

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...

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