Amazon AWS S3 / Github downloads sehr langsam, nicht nutzbar

lsup · ‎16.12.2020

Hallo,

seit ca. einer Woche habe ich starke Probleme beim Zugriff auf Inhalte von Github / Amazon AWS S3. Es ist nahezu unmöglich größere Dateien herunterzuladen. Ich erreiche lediglich Geschwindigkeiten im einstelligen kb/s Bereich. Aufgefallen ist es mir nach der Neu-Installation meines Desktop Rechners und ich hatte erst vermutet es sei ein lokales Problem mit dem Rechner. Ich habe jedoch heute auch mit 3 weiteren Geräten im lokalen Netz das gleich Problem gehabt. Da das Problem nun an min 3 Tagen in der letzten Woche aufgetreten ist, und ich über z.B. LTE ordentliche Bandbreiten erreiche habe ich nun ein Problem mit dem Anschluss in Verdacht.

Die Generelle Bandbreite des Anschlusses ist i.O., lediglich mit S3 habe ich Probleme. Ich habe in älteren Posts von Problemen mit dem Peering gelesen, konnte dazu allerdings nichts aktuelles finden. Wie kann ich mein Problem lösen?

Waldemar H. · ‎29.01.2021

@Thomas_Herrmann schrieb:

Bei mir auch Wirespeed, 11MB/s.

Danke Telekom/AWS/wer auch immer - auch wenn's lange gedauert hat.

@viper.de schrieb:

Bei mir ca. 9 MB/s an einem VDSL100, IP Adresse 91.23.xxx.yyy

@rtel schrieb:

Auf einmal 12.1Mb/sec anstatt zuvor 1-2 Kb. Kann bestätigen, dass es wieder schnell ist. Keine Ahnung, wer was genau gemacht hat, aber auf jeden Fall vielen Dank!

@soupdiver schrieb:

Ich kann von 84.161.x.x auch bestätigen, dass wieder >10MB/s durch die Leitung gehen.

Top!!... danke an die vielen sinnvollen Beiträge hier... und das ganze Gemecker vergessen wir mal

@tm_107 schrieb:

Hier auch wieder ordentliche Downloadgeschwindigkeiten ...

@Jaffi schrieb:

ES FUNZT WIEDER!!! FULLSPEED, DANKE!!! 🚀

@luddinho schrieb:

Auch ich kann von meiner Seite berichten, dass seit heute Nachmittag ca. 16:45 Uhr die Downloadgeschwindigkeit enorm zugenommen hat.

@Thomas_Herrmann @viper.de @rtel @soupdiver @tm_107 @Jaffi @luddinho Danke für die positiven Rückmeldungen und es freut uns, dass die von euch genutzten Dienste, die von Amazon gehostet werden, nun wieder in der gewünschten Geschwindigkeit zur Verfügung stehen. 👍 😊

@luddinho schrieb:
Interessieren würde mich dennoch was im Hintergrund geschehen ist was zur Besserung beigetragen hat.

Wie zuvor erwähnt: Von unserer Seite gibt es keine Engpässe bezüglich der Verkehre mit Amazon. Unsere mit Amazon vereinbarten Schnittstellen sind für den Datenverkehr ausreichend ausgestattet. Die Verkehrssteuerung obliegt am Ende aber Amazon selbst. Seit Anfang der Woche sehen wir wieder eine optimalere Verkehrsverteilung und sind guter Dinge, das damit die Probleme für unsere Kunden gelöst sind. Auch stehen wir mit Amazon in direktem Kontakt, um solche Vorfälle in Zukunft hoffentlich vermeiden zu können.

Liebe Grüße

Waldemar H.

Lösung in ursprünglichem Beitrag anzeigen

hg42 · ‎19.01.2021

eine kleine Zusammenfassung für Neuankömmlinge als Living-Post (ich bin kein Experte nur Zusammenfassender):

Das Problem ist noch nicht gelöst!
Der Thread ist nur als "Gelöst" markiert, weil das die einzige Möglichkeit ist, Beiträge anzupinnen.

Es betrifft offenbar AWS-Server an der Ostküste der USA und Dienste wie github die dort gehostet werden.
Das aber nur bei Kunden der Telekom und bei Wiederverkäufern, wahrscheinlich auch bei Providern die Infrastruktur der Telekom nutzen.

Die grundsätzliche Ursache liegt wohl in der Route auf dem Rückweg.
(Posts mit Traceroutes in Hinrichtung nützen deswegen übrigens nichts)

