Performance Thread Rheinufer

Ich hab 8 Beiträge in ein vorhandenes Thema verschoben: Sammelthread: Störungsmeldungen und Netzprobleme in Gelsenkirchen

Vielleicht sollten wir einfach auf nächste Woche warten bis die Feuer gelöscht sind. Ich denke, das Einbinden von neuen Personen kann man einfach nicht so gut machen, wenn es akut an allen Enden brennt.

Soweit ich weiß läuft auch die Umstellung der einzelnen Domänen auf den Backbone im Hintergrund. Problem dabei ist nach meiner Vermutung, dass es viel Arbeit ist, es aber keinen Sinn macht, da jemanden anzulernen (schließlich macht man das nur einmal…)

Trotzdem sollte man zügig die neuen Interessenten schnell integrieren, bevor das Feuerlöschen ein Dauerzustand wird. Bis jetzt habe ich da aber durchaus noch Verständnis. Wenn in einem Monat die Admins aus Aachen allerdings immer noch nicht mitarbeiten können, dann schließe ich mich nämlich meinen Vorrednern an, dann läuft definitiv was schief mit der Nachwuchsarbeit.

1 Like

Das stimmt so schlicht nicht. Wobei die Definition von „wir“ sicher zu kären wäre.

Das nutzt uns allen aber eh nix und da rumzuplöppern kostet unötig Zeit und Kraft die wir sinnvoller verwenden können.

Ich würde mir folgendes wünschen, sobald die Probleme abgefedert sind:

  • Das Wachstum und den Ausbau „vorausschauender“ betreiben
  • Allg. zugängliche Informationen wie z. B. Performance Stats (die gibt es bestimmt, wie es alles gibt nur wenige wissen wo). So können Communitys von denen der Verein nicht mal was weiß, sich selber schon ein Bild machen
  • Wissen verallgemeinern, aktuell halten, zugänglicher machen (korreliert mit dem Satz drüber)

Einfach bessere Kommunikation und aktuelle Wissensquellen an EINER zentralen (Verteil)Stelle. Hilfe dazu einfordern und anfragen.

Das gilt nicht nur für die Technik. Selbst so Dinge „wir sind im RIPE“ findet sich nicht mal als News-Schnipsel auf der Website des e. V. Wir haben dafür keine Quelle gefunden, außer dem RIPE Eintrag beim RIPE dort.

Beispiel: wir es Montag eine Info geben zu:
Was klemmte
Was wurde gemacht
Wie sieht es jetzt aus
Was ist noch von wem bis wann zu tun
Was sind die Konsequenzen

Lasst uns die aktuellen Engpässe lösen und überlegen wie wir damit in Zukunft proaktiv (Bingo!) umgehen wollen. Ich wäre dabei, wenn sich da was produktives abzeichnet bzw. würde dazu beitragen. Viele andere sicher auch.

Viele Grüße, Fx

4 Likes

Habt ihr schon was gemacht?

Es ist gerade Stoßzeit, aber das Netz ist wieder erstaunlich flott. :smiley:

2 Likes

Wow, das ist bei 530 Nodes mit 876 Clients echt erstaunlich. :smiley:

Vermutlich ist heute die Last besser ausbalanciert als in den vergangenen Tagen.

1 Like

Nicht ganz so toll wie bei @yayachiken, aber gegenüber gestern Abend mit etwa 100 kbit/s deutlich besser!

Die Node ist heute auch mit 2 Supernodes verbunden:
There are 4 peers configured, of which 2 are connected:
mesh_vpn_backbone_peer_rheinufer0: connected for 5330.039 seconds
mesh_vpn_backbone_peer_rheinufer1: not connected
mesh_vpn_backbone_peer_rheinufer3: not connected
mesh_vpn_backbone_peer_rheinufer2: connected for 5328.291 seconds

Gestern war das eine Zitterpartie zwischen 0 und einer Verbindung.

Name links vpn
Supernode: rheinufer0 0 1 152
Supernode: rheinufer1 0 1 200
Supernode: rheinufer2 0 3 151
Supernode: rheinufer3 0 1 187

@nomaster Wo liegen denn derzeit die Limits?

Ist das mit den unvollständigen Links untereinander Absicht?

1 Like

Müssen wir uns Sorgen machen? :wink:
Supernode: rheinufer3 0 1 251
Supernode: rheinufer2 0 2 199
Supernode: rheinufer1 0 0 0
Supernode: rheinufer0 0 1 201

Gibt es Neues zu den angekündigten Arbeiten?
Aktueller Stand bei mir über Freifunk:

Vorhin ging gar nichts. Ich kann natürlich nicht ausschließen, dass das Problem bei mir liegt.
Deshalb schicke ich mal den Status des Routers mit:

Model: Ubiquiti Nanostation M
Firmware release: 2014.4-stable-1

22:57:35 up 2:01, load average: 0.13, 0.39, 0.56

6: br-client: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether 68:72:51:12:1f:61 brd ff:ff:ff:ff:ff:ff
inet6 2a02:f98:0:28:6a72:51ff:fe12:1f61/64 scope global dynamic
valid_lft 86380sec preferred_lft 3580sec
inet6 fda0:747e:ab29:cafe:6a72:51ff:fe12:1f61/64 scope global dynamic
valid_lft 86400sec preferred_lft 3600sec
inet6 fe80::6a72:51ff:fe12:1f61/64 scope link
valid_lft forever preferred_lft forever

         total         used         free       shared      buffers

Mem: 28860 26256 2604 0 2152
-/+ buffers: 24104 4756
Swap: 0 0 0

Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 2304 2304 0 100% /rom
/dev/mtdblock5 4288 300 3988 7% /overlay
Neighbourswlan0Joined IBSS 32:ca:ff:ee:ba:be (on wlan0)
SSID: wifimesh-rheinufer
freq: 2422

Station 6a:75:52:0a:2d:67 (on wlan0)
inactive time: 40 ms
rx bytes: 51259145
rx packets: 424407
tx bytes: 1200
tx packets: 36
tx retries: 280
tx failed: 25
signal: -78 [-81, -81] dBm
signal avg: -77 [-81, -80] dBm
tx bitrate: 104.0 MBit/s MCS 13
rx bitrate: 6.5 MBit/s MCS 0
authorized: yes
authenticated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no

VPN statusfastd running for 7232.741 seconds
There are 4 peers configured, of which 2 are connected:

mesh_vpn_backbone_peer_rheinufer0: not connected
mesh_vpn_backbone_peer_rheinufer1: connected for 7169.949 seconds
mesh_vpn_backbone_peer_rheinufer3: connected for 7172.725 seconds
mesh_vpn_backbone_peer_rheinufer2: not connected

Kann ich teilweise bestätigen. Speedtest zeigt zwar 1,32 MBit/s down 2,54 MBit/s up (an einer Gigabitleitung), aber Web-Browsing ist nicht sehr gut möglich (Seitenaufbau ~30 Sekunden). Warum, kann ich nicht sagen.

Gibt es einen einfachen Schalter der sagt:
„Internet weiterhin freigeben, aber ohne VPN?“

Soweit ich weiß absichtlich nicht. In diesem Fall wäre es nämlich zu einfach, den versehentlich umzulegen, sei es durch Anwenderfehler oder aktuen Routeralzheimer oder auch Programmfehler.

Wer das möchte, der kann das tun. Auf der Kommandozeile. Und sich die Befehle dazu selbst zusammensuchen. (Und bei der Suche vielleicht nochmal ins Nachdenken kommen.)
Ich werde niemanden dazu anstiften.

Hi

wie sieht es denn bei fastd mit sowas wie AES-NI aus?
Ich hab das bisher nur für luks verwendet, aber ich glaub hab schon gut was gebracht. Keine Ahnung was fastd für n Crypto macht, aber so n bisschen hardwarebeschleunigung kann nie schaden.

FastD macht mit der neuen Firmware Salsa2012+UMAC.

Soweit ich es verstanden habe haben wir für das letzte Wochenende wichtige Erweiterungen des Backends auf der Agenda gehabt, die den Performance Problemen entgegentreten sollten.

Ist das geglückt? Wie kann man™ das nachvollziehen bzw. wie wird das gemessen und herausgestellt?

Viele Grüße, Fx

Menge laufender Gateways mit:

batctl gwl

und/oder zusätzlich Blick in die Map wo die Tunnel terminieren…

Hi zusammen,

Die neue Gateways sind schon fertig, allerdings gibt es noch Probleme mit den Client-Verbindungen die wir momentan prüfen. Danach kommt ein neuer Stable-Release welche die neue Supernodes in der Config bereithält.
Wir sind bereits mit dem Provider in Kontakt um das Problem zu lösen, scheint ein Netzwerkproblem beim Provider zu sein der IPv6 nicht durchlässt.

Sobald das erfolgreich getestet ist haben wir 7 Supernodes aktiv.

2 Likes

Die Verbindungen zu den neuen Supernodes funktionieren nun, Beta Nodes haben bereits die neue Konfiguration. Die Stable Version folgt spätestens heute Abend.

1 Like

Man kann sich übrigens einen groben Überblick über die Supernodes und die Verbindungen in der Graph Darstellung anschauen. http://ffmap.freifunk-rheinland.net/graph.html

Edit: natürlich ist die Darstellung aufgrund von ALFRED/Map-Foo manchmal ein bisschen buggy, das wollte ich keinem vorenthalten :stuck_out_tongue: