Vielen Dank für die Info. Ich glaube Feedback ist wichtig, dann hat man hoffnung, dass es besser wird. Ich musste den Umweg über VPN gehen um meine Anwendungen zu installieren.

Ich hoffe, dass Ihr das demnächst gelöst bekommt.

Danke!

Ja, auch bei den Blauen tritt das Problem auf. Ist bei mit so. Habe ein VDSL100.

Beim blauen Anbieter hatte ich bei früheren Tests keine Probleme (Anschluss in Berlin, scheinbar nicht am Telekom-Backbone). Bei meinem Nachbarn (ebenfalls beim Blauen) treten allerdings die gleichen Probleme auf wie bei mir, das Routing sieht identisch aus und die IP stammt auch aus dem gleichen Subnetz.

Es scheint also je nach Wohnort unterschiedlich und eher ein Glücksspiel zu sein, ob ein Anbieterwechsel dorthin hilft.

Gitub nutzt leider kein CDN für die Asset-Downloads, sondern direkt S3. 

Verstehe allerdings auch nicht, warum Github hier kein Cloudfront einsetzt.

Und wegen Monopolmissbrauch: Natürlich hat die Telekom eine marktbeherrschende Stellung gegenüber Hetzner und anderen Anbietern. Sonst würde sie mit ihren unberechtigten Forderungen nicht durchkommen.

Github gehört seit 2018 zu Microsoft und es ist in der Tat verwunderlich, warum Github weiterhin auf eine eigene Cloud-Infrastruktur setzt bzw Amazon S3 nutzt. Die Verbindungsprobleme zwischen Amazon S3 und der Telekom sind aber gelöst (nach gefühlt 1000 Nachrichten hier im Thread...). Falls es bei Dir der Download von S3 Assets immer noch hakt, poste bitte mal eine Beispiel-URL. Wir haben uns hier bisher immer auf die Probleme bei der AWS Region US-EAST fokussiert, es könnte sein, dass andere Regionen weiterhin Probleme machen.

Das nenn ich erstaunlich 😮

Heute gehts und das auch mit der vollen Leitung. https://github.com/gamer-os/install-media/releases/download/2020-10-02/gameros-2020.10.02-x86_64.iso 

Es war mal so extrem das ich 9 mb sogar auf mein eigenen Server geladen habe und dann da Runtergeladen habe.

Beispiel: 

https://github.com/docker/compose/releases

https://github.com/docker/compose/releases/download/1.29.1/docker-compose-Darwin-x86_64

Und ich mach mir ganz sicher nicht solch mühe ohne grund. Das war am 22 Dec 2020

Gestern Hatte ich das Problem bei denn Repositorys von ESP-IDF. Halben Tag gebraucht für lass mich lügen ca 400mb kp.

"Github nutzt seit ca. einem Jahr ein CDN " das wusste ich schon, nur ist damit nicht geklärt weshalb es bei dem einen Anbieter besser läuft als beim anderen, trotz gleicher nameserver und sogar geringerer leitungs Kapazität.

"Bei mir auf dem Handy rennt GitHub problemlos" ja bei mir auch mit vodafone und o2 xD das sind ja meine test netze fals die telekom über dsl mal wieder nen navi zum routen braucht.

FelixKruemel

Wo bitte hat die Telekom denn ein Monopol?

Naja ich würde sagen da wo die Gerichte es auch gesehen haben, und deshalb das Netz an andere Bewerber weitervermieten müssen. Zb 1und1.

FelixKruemel

Was bei GitHub hier aber das Problem darstellt ist nicht Strecke Telekom -> GitHub sondern der Rückweg der aus irgendwelchen Gründen über die USA läuft.

Das konnte ich noch nicht beobachten. Zumal ich keine Ahnung habe warum und wie das möglich sein soll, da die Antwort doch für gewöhnlich denn gleichen weg zurück nimmt oder nich? Hier muss ich sagen steh ich gerade nicht tief genug in der Materie, also wenn das echt so ist dann is das echt halt doof gelaufen.

Dennoch bleibt platz sich aufzuregen das sowas wie Double paid traffic offensichtlich existiert. Ich hab mich am ende geweigert 5 euro für jeden server extra zu zahlen und überlegt eher zu wechseln. wenn der Anschluss nich der telekom gehören würde aber das hab ich ja schon einmal beschrieben.

---

Aber ja, das ist ja unser Problem hier wir koennen nur spekulieren. Das eine ist das technische Problem, was jetzt vermutlich bekannt ist, aber vielleicht will man es nicht loesen solange irgendwelche Peering Verhandlungen etc. laufen. Aber dann ist es halt komisch wenn man sich da aus den grossen /10 blocken irgendwie einzelne /24 rauspickt und auf ne andere miesere Route schickt anstatt gleich den grossen Hammer auszupacken.

---

richtig...aber es kommt halt kaum was an Details von der Telekom, was denn nun genau das Problem ist.

[Verschwörungstheorie an]
Den großen Hammer nicht auszupacken könnte man sich eventuell erklären. Dann wäre die Sache eindeutig und das würde vermutlich zu einer Klage führen. Wenn man das mehr wie einen Fehler aussehen lässt, dann kann man es halt besser leugnen, wenn es Absicht wäre.
[Verschwörungstheorie aus]

so halb kaputt ist aber auch als Druckmittel nicht so richtig gut...würde ich mal sagen...

Danke für Deine Beiträge, das sind mal echte Infos...

Ich stehe übrigens noch immer im direkten Austausch mit AWS - als nicht Premium-Kunde kann ich nur über deren Buchhaltung kommunizieren, aber eine sehr engagierte Dame dort leitet meine Anfragen an und die Antworten von deren Netzmanagement weiter.

Ich stehe übrigens noch immer im direkten Austausch mit AWS - als nicht Premium-Kunde kann ich nur über deren Buchhaltung  kommunizieren, aber eine sehr engagierte Dame dort leitet meine Anfragen an und die Antworten von deren Netzmanagement weiter.

Ich stehe übrigens noch immer im direkten Austausch mit AWS - als nicht Premium-Kunde kann ich nur über deren Buchhaltung  kommunizieren, aber eine sehr engagierte Dame dort leitet meine Anfragen an und die Antworten von deren Netzmanagement weiter.

das würde ich mir bei der Telekom auch wünschen...es muss doch irgendjemand geben, der da näher dran ist und mal einen Draht aufbaut...

Das mit den Server-Namen hat er vielleicht nicht verstanden...wie mir immer wieder versichert wird, haben Amerikaner oft weniger Englisch-Kenntnisse als Deutsche (sorry ein bisschen Frotzelei muss sein).
Oder war das alles auf Deutsch? das könnte dann auch so ähnlich sein, nur eben auf deutscher Seite.

Wie wär's mit einem direkten Peering zum AWS Techniker? 😉 Dann spart man sich auch noch einen Hop und etwas Latenzzeit

das hatte @jkammann  ja auch schon:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-nicht-nutzbar/m-p/4953597#M1309992