Zur Stellungnahme des Telekom-Teams siehe anderer angepinnter Beitrag.
Außerdem fand ich diesen Beitrag in einem anderen Thread recht klar:
"von unserer Seite gibt es keine Engpässe in Richtung Amazon. Unsere mit Amazon vereinbarten Schnittstellen sind für den Datenverkehr ausreichend ausgestattet. Warum Amazon seinen Datenverkehr von der Ostküste darüber hinaus auch über andere Verkehrswege verschickt, können wir nicht sagen und ist die Entscheidung von Amazon.
Selbstverständlich befinden wir uns mit dem Anbieter in Gesprächen, um eine bessere Lösung für unsere Kunden zu schaffen."

Die Rückroute geht im langsamen Fall z.B. über Cogent an die Telekom.
Die Anbindung ist wohl suboptimal um es nett zu sagen.
Warum dabei die Geschwindigkeit auf 1/100 bis 1/1000 sinkt ist [für mich] rätselhaft.

Eine Frage ist, ob die Ursachen in firmenpolitischen Zusammenhängen liegen, siehe interessante Links ganz unten.

Workarounds:

Von der IP die man zugewiesen bekommt, hängt offenbar das Routing ab.
Man kann versuchen, durch z.B. "Neu Verbinden" in der Fritzbox oder entsprechendes bei anderen Routern (ohne Trennen des DSL) einen anderen IP-Bereich zu bekommen.
Aber nicht jeder bekommt IPs aus mehreren Bereichen.

Bekannte kritische Bereiche:
79.192.0.0/10 (79.192.0.1 - 79.255.255.254)

80.128.0.0/11 (80.128.0.1 - 80.159.255.254)

84.128.0.0/10 (84.128.0.1 - 84.191.255.254)

87.128.0.0/10 (87.128.0.1 - 87.191.255.254)

91.0.0.0/10 (91.0.0.1 - 91.63.255.254)

93.192.0.0/10 (93.192.0.1 - 93.255.255.254)

...

scheint wieder zu funktionieren:
84.136.0.0 bis 84.191.255.255 (siehe Link unter Entwicklungen)
darunter 84.166.*.* aus eigener Erfahrung

anscheinend unkritisch:
93.* (ausgenommen obiger Teilbereiche)
217.*
...

(weitere bitte posten...wird ergänzt, wenn Zeit ist)

Durch einen Proxy oder ein VPN kann man ebenfalls einen anderen IP-Bereich bekommen und damit auch ein anderes Routing.
(ich denke, der Proxy/VPN darf dann selbst nicht bei der Telekom und in einem schlechten Bereich liegen, z.B. bei einem eigenen VPN-Server und auch nicht auf AWS us-east für die Verbindung zu Dir)

Kleine Zusammenfassung der "Lösungen" in einem älteren Post:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...

zusätzlich für einzelne Dateien auch:
"der einfachste Workaround ist
diese URL aufrufen
https://hide.me/en/proxy
und da die eigentliche URL zu github einfügen.
Braucht kein VPN und kostet nichts -
für einzelne Dateien ist das nicht mal ein nennenswerter Mehraufwand - was an dem Problem nichts ändert"
(von Stefan)

Der obige Proxy scheint auch nicht immer zu funktionieren, stattdessen aber dieser:
https://www.hidemyass.com/de-de/proxy

Test der Rückroute:
https://mtr.sh
AWS US-OH Ohio für us-east
AWS US-OR Oregon für us-west zum Vergleich
oben eigene externe IP eintragen und "mtr" wählen
(interessanterweise ist US-VA, das ja auch an der Ostküste liegt mit kurzer Route)

weitere interessante Links/Posts:

Entwicklungen:
84.136.0.0 bis 84.191.255.255
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...

Messung:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...
(sehr interessant, mag etwas über die Ursachen aussagen)

bzgl. Route:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...

bzgl. älterer Peering-Verwicklungen der Telekom:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...

eventuelle Gegenargumente:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...

zu Rückmeldungen von Amazon:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...

Abhandlung der Telekom über Peering-Probleme:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Peeringprobleme-Probleme-bei-Datenuebertragung...

Lösung in ursprünglichem Beitrag anzeigen

Stefan · ‎13.01.2021

der einfachste Workarround für das herunterladen einzelner Dateien ist diese URL aufrufen

https://hide.me/en/proxy

oder falls es da Probleme gibt:

https://www.hidemyass.com/de-de/proxy

und da die eigentliche URL zu github einfügen.

Braucht kein VPN und kostet nichts -

Für einzelne Dateien ist das nicht mal ein nennenswerter Mehraufwand - was an dem Problem nichts ändert

Lösung in ursprünglichem Beitrag anzeigen

viceice · ‎21.01.2021

Kurze Info: Bei mir geht's seid zwei / drei Tagen wieder ganz gut.

Die IP's der letzen zwei Tage sind im Bereich: 84.176

Habe bei mir nun auch die Zwangstrennung in der Box deaktiviert, hatte jedoch heute Nacht trotzdem ein Reconnect (liegt vermutlich an meinem Anbieter 😇).

rtel · ‎21.01.2021

Von Github gibt es mittlerweile auch ein Statement:
https://github.community/t/slow-downloads-telekom-germany/154790/17

marc.sowen · ‎21.01.2021

@rtel schrieb:
Von Github gibt es mittlerweile auch ein Statement:
https://github.community/t/slow-downloads-telekom-germany/154790/17

Dort steht ja ziemlich eindeutig, dass das Netz der Telekom am Limit ist. Die Telekom ist wohl dem Ansturm von Homeoffice nicht gewachsen und ist damit wohl doch kein Premium-Anbieter. Vielleicht interessiert sich die Presse ja dafür?

der_Lutz · ‎21.01.2021

@marc.sowen schrieb:
Dort steht ja ziemlich eindeutig, dass das Netz der Telekom am Limit ist. Die Telekom ist wohl dem Ansturm von Homeoffice nicht gewachsen und ist damit wohl doch kein Premium-Anbieter.

Und du bist dir sicher dass genau dieser Beitrag der einzig korrekte ist?

@marc.sowen schrieb:
Vielleicht interessiert sich die Presse ja dafür?

Frag sie doch

mbsl · ‎21.01.2021

Für mich sieht das eher so aus als ob die Telekom bewusst die Leitung zu macht um die verärgerten Nutzer als Hebel zu benutzen um die Anbieter zur Kasse zu bitten und sich den Traffic doppelt bezahlen lassen. Einmal von den Anbietern und einmal von den Nutzern.

Die Messung von @luddinho hat ja gezeigt dass hier absichtlich eingegriffen wird.

sral96 · ‎21.01.2021

@der_Lutz schrieb:
@marc.sowen schrieb:
Dort steht ja ziemlich eindeutig, dass das Netz der Telekom am Limit ist. Die Telekom ist wohl dem Ansturm von Homeoffice nicht gewachsen und ist damit wohl doch kein Premium-Anbieter.
Und du bist dir sicher dass genau dieser Beitrag der einzig korrekte ist?

Das hat ja keiner gesagt. Jeder sagt ja offenbar was anderes, das Problem will keiner lösen. Unabhängig von Services der AWS sind ja auch andere Cloud-Anbieter( BSP. Alibaba) betroffen. Dort habe ich heute morgen mal einen Trace gemacht, der ebenfalls über die offenbar aus allen Nähten platzende Cogent-Route geht. Genau diese will die Telekom ja scheinbar nicht ausbauen

marc.sowen · ‎21.01.2021

@der_Lutz schrieb:
Und du bist dir sicher dass genau dieser Beitrag der einzig korrekte ist?

Zumindest ist das mal eine relativ offizielle Stellungnahme von einem Mitarbeiter und nicht "nur" Community Mitgliedern.

Frag sie doch

Schon passiert.

Sascha33 · ‎21.01.2021

Github sagt Telekom ist schuld
Telekom sagt Github ist schuld

Und wir mitten drin. Na super. Hauptmann von Köpenick lässt grüßen.

sral96 · ‎21.01.2021

@mbsl schrieb:
Für mich sieht das eher so aus als ob die Telekom bewusst die Leitung zu macht um die verärgerten Nutzer als Hebel zu benutzen um die Anbieter zur Kasse zu bitten und sich den Traffic doppelt bezahlen lassen. Einmal von den Anbietern und einmal von den Nutzern.

Die Messung von @luddinho hat ja gezeigt dass hier absichtlich eingegriffen wird.

Ob die Telekom nun bewusst die Leitung zu macht sei mal dahin gestellt, über deren direkte Route sieht ja erstmal alles gut aus. Fakt ist nur, dass für bestimmte Subnets eben eine falsche Route genommen wird, die eben total überlastet ist. Genau hier reagiert die Telekom aber seit Jahren nicht, worüber sich u.a. Cogent ja auch schon beschwert hat.

