Performance-Probleme

Ich weiß nicht, ob das Paket weiterentwickelt wurde oder es einfach nur 2013.4.0 enthält und mit DKMS ein Kernelupdate vereinfachen soll. Auf die Schnelle habe ich gerade nichts darüber gefunden.

Ich würde es mit der von @phip verlinkten Version versuchen, die hat auch noch zusätzliche Patches und ist so gesehen „kompatibler“ mit der Version auf den Nodes. :wink:

Das war übrigens der Grund, warum ich akut nochmal einen Satz Experimental-Builds für Gluon gemacht habe. In der Hoffnung damit die „verschwundenen Nodes“ im alfred oder beim ipv6-batman-routing reduzieren zu können. Bin mir aber unschlüssig, ob das hilft, denn der Effekt tritt immer noch auf, wenn auch gefühlt seltener.

Wo wäre die gesicherte Information zu „müssen Split durchführen“ Grenze?

Ich frage für eine Lieferung von ganz vielen Routern…

Gefühlt liegt die Grenze des Machbaren bei 500 Routern pro Domain.
Weil irgendwann der elende Broadcast-Traffic (egal ob mit oder ohne Split-Horizon-Patch) so arg wird, dass Standort mit „DSL-Lite“ schlicht gar nicht mehr genug Upstream haben und schon mit dem Broadcast-Mist ihren Upload „saturieren“.

P.S.: Communities statis zu bilden „Nach Ortschaften“ mag nahe liegen.
Meine Vermutung ist jedoch, dass dabei stets sehr unterschieldich große Gebilde bei herauskommen, da das Wachstum nicht überall gleich bleiben wird. Ausserdem wird man immer wieder von neuem Teilen müssen.

Schöner wäre es, diese Segmentierung des Netzes irgendwie automatisiert hinzubekommen.

Idee „in die Tüte gesprochen“:

Man könnte man anhand der AP-Stationen herum (auch den „Nicht-Freifunk-ESSIDs“, alles was ein iw scan so ausgibt) anhand freier Datenbanken schon gut geographich lokalisieren. (Falls bei der Einrichtung keine Koordinaten hinterlegt wurden)
Und dann könnte man die Nodes nach einem ersten Handshake mit einem „Dispatcher“ gemäß Geokoordinaten und gehörter Nachbarn in eine regionale Wolke geben (also ihnen die Liste der für sie zuständigen Supernodes übergeben.)
Wie man das öffentliche Routing der IPv6-Adressen dann hinbekommt, das müsste man noch prüfen, evtl. nochmal umswitchen nach diesem Dispatch) #
Auf jeden Fall hätte man Wolken, die in ihren Grenzen je nach Netzentwicklung durchaus dynamisch wandern könnten. Langsam zwar, aber eben so, dass sie Lastsituation in den einzelnen Teildomains ähnlich bleiben.

Wie gesagt bei 620 Nodes hat Hamburg derzeit 60 kb/s upload „waste“, das skaliert also noch deutlich größer…da ist bislang noch niemand im Zwang gewesen splitten zu müssen!

Ich habe gerade einen 1 Monat lang dauernden Kampf mit bat15 hinter mir, der überhaupt keinen Spaß gemacht hat. Da konnte ich so viel verstellen und optimieren wie ich wollte; dies brachte keine Verbesserung. Im Batman-Code wurde etwas nicht bedacht, schlicht vergessen oder ein Flüchtigkeitsfehler hat sich eingeschlichen. Es bringt also nichts das fehlerhafte Modul zu nutzen, da auf einem Gateway durch das Datenaufkommen der Fehler statistisch öfter passieren kann, als auf einem Knoten. Ein Knoten startet sich zudem einfach neu, ein Server landet bis zum Reset im Nirvana.

bat14 wird nicht mehr aktiv weiterentwickelt. Um so mehr lobe ich die Tatsache, das bemerkte Fehler durch Patches behoben werden, entweder als entdecker Fehler oder als Erkentniss aus aktiver bat15 Entwicklung. Mich hat es einfach nur vom Hocker gehauen, dass mir weder die allerneueste bat15 Version noch die viel neuere, mit dem neuestem Kernel gelieferte Version helfen konnte den auftretenden Fehler zu beseitigen. Und da der Fehler noch nicht entdeckt wurde …

