[Berlin-wireless] OLSR Status

[Sven-Ola Tücke]

Moins,

(eine Vorbemerkung: ich bin eher Praktiker. Mir isses egal, ob etwas 
wissenschaftlich korrekt ist - solange es funktioniert). 

Aha. Die Berechnung ist also von SendedPacks / ReceivedPacks auf 
SendedHellosLastMinutes / ReceivedHellosLastMinutes umgestellt. Das kann 
schon Sinn machen, z.B. wenn die Verbreitung von Topoinfo nicht mehr uber 
Superviele-Redundante-TCs laeuft. Hannes hatte ja mal sowas angekuendigt. 

Jedenfalls koennte man auch Hellos/Minute beim Start mit einem kleinen 
Bewertungszeitraum rechnen. Und den Bewertungszeitram erst nach dem 
hochlaufen langsam verlaengern. Naja - erstmal egal...

Des weiteren wird (falls nicht auch an der Paketaggregation gedreht wurde) es 
moeglicherweise dasselbe Problem wie beim B.A.T.M.A.N geben: Berechnet wird 
der Verlust von *kleinen* Paketen. Das ist aber Wireless. Bei miesen Links 
kann man sehr wohl mit 50-Byte-Paketen uebertragen, aber ein 1500er gehen nur 
selten mal durch.

Eine Mail spaeter identifizierst du den DijstraLimit als Fehlerquelle - ich 
nehme an, dass LQTCs dann nicht oder nich korrekt gesendet werden. Das kann 
schon sein - denn Hannes hat ja immerhin das ganze Timerzeugs umgebaut. Das 
D-Limit erzwingt eine Komplettberechnung der GesamtTopo alle X Minuten. Und 
ignoriert "Neuberechnungs-Aufforderungen" wegen empfangener Topoupdates. 
Zumindest vor dem Timer-Refactoring war das noch noetig um die CPU-Last 
einigermaszen niedrig zu halten. 

Ich werde also zunaechst mal mit einer WVC54G testen. Das ist 'ne Webkamera 
mit einer saulangsamen CPU (ca. 1/10 von einem WRT). Wenns da drauf laeuft 
dann sehen wir weiter...

P.S.: Nein - Zeit hab' ich praktisch keine. Und auch kein Skype & co. Nur SIP, 
DSS1 und manchmal DTAP-CC. 

// Sven-Ola

Am Samstag 10 Mai 2008 10:50:50 schrieb Henning Rogge:
> 2008/5/10 Sven-Ola Tücke <sven-ola at gmx.de>:
> > Hallo Henning,
> >
> > das hab' ich nicht kapiert. Das ist jetzt auf Hello-Message-Loss (statt
> > Packetloss wie vorher) umgestellt? Und dazu kein bzw. ein kleines
> > Message-Loss-Messfenster bzw. eins mit Alter. Das gibt in jedem Fall
> > eine "Startverzoegerung" wenn die Gegenseite noch kein Upate hat.
>
> Exakt... da die Rate der Pakete nicht konstant ist können wir sonst
> keine sinnvollen ETX Werte berechnen. die geben nämlich eigentlich
> "Paketverlust pro Zeit" an.
>
> Und es kann ja nicht richtig sein das nur weil ein Link von irgendwas
> mal 3 Sekunden geblockt wird der ETX Wert auf 0 sinkt weil in dieser
> Zeit 100 TC-Pakete weitergeleitet wurden.
>
> Meine Bestrebungen gehen momentan dahin etwas wie ETT oder MIC Metrik
> zu implementieren, aber die Arbeit an dem Layer-2-Wrapper liegt auf
> Eis solange wir den Bug nicht gefunden haben.
>
> > Und richtig. Das war eine neue Version in einem Mesh voller
> > gegenwaertiger Versionen. Man braucht 3 Geraete dafuer (oder 3*VMWare
> > oder so). In der Mitte muss was stehen, dass die beiden aeusseren "sieht"
> > und die beiden auesseren mit iptables abblocken. Virtuelle Maschinen
> > fuer'n Test gibts z.B. unter http://www.damnsmalllinux.org/
>
> Ich habe bei mir bereits ein laufenden KVM (Kernelbased Virtual
> Machine) Netz mit bis zu 50 Knoten am laufen, auf denen
> OpenWRT-Kamikaze-x86 läuft.
>
> Wenn du Zeit hast würde ich dich gerne mal im Skype sprechen, jede
> Information was genau passiert könnte helfen den Fehler zu
> reproduzieren... und dann bin ich zuversichtlich das wir den Fehler
> auch finden. Wenn du Zeit hast schick mir mal direkt eine Email (nicht
> über die Mailing-Liste).
>
> Nach Informationen von Clemens tritt das Problem seit Revision 1472
> auf, 1469 sollte den Fehler nicht haben (beides Revisionen aus dem
> Entwickler-Tree http://gredler.at/hg/olsrd/ ).
>
> Der Fehler wurde nicht früher erkannt weil er anscheinend nur in
> speziellen Fällen auftritt, ich habe erst gestern ein Netz mit alten
> und neuen Knoten zusammen simuliert und hatte keine Probleme. Wir
> nehmen momentan an das sich etwas subtil im Timing-Verhalten geändert
> hat.
>
> Henning