crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
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?
Gelöst! Gehe zu Lösung.
29.01.2021 14:15
@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.
19.01.2021 20:39 Zuletzt bearbeitet: 24.01.2021 14:52 von Stefan
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...
13.01.2021 10:35 Zuletzt bearbeitet: 18.01.2021 11:37 durch den Autor
der einfachste Workarround für das herunterladen einzelner Dateien ist diese URL aufrufen
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
16.12.2020 21:10 Zuletzt bearbeitet: 16.12.2020 21:11 durch den Autor
Mach doch mal nen mtr zu S3.
sudo apt install mtr
mtr <URL>
Solltest du Windows nutzen geht das auch mit WinMTR:
https://github.com/White-Tiger/WinMTR
Das sollte zeigen ob du im Mobilfunk eine andere Route bekommst als im Festnetz und zudem ob du ein direktes Peering hast oder über Level3 gehst. Letzteres würde die Performance Probleme erklären. Zudem siehst du auch direkt wo Paketverlust auftritt und man kann damit beurteilen ob es im Telekomnetz ist oder außerhalb auf dem Weg zu AWS.
16.12.2020 21:12
bzw. poste mal den Link zu einem langsamen Download, bei mir sind div. Test schnell gewesen
16.12.2020 21:48
Hi,
danke für das schnelle feedback, ich habe zwei mal MTR (beides mal von meinem Telekom Anschluss) auf s3.amazonaws.com ausgeführt. Folgender output:
Die Messung über Mobilfunk muss ich wann anders machen, das war jetzt auf die schnelle nicht möglich.
Beispiel für einen Download der bei mir extrem langsam ist:
Kann man über die Messungen schon etwas sagen?
16.12.2020 21:52 Zuletzt bearbeitet: 16.12.2020 21:57 durch den Autor
die 90MB wurden in 4 Sekunden heruntergeladen.
Dein erster Traceroute hat schon Probleme in deinem LAN
Auch der Zweite ist auffällig, wenn gleich außerhalb des Hauses, werde mal einen hier machen
Auffälligkeiten im Routing bei TATA gab es hier die letzten Tage schon, nur hat die Telekom da keinen Einfluss
16.12.2020 21:52
De 10.1.0.2 in deinem Netz verwirft Ping Pakete.
Bei beiden MTRs tritt der größte Paketverlust bei as643.net auf, wobei du beim ersten MTR rein theoretisch gute Geschwindigkeiten haben solltest, da bis auf 10.1.0.2 eigentlich am Ende alle Pakete ankommen sollten.
16.12.2020 22:01
Der erste Schrieb hatte mich auch verwundert. Zunächst sah alles aus wie im zweiten. Dann ließ ich es jedoch im Hintergeund etwas laufen und dann bot sich das Bild wie im Screenshot. 10.1.0.2 wäre meine Fritzbox. Die könnte ich morgen testweise mal neu starten. Gibt es sonst noch mögliche Ursachen? Kann ich noch etwas tun?
16.12.2020 22:20
Warum hast du eine FritzBox und eine pfsense im Einsatz? Ergibt kein Sinn, es sei denn die FritzBox steht rein auf Modem Betrieb mit deaktivierter Firewall. Nicht das sich da was doppelt moppelt.
16.12.2020 22:26
Die FB nutze ich quasi nur als Modem. Die pfsense hängt als eyposed host direkt dahinter. Ich habe bisher auch nur Probleme beim Zugiff auf S3. Sonstige speedtests, oder Downloads sind in der Regel Problemlos.
17.12.2020 11:24
Möchte mich hier nur einklinken, um mehr Aufmerksamkeit auf das Thema zu lenken.
S3 basierte Anwendungen sind aktuell quasi unbrauchbar. 3,58kb/s vor 2-3 Minuten getestet. Das ist einfach super Panne.
Freunde mit denen ich die gleiche Anwendung nutze (roll20.net) haben das Problem nicht, und wenn ich mich über VPN Einwähle, ist das Problem auch nicht vorhanden.
17.12.2020 12:51
Hier mal tracing von heute, es ist echt zum 😭 Das geht hier seit Tagen so.
Host Loss% Snt Last Avg Best Wrst StDev 1. pcxy 0.0% 32 0.2 0.2 0.1 0.2 0.0 2. fritz.box 0.0% 32 1.2 1.2 0.8 4.0 0.5 3. p3e9bf7d8.dip0.t-ipconnect.de 0.0% 32 5.0 7.3 4.6 61.4 9.9 4. 217.5.111.94 0.0% 32 13.8 137.6 13.0 1004. 248.0 5. 80.156.162.178 0.0% 32 13.1 13.4 12.7 17.4 1.1 6. if-ae-45-2.tcore1.fr0-frankfurt.as6453.net 40.6% 32 98.2 98.9 98.1 102.7 1.1 7. if-ae-55-2.tcore2.pvu-paris.as6453.net 0.0% 32 102.1 102.3 101.6 104.8 0.6 8. if-ae-49-2.tcore1.pvu-paris.as6453.net 12.5% 32 102.3 102.3 101.7 103.1 0.3 9. if-ae-11-2.tcore1.pye-paris.as6453.net 93.5% 32 101.9 102.7 101.9 103.4 1.1 10. if-ae-3-2.tcore1.l78-london.as6453.net 3.1% 32 98.8 99.0 97.9 102.2 0.8 11. if-ae-66-2.tcore2.nto-newyork.as6453.net 0.0% 32 102.1 103.1 101.6 118.4 3.1 12. if-ae-12-2.tcore1.n75-newyork.as6453.net 0.0% 32 102.0 103.3 101.8 117.4 3.1 13. 66.110.96.157 0.0% 32 112.9 107.3 105.7 114.7 2.4 14. 52.93.31.37 0.0% 32 106.5 109.4 106.0 134.3 5.6 15. 52.93.4.4 0.0% 32 106.1 106.6 105.2 129.5 4.2 16. (waiting for reply) 17. (waiting for reply) 18. (waiting for reply) 19. (waiting for reply) 20. (waiting for reply) 21. (waiting for reply) 22. 150.222.241.179 21.9% 32 110.5 111.0 110.0 117.0 1.7 23. (waiting for reply)
17.12.2020 15:35
So kleines update von mir heute. Ich habe eben meine Fritzbox neu gestartet, bzgl. des S3 Problems keine Änderung. Ich habe mir jetzt auch mal winMTR auf meinen PC geladen (haha auch von Github, zum glück recht klein). Aktueller Output sieht folgendermaßen aus:
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| pfsense-master.xxxxxxxxxxxxxx - 0 | 263 | 263 | 0 | 0 | 10 | 0 |
| FRITZ-NAS - 0 | 263 | 263 | 0 | 7 | 72 | 6 |
| p3e9bf615.dip0.t-ipconnect.de - 0 | 263 | 263 | 6 | 7 | 69 | 7 |
| pd900c972.dip0.t-ipconnect.de - 0 | 263 | 263 | 10 | 10 | 20 | 11 |
| 80.156.162.178 - 0 | 263 | 263 | 10 | 10 | 38 | 20 |
|if-ae-45-2.tcore1.fr0-frankfurt.as6453.net - 3 | 245 | 240 | 95 | 96 | 117 | 95 |
| if-ae-55-2.tcore2.pvu-paris.as6453.net - 1 | 256 | 254 | 94 | 95 | 111 | 95 |
| if-ae-49-2.tcore1.pvu-paris.as6453.net - 4 | 233 | 225 | 95 | 96 | 129 | 95 |
| if-ae-11-2.tcore1.pye-paris.as6453.net - 2 | 249 | 245 | 94 | 95 | 105 | 95 |
| if-ae-3-2.tcore1.l78-london.as6453.net - 28 | 126 | 91 | 0 | 95 | 105 | 95 |
|if-ae-66-7.tcore2.nto-newyork.as6453.net - 3 | 241 | 235 | 95 | 96 | 131 | 95 |
|if-ae-12-2.tcore1.n75-newyork.as6453.net - 0 | 263 | 263 | 94 | 95 | 114 | 95 |
| 66.110.96.157 - 0 | 263 | 263 | 103 | 104 | 118 | 104 |
| 52.93.31.47 - 0 | 263 | 263 | 103 | 104 | 132 | 104 |
| 52.93.4.46 - 0 | 263 | 263 | 103 | 103 | 122 | 103 |
| Request timed out. - 100 | 52 | 0 | 0 | 0 | 0 | 0 |
| 150.222.242.116 - 16 | 164 | 139 | 103 | 104 | 115 | 104 |
| Request timed out. - 100 | 52 | 0 | 0 | 0 | 0 | 0 |
| Request timed out. - 100 | 52 | 0 | 0 | 0 | 0 | 0 |
| Request timed out. - 100 | 52 | 0 | 0 | 0 | 0 | 0 |
| Request timed out. - 100 | 52 | 0 | 0 | 0 | 0 | 0 |
| 150.222.241.173 - 16 | 164 | 139 | 103 | 104 | 121 | 104 |
| Request timed out. - 100 | 52 | 0 | 0 | 0 | 0 | 0 |
| Request timed out. - 100 | 52 | 0 | 0 | 0 | 0 | 0 |
| Request timed out. - 100 | 52 | 0 | 0 | 0 | 0 | 0 |
| Request timed out. - 100 | 52 | 0 | 0 | 0 | 0 | 0 |
| Request timed out. - 100 | 52 | 0 | 0 | 0 | 0 | 0 |
| Request timed out. - 100 | 52 | 0 | 0 | 0 | 0 | 0 |
| Request timed out. - 100 | 52 | 0 | 0 | 0 | 0 | 0 |
| Request timed out. - 100 | 52 | 0 | 0 | 0 | 0 | 0 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v1.00 GPLv2 (original by Appnor MSP - Fully Managed Hosting & Cloud Provider)
Hier auch noch die Werte über Mobilfunk:
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.43.1 - 7 | 73 | 68 | 2 | 97 | 4545 | 6 |
| Request timed out. - 100 | 19 | 0 | 0 | 0 | 0 | 0 |
| Request timed out. - 100 | 19 | 0 | 0 | 0 | 0 | 0 |
| Request timed out. - 100 | 19 | 0 | 0 | 0 | 0 | 0 |
| Request timed out. - 100 | 19 | 0 | 0 | 0 | 0 | 0 |
| Request timed out. - 100 | 19 | 0 | 0 | 0 | 0 | 0 |
| Request timed out. - 100 | 19 | 0 | 0 | 0 | 0 | 0 |
| Request timed out. - 100 | 19 | 0 | 0 | 0 | 0 | 0 |
| 80.156.5.83 - 7 | 75 | 70 | 22 | 128 | 1731 | 92 |
| d-ed5-i.D.DE.NET.DTAG.DE - 13 | 63 | 55 | 24 | 144 | 1251 | 51 |
| d-sb21-i.D.DE.NET.DTAG.DE - 11 | 68 | 61 | 26 | 98 | 481 | 79 |
| d-ed5-i.D.DE.NET.DTAG.DE - 11 | 67 | 60 | 25 | 135 | 1220 | 97 |
| 80.157.204.58 - 7 | 75 | 70 | 29 | 130 | 1715 | 182 |
| ae1.cr8-nyc2.ip4.gtt.net - 6 | 78 | 74 | 109 | 223 | 1423 | 362 |
| a100-gw.ip4.gtt.net - 6 | 79 | 75 | 112 | 234 | 1715 | 160 |
| 52.93.1.85 - 11 | 67 | 60 | 117 | 209 | 1230 | 231 |
| 52.93.1.36 - 11 | 67 | 60 | 116 | 224 | 1423 | 316 |
| Request timed out. - 100 | 19 | 0 | 0 | 0 | 0 | 0 |
| Request timed out. - 100 | 19 | 0 | 0 | 0 | 0 | 0 |
| Request timed out. - 100 | 19 | 0 | 0 | 0 | 0 | 0 |
| Request timed out. - 100 | 19 | 0 | 0 | 0 | 0 | 0 |
| Request timed out. - 100 | 19 | 0 | 0 | 0 | 0 | 0 |
| 52.93.29.54 - 9 | 70 | 64 | 115 | 221 | 713 | 293 |
| Request timed out. - 100 | 19 | 0 | 0 | 0 | 0 | 0 |
| Request timed out. - 100 | 19 | 0 | 0 | 0 | 0 | 0 |
| Request timed out. - 100 | 19 | 0 | 0 | 0 | 0 | 0 |
| Request timed out. - 100 | 19 | 0 | 0 | 0 | 0 | 0 |
| Request timed out. - 100 | 19 | 0 | 0 | 0 | 0 | 0 |
| Request timed out. - 100 | 19 | 0 | 0 | 0 | 0 | 0 |
| s3-1.amazonaws.com - 7 | 75 | 70 | 113 | 211 | 1346 | 316 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v1.00 GPLv2 (original by Appnor MSP - Fully Managed Hosting & Cloud Provider)
Vom reinen package loss sieht es jetzt ja deutlich besser aus, aber ich erreiche weiterhin nur eine Bandbreite i 1 bis 2 Stelligen kb/s Bereich.
17.12.2020 16:00
Der Vollständigkeit halber hier mal ein tracert von mir...
Routenverfolgung zu s3.amazonaws.com [52.217.14.134]
über maximal 30 Hops:
1 <1 ms <1 ms <1 ms fritz.box [192.168.178.1]
2 6 ms 5 ms 5 ms p3e9bf1b8.dip0.t-ipconnect.de [62.155.241.184]
3 410 ms 7 ms 6 ms d-ed5-i.D.DE.NET.DTAG.DE [217.5.71.98]
4 8 ms 6 ms 9 ms 80.157.204.58
5 87 ms 83 ms 83 ms ae1.cr8-nyc2.ip4.gtt.net [89.149.128.166]
6 93 ms 93 ms 91 ms a100-gw.ip4.gtt.net [173.205.58.70]
7 103 ms 100 ms 101 ms 52.93.1.91
8 93 ms 93 ms 93 ms 52.93.1.10
9 * * * Zeitüberschreitung der Anforderung.
10 * * * Zeitüberschreitung der Anforderung.
11 * * * Zeitüberschreitung der Anforderung.
12 * * * Zeitüberschreitung der Anforderung.
13 * * * Zeitüberschreitung der Anforderung.
14 98 ms 97 ms 97 ms 52.93.29.86
15 * * * Zeitüberschreitung der Anforderung.
16 * * * Zeitüberschreitung der Anforderung.
17 * * * Zeitüberschreitung der Anforderung.
18 * * * Zeitüberschreitung der Anforderung.
19 * * * Zeitüberschreitung der Anforderung.
20 * * * Zeitüberschreitung der Anforderung.
21 98 ms 97 ms 97 ms s3-1.amazonaws.com [52.217.14.134]
17.12.2020 17:17
Das ist interessant. Die Zahlen am Anfang sehen für mein Verständnis erstmal gut aus, Lediglich die Fehler weiter unten fallen mir ins Auge. Kann ich irgendwie feststellen von welcher Location ein Download bei mir aktuell versucht wird?
17.12.2020 17:57 Zuletzt bearbeitet: 17.12.2020 18:00 durch den Autor
Ähnliches Bild auch hier:
In einem anderen Beitrag hatte ich auch schon mal auf das Problem hingewiesen.
Aktuell habe ich zum Beispiel bei folgendem Link:
(Hostname: github-production-release-asset-2e65be.s3.amazonaws.com -> 52.216.111.19)
an unserem Telekom-Anschluss Downloadraten von 15-18 kB/s. Selbst über das TOR-Netzwerk bekomme ich da aktuell >600 kB/s.
17.12.2020 17:59
Ich habe zum test auch dieses File mal probiert. Ich schaffe ca 12 kb/s...
17.12.2020 18:16
Traceroute zu github-production-release-asset-2e65be.s3.amazonaws.com:
Traceroute zu s3.amazonaws.com:
Zum Vergleich:
amazon.com
amazon.de
17.12.2020 18:39
welches. file?
ich habe eben noch mal alle tests Durchlaufen lassen, keine Fehler
Änliche Ergebnisse wie heute Mittag.
Bei den kleinen Dateien 4mbit Minimum
bei den grossen Dateien schlechtester Wert bei ap-northeast-2 mit 30mbit/s bester werte eu-west-3 mit 400mbit/s
17.12.2020 19:27
17.12.2020 19:33
Dein File konnte ich in 5 Sekunden Laden über wlan
17.12.2020 19:34
Tja 😄
17.12.2020 19:38
Gleiches Problem hier, Downloads von Github quasi unmöglich. Reddit zeichnet übrigens ein ähnliches Bild, wahrscheinlich CDN identisch?
17.12.2020 19:39
Da ich über die gleiche Route gehe wie ihr, muss es eine andere Ursache geben die man im Tracert nicht sieht.
17.12.2020 20:15
Weil jetzt hier auch mal Dockerhub erwähnt wurde, da habe ich auch enorme Probleme, aber unabhängig von der Verbindung.
Egal ob Telekom oder mein lokaler Provider, bei Dockerhub geht aktuell rein garnichts. Ich denke das ist auch der Grund warum die das so enorm kastriert haben, der Traffic da wird zu viel.
Aber da sieht mir das nicht nach nem Peering Problem aus, denn dann würde mein lokaler Anbieter nicht das selbe Problem haben.
Bei Github jedoch sieht das anders aus.
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.
Informieren Sie sich über unsere aktuellen Internet-Angebote.