Interessante Einschränkungen bei der Uploadgeschwindigkeit

[rhaessner]

Hallo,

grundsätzlich bin ich mit meinem Kabelvertrag 500/50 sehr zufrieden.

Seit 3 Wochen hapert es aber gewaltig am Upload. Der schwankt statistisch zwischen 1 und 20 MBit/s, gemessen mit https://www.speedtest.net. Download ist immer absolut perfekt.

Der Service war sehr schnell, hat viel Zeit in meiner Wohnugn verbracht, die Fritzbox getauscht, Dämpfungsmessungen vorgenommen, alles ohne Wirkung.

Bin sehr beeindruckt von der Schnelligkeit des Services, auch wenn es erst einmal nicht geholfen hat.

Ich habe einmal selbst ein wenig weiter gespielt und Interessantes gemessen, ohne, dass ich alles interpretieren kann.

a) Der Speedtest mit https://www.speedtest.net von Ismaning zum nächstgelegenen Vodafon-Server in München zeigt die schlechten Upload-Werte. Typischerweise beginnt der Upload sehr schnell, bricht dann ein, erholt sich wieder, bricht nochmals ein und wird dann langsam etwas schneller. Das Verhalten ist gut reproduzierbar. Der Download beginnt langsam (150 MBit/s) und steigt ohen Zwischentief auf den Maximalwert von 500 MBit/s.

Dieser Anstieg ist mir bekannt, da wird die Größe des Übertragungsfensters optimiert, die wellenförmigen Bewegungen beim Upload sind merkwürdiger.

b) Ich habe einmal den Speedtest von chip probiert (https://speedtest.chip.de). Dort kann man eine Unmenge an Servern auswählen. Der nächstgelegene Server in München zeigt dabei das gleiche Verhalten wie beim o.e. Speedtest. Ich habs einmal spasseshalber mit Hamburg probiert. Up- und Download absolut perfekt! ping natürlich wegen der Strecke etwas größer. Ein paar weitere Server in Deutschland, alle prima. Spasseshalber Singapur. Etwas schlechter, Download 300 MBit/s, aber auch hier der Upload besser als nach München.

c) Ich habe einmal ein paar in der Nähe liegende mir bekannte IPs mit ping -f -s 1000 -c 1000 traktiert. Allesamt zeigen Paketverluste von ca. 1%. Die IP des Vodafon-Servers in München konnte ich leider nicht ermitteln, das wäre natürlich aussagekräftiger gewesen, als irgendwelche von mir selbst ausgewählten Ziele.

Ich kann mir aus den Beobachtungen kein wirkliches Bild machen. Es sieht ein wenig so aus, als ob eine ausgewählte Route (eben die zum Testserver in München und leider auch zu meinem Backupserver ebenfalls in der Nähe Münchens) über eine Hardware führt, die leichte Paketverluste verursacht.

Als Anhang habe ich einmal so ein typisches Upload-Muster ausgewählt. Stammt von https://www.speedtest.net, bei dem ich per Chrome-Entwicklertools die Download-Kurve ausgeblendet habe (das File heisst dennoch Download.png zeigt aber den Upload)

[rhaessner]

Noch ein Versuch mit einer Grafik. Vielleicht bekomme ich das ja hin.

Diesmal der Chip-Speedtest, ausgehend von ismaning zum nächstgelegenen Punkt in München (am langsamsten) und nach Frankfurt sowie Hamburg.

Sehr schön zu sehen ist das Wellenmuster bei der Uploadgeschwindigkeit.

Hamburg war schon einmal besser, dennoch sind sowohl Hamburg als auch Frankfurt besser als München.

[AndreasLevers]

Ich habe im Grunde das gleiche Problem mit meiner 500/50-Verbindung. Der Download steigt schnell an und bleibt dann bei den gebuchten 500MBit/s, während er Upload stark schwankt und fast nie die gebuchte Geschwindigkeit erreicht. Die Wellenform kann man im angehängten Screenshot des FritzBox-Onine-Monitors ganz gut erkennen.

Bei Tests mit verschiedenen Root-Servern fiel mir auf, dass die Geschwindigkeit vom Rechenzentrum abhing. Wenn ich die gleichen Server von einem T-Online Glasfaser-Anschluss aus teste, ist der Upload linear und lastet meine Leitung komplett aus.

Ein telefonisches Störungsticket wurde leider ohne weitere Angaben oder Lösung geschlossen.

Gibt es vielleicht in der Vodafone-Infrastruktur ein Problem beim Routing oder der Lastverteilung?

[rhaessner]

Ich habe noch einmal ein wenig gespielt. Es scheint wirklich an Paketverlusten zu liegen, an welcher Stelle auch immer.

Und zwar habe ich mein geliebtes Fire-ping auf www.bild.de losgelassen. Jetzt nicht, weil ich die Zeitung so mag, sondern weil die das Akamai-Netzwerk nutzen. 