Ich kann zwar kein C, aber ich glaube, dass der von mir verlinkte Patch Euren Fehler beschreibt. Die Entwickler stellen keine Fehler bereinigte Version von bat14 mehr zum Download bereit, also muss man sie sich aus dem Git ziehen. Das geht zum Glück auch ohne Git:

https://github.com/freifunk-gluon/batman-adv-legacy/archive/master.tar.gz

Versucht es, es kann nur besser werden.

2 Likes

Ist bei uns nicht ganz so massiv wie es bei Dir war - im Schnitt haben wir einen Server pro Woche der ne Panik hat. Da es bei uns nun so eingestellt wurde das nach einer Minute Wartezeit bei einer Kernel Panik automatisch restartet wird, kommen die Gateways vermutlich sogar von alleine wieder hoch.

Wie passt „gefühlt max 500 pro Domain“ und „wir haben 650“ mit der Erfolgsmeldung: „1.000 Router drehen“ (https://freifunk-rheinland.net/) zusammen?

Ich verstehe das nicht.

Viele Grüße, Fx

Das Ruhrgebiet hat in Hochzeiten schon 480 Router, fortlaufend mindestens 430 im Netz.

Entsprechend hatten wir schon sehr früh Probleme im Umgang mit größeren Domänen und hatten uns ebenfalls entsprechend früh mit den Hamburgern ausgetauscht.

Wieviele wir ohne größere Probleme tatsächlich ins Netz bekommen weiß noch niemand. Aus dem Bauch raus tippe ich derzeit vorsichtig auf annähernd 1.000 Stück - aber bitte nicht verwechseln, dies ist kein profunder Wert, sondern lediglich eine Schätzung auf Basis der größten mir bekannten Kollisionsdomäne Hamburg und deren Zahlenmaterial.

Ok, dasheisst die 1.000er Meldung enthält mehrere Domains.

ALLE, das ist die Anzahl Router in allen Domänen des Vereins, aus der gemergeten Map: http://map.freifunk-rheinland.net/graph.html

Meine Statistikanzeige frisst leider immer noch nicht Möhne und Wuppertal, sonst hätte man da nen schönen Wert:

http://map.freifunk-ruhrgebiet.de/counts/count.php

Ja, sorry. Wir nutzen ffmap-d3 in der neuesten Inkarnation und den neuesten ffmap-backend. Der generiert so was (eine Zeile als Beispiel):

{"name": "/dev/tal", "flags": {"gateway": false, "online": true}, "clientcount": 1, "firmware": "0.5.90-ffw-20140910", "id": "10:fe:ed:e6:5b:68", "geo": [51.26675, 7.14505]},

es reicht also nur die die „online“: true zusammen zu zählen und „clientcount“: x-1 auszuwerten und man hat die Werte.

1 Like

aktuell misst OOKLA Speedtest auf meinem iPhone über mehrere Messungen nur gut 1 Mbps.
Zum Vergleich: über Troisdorf/Wupper messe ich zw. 5,7 und 6,3 Mbps.

Weil in Wupper fast nix im Netz ist und Rheinufer noch zu wenig Serverkapazitäten hat.

Jetzt stimmen übrigens auch die Werte der Übersicht:

http://map.freifunk-ruhrgebiet.de/counts

2 Likes

Hallo @nomaster,
bin Linux Admin und bei den Aachenern mit aktiv. Habe leider zu wenig Zeit, um mich selber in das Thema Supernodes einzuarbeiten - kenne mich aber SEHR gut mit Linux aus.
Wenn wir in Aachen jetzt wirklich mit der Rate weiter wachsen, dann werden wir sehr früher als später eigene Supernodes brauchen. Eine Art Schulung wäre also super!

Schönen Gruß,
Upuetz

Schreib mal ne Mail an request@freifunk-rheinland.net und frag mal ob du bei einer Domäne als Admin mithelfen kannst.

Zumindest Ruhrgebiet sucht noch neue Admins ([siehe] 1) und da sollte man ja Erfahrung sammeln können.

Nein, keine Tickets mehr machen, Udo ist Admin aus Aachen und Aachen hatte bereits 2 Tickets und nen privaten Thread hier im Forum auf.

Ich habe das nun alles zusammengefasst und alle Tickets geschlossen, nun sollte wieder „Grund drin sein“. :wink: