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?
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.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.
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:
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.
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?
