Knoten und Topo Probleme (neue Topographie Beitrag #31)

[zuw2]

@Basti7
Ich nehme an, du meinst die alte/neue Topo.

Falls du meine Spielerei meinst - ich habe gerade Probleme mit der Verbindung zu den meisten ff-Halle-Routern. Zum einen scheint 3dfx' vpn server gerade offline zu sein, so dass ich darüber keine stabile Verbindung ins ff-Netz bekomme. Zum anderen ist die Verbindung vom Umspannwerk nach Halle gerade sehr mies. Ich nehme an wegen des vielen Laubes, das sich zur Zeit auf den Bäumen rumtreibt. Wir sind dabei zu optimieren.

[3dfxatwork]

ja ich doktore gerade an meinem server (gerade ist gut seit Freitag schon) und es ist noch nicht wirklich ein ende in sicht

[Basti7]

ok, der Server macht also noch Probleme. Und wie sieht euer Plan aus, geht die ursprüngliche Topo ( http://karte.freifunk-halle.net/ ) danach wieder online oder bleibt erstmal die neue ( http://map.freifunk-halle.de.tc/ )?

[zuw2]

Ich habe den Plan, an meiner Karte weiter rumzubasteln, noch ein paar Features einzubauen. Das hat aber alles den Charakter "Will mal ausprobieren, wie das geht, wenn ich Zeit dafür habe.". Vor allem weil es hier ja schon einiges an Planungen für etwas richtiges gibt.

[Basti7]

das klingt gut was heißt "etwas richtiges"?

[tox]

Also ich würde darunter jetzt die Wiedereinrichtung der alten Topographie verstehen.

@zuw wir können uns mal kurzschließen bezüglich der Datenquellen, die du für deine Anwendung verwendest. Woher beziehst du sie bisher? Ich bin ja dabei eine Art Freifunk-Tools-Sammlung in C#/Mono/ASP.Mono zu schreiben, um die Python-Scripte abzulösen, die bisher auf dem Server liefen. Konkret handelt es sich dabei um eine Postgres-Datenbank, die Teile des NVRAMs der Nodes aufbewahrt. Diese werden von einer auf dem Server lokal laufenden Anwendung in regelmäßigen Abständen (aufgrund des Wunschs eines einzelnen auch parallelisiert) gesammelt. Diese bietet zudem die Möglichkeit, die Daten vorzuverarbeiten, beispielsweise sie umzuformen (unescapen von HTML-Entitäten), sie zu validieren und weitere Daten aus ihnen zu extrahieren (GPS-Koordinaten). Eine zweite Anwendung, eine Website, liefert aus dieser Datenbank die für die FFHTopo-Topographie notwendigen Daten in Form von JSON. An dieser Stelle wäre es denkbar, dass man ein zweites Format für deine Topographie generiert. Eine dritte Anwendung, ebenfalls eine Website, ist die derzeitige Topologie, sie stützt sich weniger auf die Daten der DB und benötigt im Wesentlichen die TxtInfo eines OLSR-Dienstes (die auch die anderen Anwendungen benötigen). Diese ist die älteste der drei und wird noch redesignt, um sie den anderen anzugleichen. Ich hatte ja auch die Idee, die Topographie an sich durch etwas anderes zu ersetzen, im Wesentlichen weil sie mir nicht schnell genug vorkommt, aber das ist ein deutlich schwierigeres Unterfangen, weil die Google-Maps-API nur JavaScript kann. Also meine Frage, an welcher Stelle kann ich die Anwendungen modifizieren, damit sie dir helfen?

[zuw2]

das klingt gut was heißt "etwas richtiges"?

Das was tox hier schreibt. Jedenfalls hatte ich auf den Stammtischen, die ich besucht habe, den Eindruck gewonnen, dass schwer an etwas neuem in C# gearbeitet wird.

@zuw wir können uns mal kurzschließen bezüglich der Datenquellen, die du für deine Anwendung verwendest. Woher beziehst du sie bisher?

Das wär gut!

Ich wgette bisher einfach die Kontakt- und die Nodes-Seite der Router. Alles, was html ist, schmeiße ich mit Grep, Sed und Konsorten raus. Aus den gewonnen Daten entstehen mehrere Plaintext Files: Nodes.txt, und die GPX-Dateien, die die Funkverbindungen darstellen (good.gpx, bad.gpx, worse.gpx, worst.gpx). Alle 5 Dateien sind Layer, die über die Openstreetmap-Daten gelegt werden.

Ich fände es jetzt nicht sehr sinnvoll, wenn du die Daten in diesem Format zur Verfügung stelltest. Ich werde an diesem Schema sicher noch etwas verändern. Was ich gut fände, wäre eine generische Lösung. So simpel wie möglich. Zum Beispiel eine csv-Liste aller Router mit den wichtigsten Informationen ("Routername";"IP";"LON";"LAT";"Internetgateway Flag";"epoch";...) und eine zweite csv mit den Verbindungen nebst Qualitätsinformationen. Sowas wie: "IP1";"IP2";"LQ";"NLQ". Diese Daten per http für alle verfügbar (Datenschutzbedenken irgendwer?) Ich kann mir gut vorstellen, dass mit diesen zentral und einfach verfügbaren Daten auch andere noch etwas anfangen können.
[/quote]

[tox]

Gut, für die Verbindungsliste kann man eine bereits vorhandene Lösung verwenden. Die benutz ich auch für das Remoteenwickeln. Lokal auf dem Server würde man eine lokale Verbindung stattdessen aufbauen. Ich kann diese Seite auch auf dem fertigen Server nachher zur Verfügung stellen.
http://tox.3dfxatwork.de/preview/TopoData.ashx
Das ist eine Textdatei, die am besten zeilenweise als endlicher Automat ausgewertet wird. Ihr prinzipieller Aufbau ist eine Auflistung von Tabellen, die durch Leerzeilen voneinander getrennt sind. Jede Tabelle hat 3 Teile. Die erste Zeile hat das Format "Table: <Tabellenname>". <Tabellenname> kann in unserem Fall Topology oder HNA sein. In Topology stehen die Linkqualitäten. In HNA stehen die HNAs drin. Die zweite Zeile einer Tabelle gibt das Format der Tabelle an. Das kann auch von OLSR-Version zu OLSR-Version variieren. Die weiteren Zeilen in jeder Tabelle geben je einen Datensatz an. Bei der HNA-Tabelle ist darauf zu achten, dass nur solche Einträge mit Destination 0.0.0.0/0 tatsächlich Internet zur Verfügung stellen. Bei der Topology-Tabelle sind zwei Dinge problematisch. Zum einen stimmt die Cost-Angabe (etx) manchmal nicht mit der LQ- und NQL-Angabe überein. Dann steht da manchmal INFINITE, obwohl LQ und NLQ bei 0.9 sind. Zum anderen stimmen die LQ- und NQL-Angaben einer Verbindung nicht unbedingt mit den entsprechenden Angaben der umgekehrten Verbindung überein. Best Practice ist also, zum einen nur die LQ- und NLQ-Werte zu betrachten und Cost außenvorzulassen und zum anderen die Werte von einer Verbindung und der umgekehrten Verbindung geschickt zu verknüpfen. In meinen Anwendungen tue ich dies bereits, aber noch nicht in dieser TopoData.ashx, da sie im Moment nur die lokalen Daten durchleitet. Ich denke aber, es wäre für deine Zwecke gut, wenn ich diese Ausgabe auch noch entsprechend vorverarbeite, damit sie denselben Datenbestand widerspiegelt wie die anderen Anwendungen. Was meinst du? Das wäre keine große Sache, ich müsste einfach nur die Daten, die ich mit einer von mir bereits fertig gebauten Graphklasse ohnehin in allen anderen Anwendungen genauso einlese, nur wieder hübsch in demselben Format ausgeben.

Die CSV mit den anderen Daten sollte auch kein Problem sein.

[zuw2]

http://tox.3dfxatwork.de/preview/TopoData.ashx

Finde ich gut. Damit kann ich was anfangen. Wie oft wird die Datei aktualisiert?

Bei der Topology-Tabelle sind zwei Dinge problematisch. Zum einen stimmt die Cost-Angabe (etx) manchmal nicht mit der LQ- und NQL-Angabe überein. Dann steht da manchmal INFINITE, obwohl LQ und NLQ bei 0.9 sind. Zum anderen stimmen die LQ- und NQL-Angaben einer Verbindung nicht unbedingt mit den entsprechenden Angaben der umgekehrten Verbindung überein. Best Practice ist also, zum einen nur die LQ- und NLQ-Werte zu betrachten und Cost außenvorzulassen und zum anderen die Werte von einer Verbindung und der umgekehrten Verbindung geschickt zu verknüpfen. In meinen Anwendungen tue ich dies bereits, aber noch nicht in dieser TopoData.ashx, da sie im Moment nur die lokalen Daten durchleitet. Ich denke aber, es wäre für deine Zwecke gut, wenn ich diese Ausgabe auch noch entsprechend vorverarbeite, damit sie denselben Datenbestand widerspiegelt wie die anderen Anwendungen. Was meinst du?

Ich meine, beides wär gut. Wie entsteht der verknüpfte Wert genau? Den könntest du ja in eine weitere Spalte packen. Die Rohdaten hätte ich aber auch gern.

Die CSV mit den anderen Daten sollte auch kein Problem sein.

Finde ich auch gut.

[tox]

Finde ich gut. Damit kann ich was anfangen. Wie oft wird die Datei aktualisiert?

Ständig, die Daten werden direkt so vom OLSR-Dienst geliefert und nicht zwischengespeichert.

Ich meine, beides wär gut. Wie entsteht der verknüpfte Wert genau? Den könntest du ja in eine weitere Spalte packen. Die Rohdaten hätte ich aber auch gern.

Ok, an die unangetasteten Rohdaten kommst du angenommener Weise, deine Anwendung läuft dann auch auf dem Server, den wir einrichten, ohnehin ran. Das wäre dann nur eine andere URL, die eine Website mit demselben Format liefert.

Der verknüpfte Wert entsteht dadurch, dass ich mir den LQ der einen Verbindung nehme, den NLQ der umgekehrten Verbindung, beide addiere und dann durch 2 teile. Dahinter steckt folgende Logik. So ein Wert ist ja der Quotient aus erfolgreich übermittelten Paketen und der Anzahl der Übermittelungsversuche. Für die Rechung nehme ich an, dass beide Werte mit derselben Anzahl von Übermittlungsversuchen berechnet worden. Die kenne ich zwar nicht, aber sie ist eindeutig festgelegt. Diese Annahme stimmt nur dann nicht, wenn diese Anzahl aufgrund eines Routerneustarts noch nicht erreicht wurde, aber dann sind die Anzahlen trotzdem etwa gleich groß und außerdem ist die Angabe der Verbindungsqualität in dem Fall ohnehin ungenau. Der Gesamtquotient ist also
(#erfolgreich1+#erfolgreich2)/(2*#Versuche)
=((#erfolgreich1/#Versuche)+(#erfolgreich2/#Versuche))/2
=(LQ+NLQ)/2

[Basti7]

... hallo Jungs, wollt mal hören obs was neues von der Karte gibt

[zuw2]

... hallo Jungs, wollt mal hören obs was neues von der Karte gibt

Von mir nicht. Ich habe grade keinen ausreichend guten Funk und kein VPN um mir die Daten selbst zu beschaffen. Zum freien Freifunktreffen habe ich mit Tox darüber gesprochen, was ich von ihm nutzen könnte. Wenn ich die Datenquellen habe, gehts weiter.

[Basti7]

laut Tox letzten Stammtisch war das doch schon so gut wie fertig (nur noch kompilieren)..
Ich würd morgen 4 neue Knoten aufbauen und die Topo wär da genial beim testen, na mal schauen

[PapaBaer]

Der verknüpfte Wert entsteht dadurch, dass ich mir den LQ der einen Verbindung nehme, den NLQ der umgekehrten Verbindung, beide addiere und dann durch 2 teile. Dahinter steckt folgende Logik. So ein Wert ist ja der Quotient aus erfolgreich übermittelten Paketen und der Anzahl der Übermittelungsversuche. Für die Rechung nehme ich an, dass beide Werte mit derselben Anzahl von Übermittlungsversuchen berechnet worden. Die kenne ich zwar nicht, aber sie ist eindeutig festgelegt. Diese Annahme stimmt nur dann nicht, wenn diese Anzahl aufgrund eines Routerneustarts noch nicht erreicht wurde, aber dann sind die Anzahlen trotzdem etwa gleich groß und außerdem ist die Angabe der Verbindungsqualität in dem Fall ohnehin ungenau. Der Gesamtquotient ist also
(#erfolgreich1+#erfolgreich2)/(2*#Versuche)
=((#erfolgreich1/#Versuche)+(#erfolgreich2/#Versuche))/2
=(LQ+NLQ)/2

Der Durchschnitt ist ein Begriff aus der Mathematik. Er wird in der Mengenlehre als Kurzform für die Schnittmenge und in der Statistik synonym für den Mittelwert benutzt.

Aber warum einfach, wenn es auch so wunderbar umständlich geht

[PapaBaer]

So,

hab jetzt nochmal ne Nacht drüber geschlafen. Und muss leider mit einer argen Enttäuschung aufwarten, und mit einer Frage, die sich mir stellt.

Für die Rechung nehme ich an, dass beide Werte mit derselben Anzahl von Übermittlungsversuchen berechnet worden.

Genau da liegt der Hase nämlich im Pfeffer. Wie kommst du auf die Idee, dass beide Seiten die gleiche Anzahl von Packets übermitteln wollen? In der Regel ist es doch vielmehr so, dass Datenströme "in Richtung" der HNA fließen werden, also ein eher ungleich verteiltes Datenaufkommen. Selbst die reinen OLSR-Packete werden nicht synchron laufen. Das hängt sicher arg von der Auslastung des einzelnen Nodes und seiner Nachbarknoten ab. Obendrein kann der WLAN-Stack selbst auf verschiedene Übertragungsraten schalten, damit den Verlust von Packets abfangen und so zu asymetrischen Zuständen führen. Die einzige Möglichkeit, sinnvolle Daten zu erhalten ist der Zugriff auf den eigentlichen WLAN-Layer. Und damit zur Frage:

OLSR hat ja selbst mit genau dieser Tatsache zu kämpfen, ist ja sogar Kern des Projektes Link-Qualitäten (in beide Richtungen) zu ermitteln und daraus die besten Routen abzuleiten. Wieso machst du also den Umstand jetzt noch einmal (naive) Algorithmen aufzusetzen, wenn dir OLSR selbst die Daten liefert, die du suchst? Nimm den ETX-Wert und fertig. Dazu ist der da.

[Basti7]

Morgen Leute

nur mal kurz zur Übersicht für mich?
So wie ich das verstanden hab arbeitet Tox mit PapaBaer an der neuen Topo(graphie) bei der es anscheinend noch Probleme gibt, von zuw2 gibt es etwas Vorläufiges, was aber nicht mehr online ist.

mal eine Vorsichte Frage, nur mal theoretisch... bis das neue Ding final online ist, könnte man nicht nochmal das die alte Topo (also die welche vor 3 Monaten prima funktionierte) anwerfen oder?

[3dfxatwork]

@ Papabear, OLSR liefert eben nicht immer einen ETX, man hat immer 2 richtungen, und für jede Richtung steht ein ETX in der Tabelle(wenn es einen gibt), nun muss man entscheiden welcher der richtige ist, das soll damit bezweckt werden. Es steht aber immer ein LQ und LNQ zu jeder Verbindung drin, und aus diesen kann man den ETX berechnenn, wie beschrieben.

[PapaBaer]

und aus diesen kann man den ETX berechnenn, wie beschrieben.

Ne, geh ich nicht mit. Wenn man sich mal die Internas von OLSR und Batman ansieht, kann man gut erkennen, dass das alles eben nicht so einfach ist. Die doofe Eigenschaft von WLAN ist ja gerade, dass die Verbindungen nicht in beiden Richtungen gleich gut sind. Vortiel des Batman-Ansatzes ist es ja wohl auch, dass diese Asymetrie ins Routing eingerechnet wird.

Jetzt hinzugehen und zu sagen: Mach ich einfach n Durchschnitt und gut, wird der Sache nicht gerecht und bringt falsche Werte. Zur reinen Visualisierung könnte man vielleicht noch nen durchschnitt der ETX-Werte anbieten. (Wie werden die eigentlich genau berechnet?) Wie macht es denn die alte Topo?

[tox]

...Zum freien Freifunktreffen habe ich mit Tox darüber gesprochen, was ich von ihm nutzen könnte. Wenn ich die Datenquellen habe, gehts weiter.

ist so weit.

Um es abzukürzen: ich hatte mal irgendwo gehört, dass OLSR sich bei der Berechnung der Verbindungsqualität die letzten 100 Versuche anguckt. Selbst wenn das nun mal so überhaupt nicht stimmt, ich gehe davon aus, dass ein LQ ein und derselben Funkverbindung (und Richtung!) auf dem einen Router sich nicht wesentlich von dem NLQ auf dem anderen unterscheidet, ich will sie nur halt irgendwie kombinieren, um keinen von beiden unter den Tisch fallen zu lassen, und da bietet sich der arithmetische Durschnitt eben an.

Bei der alten Topo, wenn ich das richtig erkenne in den Scripten, ist die Link-Qualität der Kehrwert des etx-Werts.

[Basti7]

cooool
ist das jetzt die neue Topogr. unter "map" oder die alte?
Sind die Knoten aktuell oder ist das der Stand von früher?

[3dfxatwork]

Die Knoten sind aktuell, jedoch fehlen noch einige, da nicht alle Teilnetze über das VPN angeschlossen sind, das werden wir hoffentlich noch in den griff bekommen.
Die Topographie also die Karte ist halbneu, das was auf Serverseite die Daten sammelt und verarbeitet ist neu, auf Userseite ist alles so geblieben

MFG Matthias

[Basti7]

sauber
dank dir für die Info!!!

[tox]

Aktuell von letzter Nacht. Wie gesagt, der Server hat noch zu wenig RAM, um den Datensammler zuverlässig regelmäßig in einem Cronjob laufen zu lassen.

[Basti7]

was für Module bräuchtet Ihr denn, vieleicht hab ich noch was rumliegen

[tox]

Wir benötigen "SAW nerven, damit er dem VServer mehr RAM zuteilt"-Module

[Basti7]

asso

[Basti7]

also bis auf "Mono_14-15" bei Nebra macht das doch schonmal nen guten Eindruck
Ich hab gerade die 4 WGs von mir angeschrieben, das Sie mal noch die Koordinaten eintragen um auch mit auf der Karte zu erscheinen.
Danke euch schonmal und ein schönes WE

[tox]

Bei der Gelegenheit kannst du das bitte auch gleich bei deinem eigenen Knoten in der Schillerstraße nachholen

Die .14.15, ebenso wie die .14.14, ist mir auch aufgefallen, aber die eingetragenen Koordinaten sind tatsächlich aus Nebra, Mono hat falsche Koordinaten in seinen Daten stehen.

[Basti7]

meine eigenen Knoten sind in der LuWu und schon immer vorbildlich eingetragen
In der Schillerstraße hab ich zwei aufgebaut und heut mit angeschrieben, das sie die Sachen nachtragen sollen.
das mit Mono ist schon länger (war schon auf der alten Karte von Zuw), fällt eigentlich nur auf wenn man die OLSR-Verbindungen anhakt, aber sieht halt ganz schön krass aus

[tmk]

Na ich will Mono sowieso mal ansprechen wegens der Doku, da geh ich mal rum und frag, ob das Absicht ist. Wenn nicht, wird er das sicher auch wieder reparieren. Die 15.9, mein Knoten hier, war irgendwie auch verrutscht in die Breite Straße. Keine Ahnung wieso... Habs angepasst und geht. Wenn ihr mal in den Hinterhof bei mir reinscrollt, seht ihr, wie die Knoten alle auf der Wiese liegen oder am Tisch sitzen Ich glaube, die 14.27 ist auch verkehrt.

Und natürlich danke an die Frickler, dass das jetzt wieder läuft, nach so vielen Wochen ohne visuelles Feedback zum Netz. Topologie und Topographie sind wichtig zum Verstehen.

Und seht ihr die 15.18? Das ist ein DIR300 mit Kamikaze in der Scheffelstraße. Der taucht nicht auf und ich erreiche ihn auch nie.#

Werden die Nodelisten im Wiki eingentlich auch wieder die Botinfos einsammeln?