[Berlin-wireless] Lastverteilung VPN

[Philipp Borgers]

On Sat, Jan 24, 2015 at 02:03:54PM +0100, Sven-Ola Tuecke wrote:
> Nochmal Hallo Philipp,
> 
> so eine IPerf-Messung sagt aus, wievel "Restbandbreite" übrig ist. Zeigt
> ggf. an, welcher Server wie gut angebunden ist. Dem nach meinem Gefühl
> etwas besser aufgestellten Vpn03b können wir also mehr überhelfen.
> Trotzdem werde ich den Eindruck nicht los, dass sich alle Clients
> irgendwie auf eine Kiste einschießen. Theorie: die Mehrheit hat
> Google-als-DNS, und Google rückt zu jeder geraden Minute einen bestimmte
> IP zu einem DNS-Namen. Die Supernode verfälschen allerdings das Bild hier.

Die Clients schießen sich u.a. auf eine Kiste ein, weil sie nicht mehr als eine
kennen.

Die Firmware enthält absichtlich keinen Google-DNS oder ähnlich zweifelhafte
DNS-Server. Die README verrät mehr über die gewählten DNS-Server.

> Bin nicht sicher, aber dagegen könnte z.B. helfen: beim sonntäglichen
> Neustart für 10 Minuten eine UDP-Firewall-Regel, die jeweils gerade /
> ungerade Einwähl-IPs blockt.

Ich denke das löst unser Problem nicht.

> Wegen iperf: Aussagekräftiger halte ich Werte wie "vieviele Routen,
> wieviel Conntracks, wieviele Tunnel, wieviel Übertragung". Gibt bei mir
> im /home/sven-ola/stats.sh, damit guck' ich mir das an. Jeweils einmal
> nach Gleichzeitiger-Neustart-Openvpn-mit-Debug, Nach 'rüberschieben
> Chemniz, nach 'rüberschieben Oldenburg.
> 
> sven-ola at vpn03a:~$ ./stats.sh
> 12:15:26: v4r=1916 v6r=140 ctrack=10691, last 60s eth rx=9093 kB/s tx=9118 kB/s tun rx=768 kB/s tx=7271 kB/s
> 13:37:30: v4r=2078 v6r=139 ctrack=11443, last 60s eth rx=7918 kB/s tx=7823 kB/s tun rx=434 kB/s tx=6647 kB/s
> 13:58:31: v4r=1887 v6r=137 ctrack=12265, last 60s eth rx=8227 kB/s tx=8239 kB/s tun rx=440 kB/s tx=7176 kB/s
> 
> sven-ola at vpn03b:~$ ./stats.sh 
> 12:15:37: v4r=329 v6r=3 ctrack=7109, last 60s eth rx=2797 kB/s tx=2841 kB/s tun rx=83 kB/s tx=2600 kB/s
> 13:37:42: v4r=557 v6r=3 ctrack=7792, last 60s eth rx=3657 kB/s tx=3721 kB/s tun rx=124 kB/s tx=3391 kB/s
> 13:58:43: v4r=811 v6r=3 ctrack=8602, last 60s eth rx=3449 kB/s tx=3511 kB/s tun rx=117 kB/s tx=3206 kB/s
> 
> Achso. Ist erst früher Nachmittag. Abends ist mehr Daten.

Beides hat Aussagekraft, aber der iperf Benchmark zeigt, wie Basti auch
andeutet, das der Kernel/die VM noch Luft hat. Jetzt können wir spekulieren,
dass openvpn irgendwas falsch macht.

Es gibt z.B. noch eine ganze Reihe von Kontext-Wechseln.

Weißt du welche Implikationen der Aufruf des IP-Lern-Scripts auf dem Server hat?
Wo/wann wird das aufgerufen?

> // Sven-Ola
> 
> Am 24.01.2015 um 13:00 schrieb Philipp Borgers:
> > Hier die iperf logs:
> >
> > https://gist.github.com/booo/fe29553989fb209be1cf
> >
> > Tests liefen parallel zu laufenden Verbindungen.
> 
> 



> _______________________________________________
> Berlin mailing list
> Berlin at berlin.freifunk.net
> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-signature
Dateigröße  : 819 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20150124/4dbea174/attachment.pgp>