Performanceprobleme mit Unitymedia

Ja, schon. Aber mit Offloader sieht es ja auch nicht besser aus. Wobei ich es noch nicht an dem Anschluss dort sondern nur an meinem getestet habe.

naja :-) würde sagen irgendwas zwischen 2 und 5 ?

Hab das Ding ja eh schon da stehen. Ich werde jetzt an verschiedenen Anschlüssen noch einmal testen. Mal sehen, ob da doch noch ein Unterschied zu sehen ist.

Da möchte ich nochmal drauf eingehen. Es sieht von Außen vielleicht so aus als wäre unser Netz an sich das Problem. Da kann ich dich aber beruhigen, wir haben noch genug Kapazitäten übrig und daran liegt es nicht. Das monitoren wir ziemlich penibel und zuverlässig. Ausnahme ist so etwas wie der kaputte Gateway, den haben wir daher ja auch ziemlich schnell deaktiviert.
Viel häufiger ist das Problem im Peering der Anbieter zu finden, die den Anschluss betreiben. Hier wird leider zu wenig offen gepeert, also Netzwerk Routen direkt ausgetauscht, als es nötig wäre. Dadurch sind die Verbindungen in andere Netzwerke (Upload) oder aus anderen Netzwerken (Download) überlastet, es geht nichts mehr durch und Pakete gehen verloren was wiederum TCP überhaupt nicht gefällt (Ist nen anderes Thema -> Congestion Avoidance). Ich kenne Leute mit einem 100Mbit/s Anschluss in Düsseldorf die über einen Speedtest die 100Mbit/s sehen, aber zu fast allem anderen nur 5 Mbit/s bekommen. Ist übrigens der gleiche Anbieter wie bei dir. Sprich es kommt sehr darauf an wo du in deren Netz hängst und wie sie das ausgebaut haben. Daher können wir das häufig auch nicht weiter beeinflussen wenn selbst über einen Offloader nicht so viel geht wie technisch möglich wäre. Letztlich hängt es daran das der Laden zu dem dein Anbieter gehört einfach eine total miese Peering Policy hat. Nachlesen kann man die übrigens hier: http://www.libertyglobal.com/oo-bs-settled-peering-policy.html

Was du mal machen kannst um einen leichten Eindruck zu bekommen ist, via IPerf3 direkt gegen unsere Gateways messen. Also ohne Freifunk Knoten oder Offloader dazwischen. Das gibt dir schon mal einen Hinweis wie es aussieht. Es kann aber auch einfach sein, dass der Anbieter in den Daten rumpfuscht, das ist für andere VPN Protokolle zum Beispiel bekannt.

Bin mal auf deine Messungen gespannt. Bitte immer mit IPerf3 gegen die Gateways direkt (interne Adresse) Messen, nur diese Ergebnisse sind wirklich aussagekräftig.

Habe ich mal gemacht, es liegt wirklich am Peering von Unitymedia (ich nenne hier den Schuldigen mal beim Namen, die wissen ja von der Situation und tun nichts dagegen).

Ich habe folgendes aufgerufen:
for ip in 4 6 ; do for gw in 2 3 6 7 8 9 ; do for mode in " " "-R" ; do iperf3 -c gw0$gw.ffrn.de -$ip -t 5 $mode -i 0 ; done ; done ; done | tee /tmp/iperf

Hier die Ergebnisse:

Unitymedia 400/20MBit: https://paste.ffrn.de/?81d4223eafbb9ec7#oL46WncPMOUdgOKwMNuqVbWnPs4pVFy2HkBSt/BGhTE=

Telekom 100/40MBit: https://paste.ffrn.de/?6ac719a048f857f0#nqsipiSQB/GM8eZtHuEMB6ud9e4QYOLcalKgvm3Nx38=

Telekom 16/1MBit: https://paste.ffrn.de/?afa2f50b80b63833#F60flfJ2PfPlTCjcJIaeQ274RZOQ8b2s5Ghi4I/fI8o=

Zusammenfassung: Telekom Wirespeed, Unitymedia schafft nur ein Bruchteil des verkauften Geschwindigkeit.

PS: Warum läuft auf manchen Gateways iperf nicht auf IPv6?

3 „Gefällt mir“

Hey, danke für deine Tests. Genau das meinte ich :)

Weil da bald eine Umstellung ins Haus steht und die Gateways selbst kein V6 extern haben. Das wird sich aber vermutlich in den nächsten 2 Wochen ändern.

Habe heute nochmal etwas anderes gemessen:

Da die Speedtest-Webseiten teilweise tollen Durchsatz vorgaukeln, reale Downloads aber sehr langsam sind, habe ich mal iperf länger laufen lassen, mit interessantem Ergebnis: Die TCP-Sessions werden scheinbar am nach ein paar Sekunden gedrosselt. Damit sind Speedtests und Websurfen schnell, Downloads aber total langsam. Und eine dauerhaft bestehende (TCP) VPN-Session wird damit auch zum Flaschenhals.

root@routersrv1:~# iperf3 -c gw03.ffrn.de -4 -t 30 -R -i 1            
Connecting to host gw03.ffrn.de, port 5201
Reverse mode, remote host gw03.ffrn.de is sending
[  4] local 10.9.2.19 port 55789 connected to 138.201.30.247 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec  42.1 MBytes   353 Mbits/sec                  
[  4]   1.00-2.00   sec  27.4 MBytes   230 Mbits/sec                  
[  4]   2.00-3.00   sec  10.0 MBytes  84.2 Mbits/sec                  
[  4]   3.00-4.00   sec  9.10 MBytes  76.3 Mbits/sec                  
[  4]   4.00-5.00   sec  9.47 MBytes  79.5 Mbits/sec                  
[  4]   5.00-6.00   sec  9.67 MBytes  81.1 Mbits/sec                  
[  4]   6.00-7.00   sec  8.96 MBytes  75.2 Mbits/sec                  
[  4]   7.00-8.00   sec  7.53 MBytes  63.1 Mbits/sec                  
[  4]   8.00-9.00   sec  5.72 MBytes  48.0 Mbits/sec                  
[  4]   9.00-10.00  sec  5.22 MBytes  43.8 Mbits/sec                  
[  4]  10.00-11.00  sec  4.93 MBytes  41.3 Mbits/sec                  
[  4]  11.00-12.00  sec  5.02 MBytes  42.1 Mbits/sec                  
[  4]  12.00-13.00  sec  5.27 MBytes  44.2 Mbits/sec                  
[  4]  13.00-14.00  sec  5.55 MBytes  46.5 Mbits/sec                  
[  4]  14.00-15.00  sec  4.90 MBytes  41.1 Mbits/sec                  
[  4]  15.00-16.00  sec  5.06 MBytes  42.5 Mbits/sec                  
[  4]  16.00-17.00  sec  4.59 MBytes  38.5 Mbits/sec                  
[  4]  17.00-18.00  sec  4.95 MBytes  41.5 Mbits/sec                  
[  4]  18.00-19.00  sec  4.69 MBytes  39.3 Mbits/sec                  
[  4]  19.00-20.00  sec  4.31 MBytes  36.2 Mbits/sec                  
[  4]  20.00-21.00  sec  3.47 MBytes  29.1 Mbits/sec                  
[  4]  21.00-22.00  sec  3.78 MBytes  31.7 Mbits/sec                  
[  4]  22.00-23.00  sec  4.05 MBytes  33.9 Mbits/sec                  
[  4]  23.00-24.00  sec  4.65 MBytes  39.0 Mbits/sec                  
[  4]  24.00-25.00  sec  4.76 MBytes  39.9 Mbits/sec                  
[  4]  25.00-26.00  sec  5.19 MBytes  43.6 Mbits/sec                  
[  4]  26.00-27.00  sec  5.10 MBytes  42.8 Mbits/sec                  
[  4]  27.00-28.00  sec  5.26 MBytes  44.1 Mbits/sec                  
[  4]  28.00-29.00  sec  3.70 MBytes  31.0 Mbits/sec                  
[  4]  29.00-30.00  sec  2.21 MBytes  18.5 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-30.00  sec   229 MBytes  63.9 Mbits/sec  230             sender
[  4]   0.00-30.00  sec   227 MBytes  63.4 Mbits/sec                  receiver

