Anderes Performance-Problem beim Meshen

Hallo zusammen,
ich möchte euch gern um Mithilfe bei einem technischen Problem bitten:

Ich betreibe an zwei Standorten in Duisburg, die ca. 250m auseinanderliegen, zwei FF-Knoten, beide mit Uplink.
Auf der FF-Map kann ich sehen, dass die beiden von Zeit zu Zeit miteinander meshen, je nach Wetter oder LKWs dazwischen, wie auch immer.
Wenn das jedoch passiert, wird die Internetverbindung für die verbundenen Clients in Bezug auf Antwortzeiten deutlich schlechter, teilweise unbenutzbar.
Dabei scheint es ebenfalls so, das der Zugang sich ähnlich verschlechtert je „roter“ auch die Meshverbindung in der Karte angezeigt wird.
Hat jemand eine Idee, was ich da machen kann?
Sollte eine Lösung das Abschalten des Meshens beinhalten, geht das auch per CLI? Ich habe zurzeit nur SSH-Zugriff.
Danke schon mal für Eure Hilfe…

Das wird evtl. ein Seiteneffekt der extremen Hop-Penalty sein, die wir inzwischen eingestellt haben, damit Meshlinks bevorzugt werden.
Bei „es geht nur zum Gateway“ sollte das jedoch eigentlich außen vor sein.

Aber den Effekt habe ich auch schon häufiger beobachtet. Leider. Passiert wenn Wolken mit guten Uplinks sich gelegentlich querverbinden.

ähnliches Problem könnten wir auch in der Community Möhne haben.
z.B. diese Verbindung
http://map.freifunk-moehne.de/meshviewer/#!l:0418d6879225-0418d68792e5

Zwei Unifis. Eine mit Uplink die andere bekommt über 5 meter einen guten Mesh Link und über 200 Meter einen sehr schwachen. Ich war neulich mal vorort bei letzterem Betreiber, um zu checken wie es generell ausschaut, nachdem er Verbindungsabbrüche beklagte. Tatsächlich aber war es nur ein Bandbreitenproblem + ne Menge Clients zu der Zeit…

Mich würde generell auch interessieren ob dies Grund für Performance-Einbußen sein kann.

Bisher nahm ich an Batman priorisiert nach Paketverlust?

Batman arbeitet nach meiner Beobachtung ähnlich wie schlecht implementiertes TMC im Auto-Navi:
„Wenn Stop&Go auf der Autobahn, dann alle runter von der Autobahn.“

Per default geht die Route also über die dicke lokale Mesh-VPN-Strecke zum Gateway.
Warum? Da der Paketverlust auf der schlechten Strecke höher ist.

Nun sind aber plötzlich so viele Clients da, dass die Performance der Hauptstrecke leidet und auf dem Papier die schwache (aber noch unbelastete) Wifimesh-Strecke besser ausschaut als als die fette (aber trotzdem überlastete) lokale Verbindung.
Ergebnis: Batman schickt erstmal alle auf die Nebenstrecke… mit katastrophalem Resultat. Nur um das zu merken und dann zu korrigieren braucht er erstmal ein paar MInuten.
Und 10 Minuten später geht das Spiel von vorne los.

1 Like

Wie schön, wieder eine neue Karte.
Darum gehts:
http://map.freifunk-ruhrgebiet.de/meshviewer/#!n:c04a0005822c
Wie leicht man sich doch bei den Entferneungen verschätzen kann… :wink:

123 m

so was habe ich auch an 2 Stellen.
Mesh ist da, aber Verbindungsqualität unter 10%, also für reale Nutzung unmöglich, für Internet schon gar nicht, kommt nur „unbekanntes Netzwerk“ oder andauerndes login/logout/login

Weis nicht ob es ginge, Meshing von einer Mindestverbindungsqualität abhängig zu machen, die der für Internet notwendigen Mindestqualität entspricht und so verhindert, dass ständig unbrauchbare Verbindungen erneuert werden, was das ganze Meshnetz runterdrückt.

Leider schauen einige nur auf „Mesh funktioniert“ (egal, wie bescheiden) und denken dann, alles easy, aber das Gegenteil ist der Fall, ist nämlich eine ständige Quelle für Reklamationen und Äerger = Imageverlust für FF

Lösung im obigen Fall seh ich nur mit „noch ein Router dazwischen setzen“ 123 m ist recht viel, selbst unter Idealbedingungen.

1 Like

Man könnte in der Firmware die MCAST Rate hoch setzen. Bei uns in der Community ist die auf 12000 gesetzt, wie bei den meisten Communitys. Sprich erst wenn WLAN technisch eine 12 MBit Verbindung besteht wird gemesht.

1 Like

lässt sich das in % bezogen auf die Angaben z.B. in http://map.ff.petabyteboy.de/ ausdrücken?

Hi,
„MCAST ändern“- kann ich das (per ssh) prüfen und ggf. ändern?

Hiermit kannste dir den Wert anzeigen lassen.

root@MA-Balkon-LocoM2:~# uci show | grep mcast
wireless.mesh_radio0.mcast_rate=12000

Setzt du den Wert mit:

uci set wireless.mesh_radio0.mcast_rate=6000
uci commit wireless.mesh_radio0.mcast_rate
wifi

Mesht der Knoten eventuell auch mit weiter entfernten Knoten

Hiermit:

uci set wireless.mesh_radio0.mcast_rate=18000
uci commit wireless.mesh_radio0.mcast_rate
wifi

Mesht ein Knoten wohl nur mit anderen Knoten die näher beieinander sind. Ich bin mir aber grundsätzlich nicht sicher ob man beliebige Werte für MCAST nehmen kann. Müsste man ausprobieren. Hab leider keinen weiter entfernten Knoten zum austesten gerade verfügbar.

Danke für den Tipp.
Ich habe es bei beiden betroffenen Routern geändert (von 12000 auf 18000). Ich gehe mal davon aus, dass es keine Neustart braucht?
Ob es sich positiv auswirkt, kann ich noch nicht sagen, schlechte Verbindungen gibt es aber nach wie vor. Ich habe mal im Abstand von ca. einer Stunde die folgenden beiden Screenshots gemacht. Was bedeuten die Zahlen, die erscheinen, wenn man mit dem Mauszeiger auf die Verbindung zeigt?

Sie zeigen die Qualität des MESH an. 1.000 bedeutet keinen Paket Verlust und würde 100% TQ bedeuten. 2.000 würde 50% TQ bedeuten. Also jedes zweite Daten Paket kommt nicht mehr an. Es zeigt sich durch die Änderung der MCAST Rate wohl sehr deutlich das die Qualität des MESH sich erheblich verschlechtert hat.

Ich habe es jetzt mal in die andere Richtung auf 6000 geändert. Aber was ich eigentlich erreichen wollte, war ja, dass sich die beiden sich gar nicht mehr miteinander verbinden. Schließlich haben beide Knoten ja einen eigenen Uplink. Können wir noch etwas in diese Richtung probieren?

Ich verstehe nicht, warum du es auf der einen Seite verringert hast. Du solltest es auf beiden Seiten auf 18000 anheben, damit schlechte Verbindungen nicht akzeptiert werden.

Das ist ein Missverständnis. Ich habe den MCAST-Wert jeweils bei beiden Routern in gleicher Weise geändert. Erst bei beiden auf 18000, dann bei beiden auf 6000.
Mit der Formulierung „andere Richtung“ meinte die Änderung des Wertes in die Richtung nach unten, vom vorher eingestellten Standardwert 12000 aus gesehen…

Ich habe jetzt beide Varianten ausprobiert: 18000 wie auch 6000 bei jeweils beiden beteiligten Routern. Die beiden meshen aber mit sich häufig stark ändernder Qualität weiter.

Ich möchte deshal nochmal meine Ursprungsfrage neu stellen: Kann ich über ssh und Kommandozeile das Meshen abschalten?

Klar.
/etc/init.d/alfred stop

Ich denke nur, dass so ein Node dann nur von beschränktem Nutzen ist für Freifunk.

Damit schaltest du nur den Daten Sammler Alfred aus. Musst das Wifi Mesh Interface abschalten. Aber ohne Mesh ist das kein richtiges Freifunk mehr. Du beraubst andere der Möglichkeit am Freifunk Netz teilzunehmen.

Ups… natürlich

ifconfig bat0 down sollte dem Mesh den Saft abdrehen.

Dann hast du auch kein MeshVPN mehr. Du musst das WifiMesh Device ausschalten.