[Berlin-wireless] kann ich am vpn-Durchsatz noch etwas optimieren?

[Bastian]

Hallo Christian,

es gibt da eine Sache die du probieren könntest:

Momentan steht in der OpenVPN-Client Konfiguration "remote
vpn03.berlin.freifunk.net", was random eine der momentan 5 und
verfügbaren vpn03 Instanzen auswählt.

Wenn ich mir die Stats zu den vpn03s so angucke, dann ist
vpn03e.berlin.freifunk.net momentan am wenigsten ausgelastet.

Du kannst also einfach mal probieren eine sortierte Liste in der
"remote" Section einzutragen. Beginnend mit vpn03e und danach wohl vpn03d.

Note: Sollten wir eine weitere vpn03-Instanz erzeugen, dann fehlt die in
deiner Liste!

Cheers, Bastian

On 03/28/2016 02:00 PM, Christian Hammel wrote:
> Hallo Liste,
> 
> bei der Mitversorgung der NUK gegenüber scheint der Durchsatz des VPN
> (irgendwo zwischen 2 und 9 Mbit down und irgendwo zwischen 0,2 und 0,5
> up) zum Engpass zu werden.
> 
> Hat jemand eine Idee,
> 1. ob mit einer Leitung von 25Mbit down und 1 MBit up, rund 70
> gleichzeitigen usern und knapp 50 GB am Tag überhaupt mehr geht?
> 2. ob ich da noch etwas feintunen könnte? Insbesondere ob die UDP und
> openVPN-Fehlermeldungen Anlass dazu geben?
> 
> Danke
> 
> Christian
> 
> 
> Die Randbedingungen:
> 
> Aufbau:
> Internet - VPN03 - Wuthenow9 - Funbrücke/OLSR - Sochos1 -
> PowerlineEthernet/OLSR - Sochos2
> Die Router sind 4300er unter Kathleen 0.1.2
> 
> Ankommende Bandbreite über vpn:
> Mit dem Lappi oder Smartphone an Wuthenow9 zeigt der ookla-Speedtest
> maximal an: 15ms ping, rund 9 Mbps down und rund 0,5 mbps up. In der
> prime-time geht ping schon mal auf über 300 steigen, down auf 2 und up
> auf 0,1 bis 0,2.
> Im Monitor sieht das so ähnlich aus:
> http://monitor.berlin.freifunk.net/detail.php?p=interface&t=if_octets&ti=eth0.4&h=Wuthenow9&s=8035200&x=800&y=350
> 
> 
> Fehlermeldungen:
> Das Systemprotokoll von Wuthenow9 meldet recht oft
> "daemon.err openvpn(ffvpn)[1975]: Authenticate/Decrypt packet error:
> packet HMAC authentication failed".
> 
> Das Kernelprotokoll meldet immer mal wieder "UDP: short packet: From
> 77.87.48.10:1194 1514/1474 to 192.168.2.10:54733" (192.168.2.10 ist mein
> FF-Router).
> 
> Die Ping-Droprate liegt (lt. Routerstatistik) bis auf kurze Peaks unter 5%.
> 
> Der Berkeley Netalyzer meldet fast immer Probleme mit fragmentiertem
> UDP, das nicht ankomt, fehlende Mitteilung an deren Server, dass sie mit
> einer MTU von 1300 senden sollen und hohes Buffering:
> http://n2.netalyzr.icsi.berkeley.edu/restore/id=36ea240d-8071-04b40aa9-26da-4423-b104/rd
> 
> In der prime-time bemängelt der Test zusätzlich hohe Latenz und hohe
> droprates (wohl zu erwarten, wenn es zu eng wird)
> 
> bereits versucht:
> MTU überall auf 1300 herabgesetzt.
> maxassoc herabgesetzt auf 5 Clients weniger als DHCP-IPs da sind.
> 
> Danke
> 
> Christian
> 
> 
> 
> 
> 
> 
> 
> 
> 


-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 473 bytes
Beschreibung: OpenPGP digital signature
URL         : <https://lists.berlin.freifunk.net/pipermail/berlin/attachments/20160328/d6bf00e2/attachment.sig>