Amazon AWS S3 / Github downloads sehr langsam, nicht nutzbar

Gelöst

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?

3 AKZEPTIERTE LÖSUNGEN
Lösung

@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 Lachend



@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  

Lösung
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  

Lösung

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

2021-01-13 10_34_03-The Fastest Free Proxy _ hide.me.png

Lösung in ursprünglichem Beitrag anzeigen  

@lsup 

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.

bzw. poste mal den Link zu einem langsamen Download, bei mir sind div. Test schnell gewesen

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:

lsup_0-1608151189295.png

lsup_1-1608151583209.png

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:

https://github.com/buchen/portfolio/releases/download/0.49.4/PortfolioPerformance-distro-0.49.4-win3...

 

Kann man über die Messungen schon etwas sagen?

 

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

@lsup 

De 10.1.0.2 in deinem Netz verwirft Ping Pakete. Zwinkernd

 

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.

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?

@lsup 

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.

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.

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.

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)

 

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.

 

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]

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?

lsup_0-1608221483466.png

 

Ähnliches Bild auch hier:

Zwischenablage01.jpg

In einem anderen Beitrag hatte ich auch schon mal auf das Problem hingewiesen.

Aktuell habe ich zum Beispiel bei folgendem Link:

https://github.com/win-acme/win-acme/releases/download/v2.1.13.1/win-acme.v2.1.13.978.x64.pluggable....

(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.

Ich habe zum test auch dieses File mal probiert. Ich schaffe ca 12 kb/s...

Traceroute zu github-production-release-asset-2e65be.s3.amazonaws.com:

tm_107_0-1608224766696.png

Traceroute zu s3.amazonaws.com:

Zwischenablage01.jpg

Zum Vergleich:

amazon.com

Zwischenablage01.jpg

amazon.de

Zwischenablage01.jpg

@lsup 

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

Ich will mich hier einfach mal anschließen:
Download von Github und Docker Hub sind leider nicht Nutzbar.

Via VPN natürlich wie üblich nutzbar.

Der Speedtest zu Amazon sieht aus wie bei @tm_107 

@tm_107 

Dein File konnte ich in 5 Sekunden Laden über wlan

Gleiches Problem hier, Downloads von Github quasi unmöglich. Reddit zeichnet übrigens ein ähnliches Bild, wahrscheinlich CDN identisch?

Da ich über die gleiche Route gehe wie ihr, muss es eine andere Ursache geben die man im Tracert nicht sieht.

 

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.