1 <1 ms <1 ms <1 ms FRITZ-NAS [192.168.178.1]
2 13 ms 10 ms 9 ms ip53a9b757.static.kabel-deutschland.de [83.169.183.87]
3 9 ms 14 ms 12 ms ip5886cb91.static.kabel-deutschland.de [88.134.203.145]
4 16 ms 17 ms 11 ms ip5886c912.static.kabel-deutschland.de [88.134.201.18]
5 22 ms 24 ms 28 ms ip5886ca41.static.kabel-deutschland.de [88.134.202.65]
6 1449 ms 126 ms 212 ms ip5886ed93.static.kabel-deutschland.de [88.134.237.147]
7 25 ms 26 ms 35 ms akamai.bcix.de [193.178.185.22]
8 23 ms 23 ms 31 ms a88-221-214-171.deploy.static.akamaitechnologies.com [88.221.214.171]

Ablaufverfolgung beendet.

tracert www.bild.de

Routenverfolgung zu e24152.g.akamaiedge.net [88.221.214.171]
über maximal 30 Hops:

1 <1 ms <1 ms <1 ms FRITZ-NAS [192.168.178.1]
2 13 ms 12 ms 16 ms ip53a9b757.static.kabel-deutschland.de [83.169.183.87]
3 10 ms 10 ms 13 ms ip5886cb91.static.kabel-deutschland.de [88.134.203.145]
4 10 ms 10 ms 18 ms ip5886c912.static.kabel-deutschland.de [88.134.201.18]
5 21 ms 24 ms 22 ms ip5886ca41.static.kabel-deutschland.de [88.134.202.65]
6 167 ms 188 ms 247 ms ip5886ed93.static.kabel-deutschland.de [88.134.237.147]
7 23 ms 25 ms 26 ms akamai.bcix.de [193.178.185.22]
8 24 ms 22 ms 23 ms a88-221-214-171.deploy.static.akamaitechnologies.com [88.221.214.171]

Ablaufverfolgung beendet.

tracert www.bild.de

Routenverfolgung zu e24152.g.akamaiedge.net [88.221.214.171]
über maximal 30 Hops:

1 <1 ms <1 ms <1 ms FRITZ-NAS [192.168.178.1]
2 11 ms 12 ms 13 ms ip53a9b757.static.kabel-deutschland.de [83.169.183.87]
3 10 ms 9 ms 11 ms ip5886cb91.static.kabel-deutschland.de [88.134.203.145]
4 10 ms 14 ms 10 ms ip5886c912.static.kabel-deutschland.de [88.134.201.18]
5 21 ms 23 ms 21 ms ip5886ca41.static.kabel-deutschland.de [88.134.202.65]
6 1082 ms 775 ms 1268 ms ip5886ed93.static.kabel-deutschland.de [88.134.237.147]
7 819 ms 1353 ms * akamai.bcix.de [193.178.185.22]
8 * * * Zeitüberschreitung der Anforderung.
9 * 24 ms 22 ms a88-221-214-171.deploy.static.akamaitechnologies.com [88.221.214.171]

Ablaufverfolgung beendet.

tracert www.bild.de

Routenverfolgung zu e24152.g.akamaiedge.net [88.221.214.171]
über maximal 30 Hops:

1 <1 ms <1 ms <1 ms FRITZ-NAS [192.168.178.1]
2 12 ms 12 ms 11 ms ip53a9b757.static.kabel-deutschland.de [83.169.183.87]
3 10 ms 13 ms 11 ms ip5886cb91.static.kabel-deutschland.de [88.134.203.145]
4 11 ms 11 ms 9 ms ip5886c912.static.kabel-deutschland.de [88.134.201.18]
5 24 ms 23 ms 21 ms ip5886ca41.static.kabel-deutschland.de [88.134.202.65]
6 218 ms 1143 ms 372 ms ip5886ed93.static.kabel-deutschland.de [88.134.237.147]
7 762 ms 440 ms 222 ms akamai.bcix.de [193.178.185.22]
8 23 ms 22 ms 24 ms a88-221-214-171.deploy.static.akamaitechnologies.com [88.221.214.171]

Ohne Angabe der Länge (56 Byte) gibt es bei 10 000 ping keinerlei Paketverluste. Bei 1000 byte sind es etwa 0,3%, bei 1400 Byte

Der eine Router bummelt ziemlich.

Habe dann mal Paketverluste mit fire-Ping gemessen

56 Byte - 0% (ping -f -s 56 -c 100000)

1000 Byte - 0,3% verlust

1400 Byte - 1,2% Verlust

Kurze Pakete (also beispielsweise die Antwortpakete beim Download) gehen nicht verloren. Damit funktioniert der bekannte slow start wunderbar und läuft bis zur Begrenzung auf.

Große Pakete, wie man sie beim Upload erzeugt, verschwinden gelegentlich. Damit fängt auch erst einmal der slow start an, läuft hoch bis zum ersten Paketverlust hoch und wird dann wieder auf ein kleineres Fenster gedrosselt. Jetzt ist es nur eine Frage, über welchen Router welche Paketverluste auftreten.

Soll heißen, das Backbone weist irgendwo einen empfindlichen Engpass auf. Irgendwo läuft ein Puffer über. Das darf er zwar, hat dann aber die beobachteten Nebenwirkungen.

