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