Stefan · ‎21.01.2021

@mbsl schrieb:

Für mich sieht das eher so aus als ob die Telekom bewusst die Leitung zu macht um die verärgerten Nutzer als Hebel zu benutzen um die Anbieter zur Kasse zu bitten und sich den Traffic doppelt bezahlen lassen. Einmal von den Anbietern und einmal von den Nutzern.

Die Messung von @luddinho hat ja gezeigt dass hier absichtlich eingegriffen wird.

Die Messung war super hat aber für die Analyse wo das Problem liegt gar nichts gezeigt. Wie er im übrigen auch selbst geschrieben hat.

Du konstruierst nun aus dem nichts dies als "Beweis"

Und wie es für dich aussieht ist doch völlig unerheblich, wenn für dich eine Katze wie ein Löwe aus sieht bleibt es ja trotzdem eine Katze.

Stefan · ‎21.01.2021

@sral96 schrieb:

@der_Lutz schrieb:

@marc.sowen schrieb:
Dort steht ja ziemlich eindeutig, dass das Netz der Telekom am Limit ist. Die Telekom ist wohl dem Ansturm von Homeoffice nicht gewachsen und ist damit wohl doch kein Premium-Anbieter.

Da steht:

My hunch is that with the increase in remote work and the ever increasing amount of services being hosted on AWS, their infrastructure may be reaching its limits.

Meine Vermutung ist, dass mit der Zunahme der Remote-Arbeit und der 
ständig wachsenden Anzahl von Diensten, die auf AWS gehostet werden, 
ihre Infrastruktur möglicherweise an ihre Grenzen stößt.

Was ist an einer Vermutung eines 1. Levelsupports den ziemlich deutlich.

mbsl · ‎21.01.2021

Eine Katze ist ein kleiner Löwe und ein Löwe ist nur eine große Katze. Kommt drauf an auf welcher Seite man ist.

Mich stört dass du hier versucht die Telekom zu "white-knighten". Es gibt zahlreiche Berichte aus der Vergangenheit dass die Telekom sich nicht fair gegenüber CDNs verhält.

Solange die Telekom nicht glaubwürdig dar legt dass die Kapazitäten ausreichend dimensioniert sind traue ihnen nicht.

Von seiten Telekom gibts ja auch nur Aussagen vom 1st Level Support dass die Kapazitäten reichen.

hg42 · ‎21.01.2021

Auch mir passieren Fehler

klar, war auch nicht bös gemeint (sowieso nie bei mir), ich wollte nur die Fakt nochmal klar machen

> Hatte ich us-east-2 ins Spiel gebracht?

nee, aber ich in der Vergangenheit war es halt auch mal us-east-2 und aktuell ist es us-east-1 und zumindest bei mir ist us-east-2 in Ordnung, auch wenn ich eine falsche IP habe (aktuell eigentlich nur noch 84.166.166.* die ich aber nicht mehr bekomme).
Es scheint also auch zu wechseln. Vielleicht wird ständig öfter umkonfiguriert, oder man gibt tagsüber den Unternehmen die guten Routen und nachts den Privatleuten. Aber alles Spekulation, ich weiß nur, dass man Pakete markieren kann und das beim Routen berücksichtigt werden kann(!). Technisch könnte es also möglich sein.

marc.sowen · ‎21.01.2021

@Stefan schrieb:
Was ist an einer Vermutung eines 1. Levelsupports den ziemlich deutlich.

