Hi,
zu Baustellen im VPN-Backbone habe ich mal die vpnkarte im Syncthing aktualisiert und mit kleinen (roten) ToDo's versehen.
Am Donnerstag, 16. Juli 2015, 22:20:35 schrieb Bjoern Franke:
srv10 und srv11 laufen nun als vpn06 und vpn05. Über den AirVPN von vpn06 lassen sich 200Mbit schaufeln. Auf srv10 habe ich nun einen Hurricane-Electric-Tunnel[0] eingeschaltet, der statt des FFRL-Tunnels announced wird - über den Tunnel läufts direkt auf dem Gateway mit 400Mbit.
Nun denkt man sich: Ok, das Netz sollte nun schneller laufen. Aber nope, mein Router an vpn02/srv12 (mit IP von vpn06/srv10, warum auch immer) eiert mit 100-200kb/s von mirror.gnomus.de (beliebter Arch -Mirror) rum.
Bei mir ähnlich und zwar bei der Datenübertragung von srv12 zu einer direkt mit srv12 verbundenen Node. Folgendes habe ich gemacht:
*Node zu srv12 verbinden *mit "batctl tr" prüfen ob eine direkte Verbindung besteht und die Daten nicht irgendeinen lustigen Umweg durchs Netz nehmen *Daten von srv12 zur Node übertragen mit "wget -O /dev/null http://10.18.8.1/speedtest"
Sehr konstant 3-4Mbit/s. 100Mbit/s wären mit meiner Leitung theoretisch Möglich, faktisch schafft mein Router aber nur ca. 10Mbit/s (Erfahrungswert). Bei einer Übertragung außerhalb von Freifunk komme ich auf ca. 25Mbit/s (mein WLAN ist nicht schneller). Insgesamt müsste eigentlich das doppelte oder dreifache übertragen werden.
Für mich sieht es danach aus, als seien langsame Exits gar nicht das Problem sondern eine der beiden Seiten (oder beide) haben ein Problem mit dem Fastd- VPN. Hier müsste jemand testen ob die Probleme auch mit einem Offloader in der Form auftreten.
Mal rein spekulativ überlegt ohne dass ich da übertrieben die Ahnung habe: Wenn wir uns überlegen, was mit einem Datenpaket auf beiden Seiten jeweils gemacht wird, dann würde mich die Datenrate gar nicht unbedingt wundern. Ich kenne da jetzt die Details nicht aber ankommende Daten an einem Router z.B. werden ja erstmal in einem FIFO-Buffer abgelegt. Die Maschine nimmt dann jeweils das vorderste Paket und bearbeitet es. Da Fastd im Userspace läuft sind dafür mindestens 2 Kontextswitche und Rechenzeit zum Entschlüsseln nötig und erst anschließend kommt dann das nächste Paket an die Reihe. Da viele Datenpakete für alles mögliche ankommen, liegt so ein Paket eine ganze weil in einem oder mehreren Puffern und wartet darauf verarbeitet zu werden und im schlimmsten Fall läuft ein Puffer voll und Daten werden verworfen sodass sie neu übertragen werden müssen. Das macht den ganzen Spaß langsam ohne dass die CPU zu 100% ausgelastet ist. Vice Versa natürlich auf einer Supernode.
Auf meiner Node hat fastd eine Grundauslastung von ca. 11%. Das heißt, da kommen die ganze Zeit Pakete für alles mögliche rein. Vielleicht führt das schon dazu, dass Kapazitäten ausgelastet werden und für eine ordentliche Datenübertragung keine Ressourcen zur Verfügung stehen. Muss man wirklich mal testen was ein Offloader zu dem Problem sagt. Der dürfte ja genug Ressourcen haben.
Das war jetzt nur so eine Idee, aber evtl. kennt sich damit ja jemand im Detail aus und kann den Ansatz nachvollziehen?
LG Clemens