iperf Done.
root@routersrv1:~# iperf3 -c gw02.ffrn.de -4 -t 30 -R -i 1
Connecting to host gw02.ffrn.de, port 5201
Reverse mode, remote host gw02.ffrn.de is sending
[  4] local 10.9.2.19 port 55941 connected to 5.9.158.125 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec  33.8 MBytes   284 Mbits/sec                  
[  4]   1.00-2.00   sec  28.1 MBytes   236 Mbits/sec                  
[  4]   2.00-3.00   sec  8.27 MBytes  69.4 Mbits/sec                  
[  4]   3.00-4.00   sec  6.17 MBytes  51.8 Mbits/sec                  
[  4]   4.00-5.00   sec  4.43 MBytes  37.1 Mbits/sec                  
[  4]   5.00-6.00   sec  3.35 MBytes  28.1 Mbits/sec                  
[  4]   6.00-7.00   sec  3.39 MBytes  28.4 Mbits/sec                  
[  4]   7.00-8.00   sec  2.31 MBytes  19.3 Mbits/sec                  
[  4]   8.00-9.00   sec  1.51 MBytes  12.6 Mbits/sec                  
[  4]   9.00-10.00  sec  1.35 MBytes  11.3 Mbits/sec                  
[  4]  10.00-11.00  sec  1.97 MBytes  16.5 Mbits/sec                  
[  4]  11.00-12.00  sec  2.38 MBytes  20.0 Mbits/sec                  
[  4]  12.00-13.00  sec  3.12 MBytes  26.2 Mbits/sec                  
[  4]  13.00-14.00  sec  3.20 MBytes  26.9 Mbits/sec                  
[  4]  14.00-15.00  sec  3.72 MBytes  31.2 Mbits/sec                  
[  4]  15.00-16.00  sec  2.59 MBytes  21.7 Mbits/sec                  
[  4]  16.00-17.00  sec  2.74 MBytes  23.0 Mbits/sec                  
[  4]  17.00-18.00  sec  2.65 MBytes  22.2 Mbits/sec                  
[  4]  18.00-19.00  sec  3.18 MBytes  26.7 Mbits/sec                  
[  4]  19.00-20.00  sec  3.12 MBytes  26.2 Mbits/sec                  
[  4]  20.00-21.00  sec  3.06 MBytes  25.6 Mbits/sec                  
[  4]  21.00-22.00  sec  2.98 MBytes  25.0 Mbits/sec                  
[  4]  22.00-23.00  sec  2.52 MBytes  21.1 Mbits/sec                  
[  4]  23.00-24.00  sec  2.31 MBytes  19.4 Mbits/sec                  
[  4]  24.00-25.00  sec  2.33 MBytes  19.5 Mbits/sec                  
[  4]  25.00-26.00  sec  1.59 MBytes  13.3 Mbits/sec                  
[  4]  26.00-27.00  sec  1.93 MBytes  16.2 Mbits/sec                  
[  4]  27.00-28.00  sec  2.60 MBytes  21.8 Mbits/sec                  
[  4]  28.00-29.00  sec  2.61 MBytes  21.9 Mbits/sec                  
[  4]  29.00-30.00  sec  2.66 MBytes  22.3 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-30.00  sec   148 MBytes  41.5 Mbits/sec   72             sender
[  4]   0.00-30.00  sec   146 MBytes  40.8 Mbits/sec                  receiver

iperf Done.
2 „Gefällt mir“

Ich bin entsetzt über das Ergebnis der Messung. Das erklärt dann auch, warum Kabelbetreiber etwas gegen Bittorrent haben. Da gibt es viele kurze TCP-Verbindungen, die jeweils nur wenige MB übertragen. Da greift dann die Drosselung noch nicht.

Ich sehe das als Täuschung eines Providers, der sein Backbone nicht in der Geschwindigkeit ausbaut, wie er es bei den Endkundenanschlüssen tut.

Interessant wären jetzt Messungen über UDP, auf dem L2TP aufbaut.

1 „Gefällt mir“

Messungen über UDP sind prinzipbedingt etwas schwieriger, ich werde das aber trotzdem mal testen.

Ob das jetzt wirklich eine Drossel ist, weiß ich nicht und möchte ich auch nicht unbedingt davon ausgehen. Es kann genau so gut sein, dass die Interfaces einfach überlastet sind und dann Pakete verwerfen. Das wiederum führt zu Paketverlust der bei TCP ein ähnliches Muster erzeugen könnte. Ganz ausschließen kann ich aber nicht das die daran rumspielen.
Eine Möglichkeit es weiter zu untersuchen wäre ein Paketmittschnitt mit Wireshark während einem solchen Test.

Reicht der TCP-Stream oder muss noch ICMP oder etwas anderes dazu? Auf dem Interface ist relativ viel los, und ich will nicht zuviel loggen.

Am besten du schneidest einfach alle in Richtung der IP des Gateways mit.

Stimmt, da hätte ich auch selber drauf kommen können :-/

Schicke Dir den Link per PN.

Hier der Console-Output:

root@routersrv1:~# iperf3 -c gw02.ffrn.de -4 -t 15 -R                                                                                                                                                                               
Connecting to host gw02.ffrn.de, port 5201                                                                                                                                                                                            
Reverse mode, remote host gw02.ffrn.de is sending                                                                                                                                                                                     
[  4] local 10.9.2.19 port 35748 connected to 5.9.158.125 port 5201                                                                                                                                                                   
[ ID] Interval           Transfer     Bandwidth                                                                                                                                                                                       
[  4]   0.00-1.00   sec  21.6 MBytes   181 Mbits/sec                                                                                                                                                                                  
[  4]   1.00-2.00   sec  5.15 MBytes  43.2 Mbits/sec                                                                                                                                                                                  
[  4]   2.00-3.00   sec  3.12 MBytes  26.1 Mbits/sec                                                                                                                                                                                  
[  4]   3.00-4.00   sec  2.59 MBytes  21.7 Mbits/sec                                                                                                                                                                                  
[  4]   4.00-5.00   sec  1.98 MBytes  16.6 Mbits/sec                                                                                                                                                                                  
[  4]   5.00-6.00   sec  1.37 MBytes  11.5 Mbits/sec                                                                                                                                                                                  
[  4]   6.00-7.00   sec  1.42 MBytes  11.9 Mbits/sec                                                                                                                                                                                  
[  4]   7.00-8.00   sec  1.62 MBytes  13.6 Mbits/sec                                                                                                                                                                                  
[  4]   8.00-9.00   sec  1.49 MBytes  12.5 Mbits/sec                                                                                                                                                                                  
[  4]   9.00-10.00  sec  1.38 MBytes  11.5 Mbits/sec                                                                                                                                                                                  
[  4]  10.00-11.00  sec  1.80 MBytes  15.1 Mbits/sec                                                                                                                                                                                  
[  4]  11.00-12.00  sec  1.58 MBytes  13.3 Mbits/sec                                                                                                                                                                                  
[  4]  12.00-13.00  sec  1.35 MBytes  11.3 Mbits/sec                  
[  4]  13.00-14.00  sec  1.20 MBytes  10.1 Mbits/sec                  
[  4]  14.00-15.00  sec  1.53 MBytes  12.8 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-15.00  sec  52.0 MBytes  29.1 Mbits/sec   43             sender
[  4]   0.00-15.00  sec  49.3 MBytes  27.6 Mbits/sec                  receiver

iperf Done.

@leah @Tobox Kam bei der Analyse des Wiresharkmittschnitts eigentlich noch was interessantes raus ?

Ich hab hier mal einen Iperf test von einem anderen Unitymedia Anschluss (100/2Mbit/s) gegen die Gateways gemacht.
Diesmal aber nicht in Hessen sondern in BW:

Hier sieht die Welt wieder total normal aus => also vergleichbar den Ergebnissen von @Tobox am Telekomanschluss.
Alles nahezu Wirespeed , egal zu welcher Zeit.

Der neue Test von Netflix (www.fast.com) hat übrigens genau das gleich gezeigt. Am UT-Hessen-Anschluss kommen da ja nur einige Mbit raus. UT-BW zeigt 80-90 %und zwar sogar auch Abends um 21 uhr!!

Der UT-Hessen Anschluss bricht übrigens in den Abendstunden immer auf maixmal 50Mbit/s von den 400Mbit/s ein.
Und zwar bei jeder Testmethode.

Hat jemand noch vergleichbare Probleme bei UT-Hessen oder anderen Anbietern ?

So, ich hatte jetzt Zeit mir den Mitschnitt mal anzugucken. Dabei habe ich die Werte mit denen von meinem Anschluss bei dem ich 100% der Leistung bekomme verglichen. Folgendes ist mir dabei aufgefallen:

Die Window Size stimmt soweit und da sehe ich kein Problem. Es sieht also nicht so aus, als würde TCP hier runter skalieren. Das wäre normalerweise bei Überlastung und Paketverlust der Fall. Sprich die Werte sehen für beide Verbindungen weitestgehend gleich aus.

Graph @tobox:

Graph @leah :

Die Unterschiede ergeben sich vermutlich durch verschiedene Implementierungen des TCP Stacks.

Beim Durchsatz, sieht es da wie zu erwarten dann anders aus, hier bricht der Durchsatz bei @tobox ziemlich schnell ein, bei mir bleibt er hingegen gleich.

Graph @tobox:

Graph @leah:

Für die RTT, das ist in dem Fall die Zeit die das Paket im TCP Stack unserer Rechner braucht um verarbeitet zu werden und wieder gesendet zu werden, wird es dann wirklich spannend.

Im Normalfall sollte das so wie bei mir aussehen:


Das heißt die Linie sollte möglichst keine Ausschläge haben die bedeuten, dass der Rechner gerade mit was anderem als Netzwerk Verarbeitung beschäftigt ist.

Bei @tobox sieht das aber dann so aus:

Das ist eher untypisch und spricht dafür, dass das System unter Last stand oder etwas anderes Probleme macht.

Grundsätzlich würde ich das Ganze auch nochmal auf dem Server mitschneiden bräuchte dafür aber vorher eine Ankündigung im Chat von dir @tobox.

Das ist mir auch schon aufgefallen, in Hessen und anderen Bundesländern scheinen die Anschlüsse grundsätzlich stärker überlastet als in BW. Vielleicht liegt es daran, dass das früher mal einem anderen Provider gehört hat und der weniger Misst gebaut hat.

5 „Gefällt mir“

Sehr gute Analyse, womit hast Du das denn gemacht? Sind das die Wireshark-internen TCP-Stream-Grafen? Ich würde mir die Daten damit auch mal genauer ansehen. Bei dem Rechner, mit dem ich den Test gemacht habe, handelt es ich um einen Linux PC mit Quad-Core-Atom, der aber fast nichts anderes macht außer Routing zwischen Firmennetz, Gästenetz, Kabelmodem und DSL-Fallback-Modem. Der Routet bei Backups vom Firmen- ins Gästenetz problemlos mit Gigabit-Wirespeed.

Viellleicht hat das gleichzeitige Capturen mit TCPdump ihn gestört, aber da ich dieselben Testergebnisse auch sehe, wenn ich nicht mitschneide, ist das eher unwahrscheinlich. Ging direkt auf die System-SSD, und es waren ja auch nur ein paar hundert MB.

Ich kann den Test gerne mal wiederholen, wenn Du auf der Gegenseite mitschneiden willst.

Danke. Ja, das waren die internen Analysetools von Wireshark. Sind nur leider nicht immer trivial zu interpretieren, siehe RTT in diesem Fall :P

Das wäre super. Schreib mir dann bitte mal im Chat wenn du Zeit hast es zu machen.

So, ich hab mir jetzt auch nochmal die neuen Werte angeguckt. Ist ganz spannend. Zum einen hast du eine extrem starke Fluktuation was die Werte der RTT angehen, bis sie sich am Ende wenn es langsam wird wieder etwas normalisieren. Gleiches gilt für die Squenznummern die nicht linear laufen sondern Richtung Ende abflachen was ebenfalls nicht normal ist und ein Resultat des Problems ist. Leider ist es da relativ schwer eine tatsächliche Ursache fest zu machen, da wir das komplette Netzwerk zwischen unseren beiden Endpunkten nicht kennen. Grundsätzlich sieht es für mich aber nach einer vollen Queue auf einem der System von Unitymedia aus. Dort werden die Pakete verzögert weil das Interface voll ist oder das System überlastet ist. Das führt zu Verzögerungen die der TCP Algorithmus dann genau richtig interpretiert und die Geschwindigkeit reduziert um die Verbindung stabil zu halten. Leider führt das dann zu eben der von dir beobachteten geringen Bandbreite.

Bei unserem weiteren Versuch kam dasselbe Ergebnis raus. Interessant wäre jetzt mal, die Capture Files von beiden Seiten an den Stellen zu vergleichen, wo diese Sägezähne im RTT entstehen. In der Zeit gehen nämlich zahlreiche Duplicate-Acks raus, die scheinbar nicht ankommen. Sieht für mich fast eher nach Traffic-Shaping aus als nach normalem Packet-Loss oder ähnlichem.

Ich habe mal an meinen TCP-IP-Parametern rumgeschraubt, kam aber immer zu ähnlichen Ergebnissen.

Bei DS-Lite wäre es vielleicht interessant zu vergleichen, wie sich fastd über v4 und v6 verhält - sobald die Gateways per v6 erreichbar sind.

Soweit ich das bisher beurteilen kann, ist es eine lokale Überlastung des Unitymedia-Backbones in Südhessen. Da wird sich IPv6 wahrscheinlich genauso verhalten wie IPv4. Testen könnte man das allerdings mal - wer hat Unitymedia-Dual-Stack lite?

Ich kann das gerne mal mit meinem DS-lite-Anschluss testen. Kannst Du mir die Wireshark-Konfiguration geben und welchen Traffic Du erzeugt hast?