"Senior Enterprise Support Engineering Manager" klingt jetzt nicht nach einem einfachen Hotline-Mitarbeiter. (https://de.linkedin.com/in/mikeadolphs)

Ansonsten ist es einfach Fakt, dass andere Provider keine Probleme haben die Daten von Github zu liefern. Das Problem gibt es wohl nur bei der Telekom und somit die das Problem auch bei der Telekom zu suchen.

Stefan · ‎21.01.2021

@mbsl schrieb:

Mich stört dass du hier versucht die Telekom zu "white-knighten".

Was dich an mir stört, ist mir eigentlich völlig egal.

Du meinst aber im Gegensatz zu dir der die Telekom hier "black-knighten" will - ist sowas überhaupt ein Wort

Ganz ehrlich, du hast eine Beiträge nicht gelesen oder verstanden, ich habe nämlich keine Partei ergriffen sondern stehts gesagt, dass wir es nicht wissen.

Wem du traust oder nicht ist deine Sache, aber irgendwelches Stammtischgelabber von dir bringt uns ja auch nicht wirklich weiter.

Jeder Löwe ist eine Katze, aber nicht jede Katze ist ein Löwe.

jkammann · ‎21.01.2021

@hg42 schrieb:
nee, aber ich in der Vergangenheit war es halt auch mal us-east-2 und aktuell ist es us-east-1 und zumindest bei mir ist us-east-2 in Ordnung, auch wenn ich eine falsche IP habe (aktuell eigentlich nur noch 84.166.166.* die ich aber nicht mehr bekomme).
Es scheint also auch zu wechseln. Vielleicht wird ständig öfter umkonfiguriert, oder man gibt tagsüber den Unternehmen die guten Routen und nachts den Privatleuten. Aber alles Spekulation, ich weiß nur, dass man Pakete markieren kann und das beim Routen berücksichtigt werden kann(!). Technisch könnte es also möglich sein.

Es scheint sich tatsächlich etwas zu rühren: Aktuell wird der größte zusammenhängene IP-Pool von 84.136.0.0 bis 84.191.255.255 direkt von AWS zur Telekom geroutet - das wären immerhin potentiell über 4 Mio Anschlüsse, die davon profitieren.

Andere Bereiche (ich habe gerade eine IP aus dem Bereich 91.0.0.0/10) laufen weiterhin über Cogent.

Verschiedene Verfügbarkeitszonen bei AWS (also us-east-2 statt ua-east-1) haben definitiv nichts mit dem Problem zu tun, da AWS Kunden die IP-Adressen zonen-übergreifend verwalten. Unterschiedliche Zonen haben nur AWS-intern ein unterschiedliches Routing über private IP-Adressen. Nach außen hin ist den IP-Adressen nicht "anzusehen", welcher Zone sie aktuell zugeordnet sind. Sollten sich doch unterschiedliche Downloadraten aus den unterschiedlichen Zonen zeigen, dann würde das Problem alle Endkunden betreffen, nicht nur die der Telekom und deren Reseller.

Wer also gerade eine Adresse aus dem Bereich 84.136.x.x.-84.191.255.255 hat, bitte wieder den Datendurchsatz messen - Falls dieser in Ordnung ist, dann wüssten wir zumindest, dass das direkte Peering der Telekom mit AWS funktioniert und nicht überlastet ist.

Zur Erinnerung: Das aktuelle Routing kann über die Webseite mtr.sh abgerufen werden. Dazu auf der Webseite oben die eigene IPv4-Adresse eingeben (vorausgefüllt ist die eigne IPv6-Adresse), dann "trace" anklicken und unter "North America" "US-VA / AWS", dann wieder oben "Run test". Eine direkte Route erkennt man am direkten Übergang von AS16509 (AWS) zu AS3320 (Telekom). Ein Umweg über Cogent erkennt man am AS174 auf dem Weg, bei den Hostnamen werden seitens Cogent Flughafen-Codes verwendet: IAD=Washington, JFK=New York und ORD=Chicago. Cogent routet zeit- und IP-abhängig, Routen über "JFK" und "ORD" liefern ordentliche Datenraten, nur IAD scheint überlastet zu sein (und zwar nicht in Washington, sondern am anderen Ende, vermutlich Frankfurt - das lässt sich aber wesentlich schlechter debuggen, weil die Telekom wohl MPLS-Routing macht, bei dem die einzelnen Hops auf IP-Ebene nicht sichtbar sind, d.h. man sieht nicht wo sich die Übergänge zwischen Cogent und der Telekom befinden und welche davon für die Paketverluste verantwortlich sind.

hg42 · ‎21.01.2021

Die Messung von @luddinho hat ja gezeigt dass hier absichtlich eingegriffen wird.

gefühlsmäßig sehe ich zwar auch eher die Telekom in der Verantwortung, aber bewiesen ist das anhand der Messdaten wohl auch nicht.
Dafür ist das Problem wohl zu kompliziert.

Allerdings:

soweit ich das gelesen habe, sind Geschäftskundenanschlüsse nicht betroffen, das deutet für mich auf absichtliches Routen
außerdem ist das zeitabhängig, wobei der Beginn der schnellen Zeit nach 23 oder 24 Uhr mich da etwas nachdenklich macht, das entspräche ja nicht unbedingt Geschäftszeiten (bzw. dem Gegenteil)
wenn tatsächlich diese Alibaba und Heroku Server auch so langsam sind, spricht das für Netzüberlastung

Das führt für mich logisch zu dem Gedanken, dass das Netz eigentlich überlastet wäre, aber durch Kappen bestimmter Bereiche, die nicht von Geschäftskunden genutzt werden, die Überlastung für den Rest nicht mehr stattfindet.

MSL1 · ‎21.01.2021

Hallo zusammen,

Meldung von meiner Seite aus.

Hab eine Quell IP aus 84.128.0.0/10 und es kommt Full Speed bei einer 100MBit FTTH Magenta Zuhause Leitung bei mir an.

Getestet mit Sample Data von https://s3.amazonaws.com/ryft-public-sample-data/wikipedia-20150518.bin

Schaut also grad gut aus....zumindest in diesem Moment.

BG

MSL1

###EDIT: Hier noch der MTR

traceroute to 84.140.*.* (84.140.*.*), 50 hops max, 60 byte packets
1 216.182.231.215 (216.182.231.215) [AS14618] 2.131 ms 216.182.231.110 (216.182.231.110) [AS14618] 19.399 ms 216.182.231.201 (216.182.231.201) [AS14618] 2.350 ms 216.182.231.0 (216.182.231.0) [AS14618] 15.793 ms 216.182.229.66 (216.182.229.66) [AS14618] 2.222 ms
2 100.66.8.242 (100.66.8.242) [*] 3.028 ms 100.66.12.50 (100.66.12.50) [*] 18.892 ms 100.66.12.80 (100.66.12.80) [*] 20.490 ms 100.66.8.172 (100.66.8.172) [*] 668.741 ms 100.66.13.2 (100.66.13.2) [*] 18.843 ms
3 100.66.11.132 (100.66.11.132) [*] 20.752 ms 100.66.10.170 (100.66.10.170) [*] 13.731 ms 100.66.38.106 (100.66.38.106) [*] 19.980 ms 100.66.14.24 (100.66.14.24) [*] 12.800 ms 100.66.39.210 (100.66.39.210) [*] 18.434 ms
4 100.66.7.159 (100.66.7.159) [*] 12.386 ms 100.66.6.135 (100.66.6.135) [*] 233.911 ms 100.66.6.23 (100.66.6.23) [*] 219.671 ms 100.66.54.216 (100.66.54.216) [*] 20.358 ms 100.66.7.5 (100.66.7.5) [*] 16.727 ms
5 100.66.5.201 (100.66.5.201) [*] 18.105 ms 100.66.5.213 (100.66.5.213) [*] 17.133 ms 100.66.5.241 (100.66.5.241) [*] 15.619 ms 100.66.5.129 (100.66.5.129) [*] 22.294 ms 100.66.5.157 (100.66.5.157) [*] 22.276 ms
6 100.65.12.129 (100.65.12.129) [*] 1.221 ms 100.65.14.1 (100.65.14.1) [*] 2.209 ms 100.65.12.193 (100.65.12.193) [*] 0.324 ms 100.65.14.97 (100.65.14.97) [*] 0.362 ms 100.65.13.65 (100.65.13.65) [*] 0.294 ms
7 100.65.14.145 (100.65.14.145) [*] 0.466 ms 52.93.28.113 (52.93.28.113) [AS16509] 0.350 ms 52.93.28.79 (52.93.28.79) [AS16509] 0.511 ms 100.65.15.161 (100.65.15.161) [*] 0.494 ms 52.93.28.75 (52.93.28.75) [AS16509] 1.391 ms
8 52.93.28.89 (52.93.28.89) [AS16509] 0.499 ms 100.100.2.66 (100.100.2.66) [*] 1.010 ms 100.100.2.76 (100.100.2.76) [*] 0.637 ms 100.100.2.72 (100.100.2.72) [*] 0.626 ms 100.100.2.76 (100.100.2.76) [*] 0.544 ms
9 87.186.183.33 (87.186.183.33) [AS3320] 1.225 ms 87.186.183.37 (87.186.183.37) [AS3320] 1.167 ms 100.100.2.76 (100.100.2.76) [*] 2.385 ms 87.186.183.33 (87.186.183.33) [AS3320] 1.182 ms 87.186.183.37 (87.186.183.37) [AS3320] 1.036 ms
10 p5b17dc8d.dip0.t-ipconnect.de (91.23.220.141) [AS3320] 91.356 ms 91.345 ms 91.362 ms 87.186.183.33 (87.186.183.33) [AS3320] 1.145 ms 1.156 ms
<Home Sweet Home >

hg42 · ‎21.01.2021

Es scheint sich tatsächlich etwas zu rühren: Aktuell wird der größte zusammenhängene IP-Pool von 84.136.0.0 bis 84.191.255.255 direkt von AWS zur Telekom geroutet - das wären immerhin potentiell über 4 Mio Anschlüsse, die davon profitieren.

seit mindestens heute Nacht hat sich für mich auch was geändert. ich bekomme keine 84.166.166.* mehr, die vorher definitiv immer schlecht war.
Die anderen 84.166.*.*, die ich vorher nachts bekommen hatte, bekomme ich jetzt "immer", auch tagsüber (d.h. bei sporadischen Tests mit Reconnects). Vorher bekam ich tagsüber praktisch immer 93.* oder 217.*
Gestern hatte ich noch 93.* und habe dann nachts mal Reconnects versucht, seitdem bekomme ich immer die 84.166.*.* Bei den Messungen heute Nacht ist der Speed bei 93.* ziemlich genau ab 22:00 ungefähr halbiert worden und gleicht jetzt dem nun ordentlichen Speed bei den 84.166.*.*
Man könnte sagen, mein Problem gibt es nicht mehr (toll, die ganze Arbeit mit dem Reconnect und vernünftig Messen umsonst, Murphy lässt grüßen, aber ich will mich nicht beklagen...). Der Speed ist bei den Downloads allerdings noch etwas suboptimal, z.B. 3MB/s statt 5MB/s wie sonst. Das ist aber nur eine Momentaufnahme, sporadisch seit heute Nacht. Wenn es tatsächlich so wäre, ist ja vielleicht die vorhandene Bandbreite mehr verteilt worden oder so.
Bin gespannt ob sich wirklich was dauerhaft geändert hat...

Aber Dein 91.* tut's ja offenbar immer noch nicht?

Das mit dem us-east-2 und -1 entstammt meinen Messungen, einmal war US-VA, was Du als Messpunkt vorschlägst, bei mir bei vorhandenem Problem nur mit kurzer Route (reproduzierbar über mehrere Stunden), während gleichzeitig us-east-1 mit langer Route war.
Weil ich mit US-VA erstaunlicherweise keine lange Route hatte, hatte ich das in der Zusammenfassung auf US-OH Ohio geändert.
Irgendwie kommt es mir deswegen so vor, als wenn es sowohl von der US-Zone als auch von der Telekom-Kunden-IP abhängt.
Ich weiß natürlich nicht, welchen Weg meine Downloads genommen haben. Normales github...Privataccount.

hg42 · ‎21.01.2021

Hab eine Quell IP aus 84.128.0.0/10 und es kommt Full Speed bei einer 100MBit FTTH Magenta Zuhause Leitung bei mir an.
Getestet mit Sample Data von https://s3.amazonaws.com/ryft-public-sample-data/wikipedia-20150518.bin

das läuft bei mir mit ca. 6MB/s, also das schnellste von s2 seit vielen Tagen

meine aktuelle IP: 84.166.163.15

bzgl. der beiden Zonen, die sind auch schneller als sonst. Die Dateien mit test1mb sind übrigens viel langsamer (< 1.5MB/s) und bei der obigen URL ist auch auffällig, dass sich die Geschwindigkeit von 3 auf 6 hochhangelt.

% wget -O /dev/null https://ch-us-east-1.s3.amazonaws.com/probe/test10mb.jpg https://ch-us-east-2.s3.amazonaws.com/probe/test10mb.jpg

--2021-01-21 18:26:35-- https://ch-us-east-1.s3.amazonaws.com/probe/test10mb.jpg
Resolving ch-us-east-1.s3.amazonaws.com (ch-us-east-1.s3.amazonaws.com)... 52.217.75.4
Connecting to ch-us-east-1.s3.amazonaws.com (ch-us-east-1.s3.amazonaws.com)|52.217.75.4|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10486107 (10M) [image/jpeg]
Saving to: ‘/dev/null’

/dev/null 100%[===============================================================================>] 10.00M 4.77MB/s in 2.1s

2021-01-21 18:26:38 (4.77 MB/s) - ‘/dev/null’ saved [10486107/10486107]

--2021-01-21 18:26:38-- https://ch-us-east-2.s3.amazonaws.com/probe/test10mb.jpg
Resolving ch-us-east-2.s3.amazonaws.com (ch-us-east-2.s3.amazonaws.com)... 52.219.104.84
Connecting to ch-us-east-2.s3.amazonaws.com (ch-us-east-2.s3.amazonaws.com)|52.219.104.84|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10486107 (10M) [image/jpeg]
Saving to: ‘/dev/null’

/dev/null 100%[===============================================================================>] 10.00M 4.18MB/s in 2.4s

2021-01-21 18:26:41 (4.18 MB/s) - ‘/dev/null’ saved [10486107/10486107]

FINISHED --2021-01-21 18:26:41--
Total wall clock time: 5.5s
Downloaded: 2 files, 20M in 4.5s (4.46 MB/s)

hg42 · ‎21.01.2021

% wget -O /dev/null https://ch-us-east-1.s3.amazonaws.com/probe/test10mb.jpg https://ch-us-east-2.s3.amazonaws.com/probe/test10mb.jpg

ach ja, bei dem Test waren die beiden Zonen auch mal unterschiedlich, also 2-5MB/s und <50kB/s
jetzt ist anscheinend auch die 84.166.166.253, die ich mal hatte und danach immer als Test verwendet habe mit vergleichbaren Routen wie die anderen 84.166.*.* (also aus dem jetzt "guten" Segment).
ich hatte gesagt, die Länge der Route wäre bei schlechten Downloads groß (ca. 28 hops), das war bei mir immer so, alles gute lag unter 22 hops.
Nun habe ich aber auch bei guter Geschwindigkeit 29 hops und keinen spürbaren Unterschied zu ca. 10 oder 20 hops.
AS174 ist auch nicht mehr dabei.

hg42 · ‎21.01.2021

ich sagte ja ich bin verwirrt...
bei mtr.sh hatte ich aus so einem trace:

84.166.166.81 | Traceroute from AWS AS16509 in United States, Ohio 28 p54a6a651.dip0.t-ipconnect.de (84.166.166.81) [AS3320] 112.576 ms !X 112.552 ms !X 112.782 ms !X 112.334 ms !X 112.483 ms !X
---
traceroute to 84.166.166.81 (84.166.166.81), 50 hops max, 60 byte packets
1 ec2-52-15-0-169.us-east-2.compute.amazonaws.com (52.15.0.169) [AS16509] 1.188 ms 1.169 ms ...

geschlossen, dass es us-east-2 ist, aber das ist nur der erste hop.

Aktuell geht US-VA stattdessen so:
84.166.166.81 | Traceroute from AWS AS16509 in United States, North Virginia 11 p54a6a651.dip0.t-ipconnect.de (84.166.166.81) [AS3320] 95.183 ms !X * * 87.137.206.5 (87.137.206.5) [AS3320] 91.097 ms *
---
traceroute to 84.166.166.81 (84.166.166.81), 50 hops max, 60 byte packets
1 216.182.229.74 (216.182.229.74) [AS14618] 5.827 ms 216.182.231.207 (216.182.231.207) ...

sral96 · ‎22.01.2021

Ich habe gerade eine Antwort vom Github Support erhalten. Dort wurde sogar auf diesen Thread hier verwiesen 😀

Aussage war aber, dass sie dort eher weniger machen können, da es eine Sache zwischen AWS und Telekom sei.

Heute ist bei mir auch ein absoluter Tiefpunkt erreicht, mit 79.229.xxx.xx IP brauche ich 2 Tage für den Download von 200MB, der Download bricht ständig komplett ein auf 0 Byte/s, Spitzenwert waren 6kB/s.

Vielleicht lohnt sich der Wechsel auf IPoAC 🤔

https://de.wikipedia.org/wiki/Internet_Protocol_over_Avian_Carriers

Kugic · ‎22.01.2021

In meinen Augen könnte GitHub schon was machen.
Ihr Website auf andere AWS Server spiegeln, so dass es in der EU ebenfalls direkt auf kurzen Weg abrufbar ist.
Aber kost halt ordentlich Kohle und Github verdient ja kein Geld damit.

trilogo77 · ‎22.01.2021

Gerade nochmal getestet. Download bei Landr.com (liegt auf S3):

Normal: Download (70 MB) beginnt sehr langsam, eine Dauer von ca. 55 Minuten wird angezeigt, dann bricht er ab.
IP-Adresse aus Großbritannien über VPN: Download dauert 15-20 Minuten

IP-Adresse aus den USA über VPN: Downloadzeit 5 Sekunden (!)

Wohlgemerkt alles die selbe Datei, der selbe PC, der selbe Router, getestet direkt hintereinander.

Aber es kann nicht sein, dass man einen Bezahl-VPN (NordVPN in meinem Fall) vorschalten muss.

Amazon AWS S3 / Github downloads sehr langsam, nicht nutzbar

Social Media