Die sündteure Fehlersuche in meiner Wohnung (2 Stunden ... + die Ersatzgeräte) war dann für die Katz.

Schaun wir mal.

Anmerkung: Wir nicht jeder wissen, was "slow start" ist:

https://www.teialehrbuch.de/Kostenlose-Kurse/Internet-Technik/16220-TCP-Slow-Start-und-Congestion-Av...

[Wallace]

Hey rhaessner,

da gibt´s vermutlich einen Überlastung in unserem Netz. Sende mir Deine Kundendaten (Name, Geburtstag, Anschrift, Kundennummer) in einer privaten Nachricht, dann schaue ich mal nach.

Melde dich hier kurz, wenn Du die Daten gesendet hast.

VG Wallace

[rhaessner]

PM ist abgeschickt.

[Moni_GK]

Hallo rhaessner,

an Deinem Anschluss treffen 2 Dinge aufeinander. Zum einen gibt es eine Segmentauslastung zur Primetime. Diese wird durch meine Kollegen aber schon bearbeitet.

Allerdings sind auch die Upstreamkanäle eher grenzwertig. Dies ist aber unabhängig von der Störung. Dazu möchte ich Dir gerne einen Techniker schicken, damit er das mal entstört. Schickst Du mir dazu bitte eine PN mit einer Rufnummer, damit der Kollege einen Termin vereinbaren kann.

Liebe Grüße

Moni

[rhaessner]

Ich habe nach einer Woche Urlaub noch einmal ein wenig gespielt und glaube eine Korrelation gefunden zu haben.

Habe einmal einen sehr großen Upload zu einem zuverlässigen Endpunkt geschickt (das ist ein Backup-Server mit 40 GBit/s Bandbreite). Gleichzeitig läuft im Sekundentakt mtr über die gleiche Strecke.

In der Textausgabe sieht das so aus:

My traceroute [v0.87]
nmr-host (0.0.0.0) Sun Mar 24 15:25:58 2019
Resolver error: Received reply from unknown source: fd00:: fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. fritz.box 99.9% 3187 0.5 0.5 0.5 0.6 0.0
2. ip53a9b757.static.kabel-deutschland.de 0.8% 3187 10.5 47.2 5.8 2738. 208.1
3. ip5886cb91.static.kabel-deutschland.de 0.4% 3187 13.0 44.2 4.6 2650. 201.9
4. ip5886c912.static.kabel-deutschland.de 0.5% 3187 10.4 44.4 5.7 3017. 203.4
5. ip5886cbe5.static.kabel-deutschland.de 0.4% 3187 17.7 51.9 11.6 3079. 206.6
6. ip5886eda3.static.kabel-deutschland.de 0.6% 3187 573.5 796.6 16.2 5979. 757.1
7. cr-fra2-be1.x-win.dfn.de 0.6% 3187 21.4 54.9 12.1 3179. 212.9
8. cr-gar1-be6.x-win.dfn.de 0.6% 3187 107.6 61.6 20.7 3125. 210.6
9. kr-gar188-0.x-win.dfn.de 0.5% 3187 27.4 61.9 20.8 3033. 212.5
10. vl-3001.cvr2-2wr.lrz.de 0.7% 3186 31.8 74.5 20.9 2941. 212.4
11. asa-cluster.lrz.de 0.6% 3186 27.0 61.6 20.5 2939. 212.1

Das ist jetzt leider nicht sehr gut formatiert. Bereits der erste Router weist ein durchschnittliches ping von 50 Millisekunden auf, kann aber durchaus auch in 5.8 Millisekunden antworten. Die Uploadgeschwindigkeit korreliert direkt invers mit dem ping. Ich kann jetzt keine Grafik anbieten. Bei den 6 ms ping ging der Upload auf etwa 35 MBit/s hoch. Es gibt auch Zeiten mit 1 Sekunden (angehängte Grafik), dann fällt der Upload auf 1 MBit/s.

Ich weiß schon, dass die Router einem ping eine geringe Priorität einräumen. Macht aber nix, eine lange Antwortzeit heißt dennoch nichts Anderes, als dass der Router gerade derart stark beschäftigt ist, dass er sich mit der Antwort auf ping nicht auseinandersetzen kann.

Interessant vielleicht auch noch die Paketverluste von etwa 0,5%, die sich ab dem ersten Router durchziehen.

Meine unmassgebliche Meinung: tatsächlich Überbuchung, aber nicht des Segmentes, sondern des nächsten Routers.

[Jens · Accepted solution]

Hallo rhaessner,

der Auftrag zum Ausbau ist ja weiterhin offen. Da wird sich also noch etwas Bewegen, sobald der abgeschlossen ist.

Gruß

Jens

[rhaessner]

Seit dem 30. 3. ist alles in Ordnung. Abends 40 statt 50 MBit/s, ist o.K.

Ich wollte nicht eher schreiben, um Murphy nicht herauszufordern.

Heute hat sich übrigens ein Techniker im Auftrag eines anderen Hausbewohners den Hausverteiler angesehen, aber ich denke, das war nicht des Pudels Kern, es funktionierte schon zwei Tage früher.

Ich bin glücklich; möge es so bleiben.