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  

Dass das Problem sofort mit NordVPN (bezahlt) verschwindet, kann ich bestätigen.

Ich finde halt immer noch merkwürdig, dass es auch nur eine bestimmte Anzahl an Leuten betrifft.

 

Ich arbeite vom Telekom Netz aus ja sogar mit Github und meine ganzen Kollegen ja auch und da hat keiner Probleme.

Auch nach der Nutzeranzahl in diesem Thread sind es ja auch eher wenige Betroffene (sonst wäre hier noch deutlich mehr los).

Und ich finde es daher auch schade, dass man da keine Lösung findet doch alle über die funktionierenden Routen zu leiten. Da muss doch AWS mal was tun...


@FelixKruemel  schrieb:

Und ich finde es daher auch schade, dass man da keine Lösung findet doch alle über die funktionierenden Routen zu leiten. Da muss doch AWS mal was tun...


Warum sind nicht alle Routen ausreichend dimensioniert? Wo ist das Problem? Warum müssen Anbieter wie Github/Amazon darauf achten, Traffic nur über bestimmte Routen zu schicken? Hat die Telekom nicht genug Glasfaserkapazität?


@rtel  schrieb:

Dass das Problem sofort mit NordVPN (bezahlt) verschwindet, kann ich bestätigen.


Natürlich löst ein VPN das Problem, das wurde ja hier schon ausführlich thematisiert.

Etwas merkwürdig ist die Sache ja schon: Genau ab 08:00 Uhr bricht die Datenrate ein. Ich habe eine 91er IP-Adresse (also eine die von AWS aus über Cogent geroutet wird) und um 07:58 erfolgt ein Download mit 10 MB/s (entspricht also etwas über 80 MBit/s). Starte ich den gleichen Download um 08:01, so werden <64 kbit/s erreicht und der Download bricht auch irgendwann ab. Laut mtr.sh ändert sich das Routing nicht. Schneide ich den TCP-Datenstrom (mit Wireshark) mit, so ist eindeutig der Paketloss (>20%) ursächlich für die geringe Datenrate. Abends kann ich keinen genauen Zeitpuntk ermitteln, wann die Datenrate wieder steigt - irgendwann zwischen 21 Uhr 22 Uhr wird es besser, ab 23 Uhr ist es auf jeden Fall wieder normal. Dieses Verhalen lässt sich nicht mit den normalen Tagesverläufen des Internettraffics erklären (siehe z.B. https://www.de-cix.net/de/locations/germany/frankfurt/statistics, ja auch wenn die Telekom nicht am De-CIX peert, lässt sich das wohl auf die private Peerings der Telekom übertragen). Dort wird nämlich das 08 Uhr-Niveau erst nach Mitternacht erreicht.

Das sieht für mich eher danach aus als ob irgendein Großkunde der Telekom Punkt 08 Uhr beginnt, große Datenmengen aus dem Netz von Cogent zu ziehen ( z.B: aus der Open Telekom Cloud? Da ist ja inbound Traffic kostenlos, d.h. wenn dort ein Kunde große Datenmengen beispielsweise von AWS zieht geht das über die gleichen Netzübergänge wie bei uns DSL-Kunden).

So etwas müsste man aber doch im Netzmanagement der Telekom bemerken und ggf. gegensteuern.

 

 

 

 

 


@marc.sowen  schrieb:

@FelixKruemel  schrieb:

Und ich finde es daher auch schade, dass man da keine Lösung findet doch alle über die funktionierenden Routen zu leiten. Da muss doch AWS mal was tun...


Warum sind nicht alle Routen ausreichend dimensioniert? Wo ist das Problem? Warum müssen Anbieter wie Github/Amazon darauf achten, Traffic nur über bestimmte Routen zu schicken? Hat die Telekom nicht genug Glasfaserkapazität?


Hallo Erde an @marc.sowen ??

Wie soll dies den gehen ? 

Alleine die Frage wo das Problem liegt beweisst das totale nichtverstehen von fundamentalen Konzepten im Internet.

 

 

 


@Stefan  schrieb:

Hallo Erde an @marc.sowen ??

Wie soll dies den gehen ? 

Alleine die Frage wo das Problem liegt beweisst das totale nichtverstehen von fundamentalen Konzepten im Internet.

Oh, dann bin ich mal auf eine Erklärung gespannt. Das Problem sind eindeutig die Edge-Router, die die Telekom mitzuverantworten hat. Zwischen AWS und Cogent ist nämlich alles grün.

 

P.S. Als "Community Guide" würde ich an Deiner Stelle vielleicht etwas an Deinem Ton arbeiten.


@marc.sowen  schrieb:

Oh, dann bin ich mal auf eine Erklärung gespannt. Das Problem sind eindeutig die Edge-Router, die die Telekom mitzuverantworten hat. Zwischen AWS und Cogent ist nämlich alles grün.

Was brauchts da für eine Erkärung?

Jede Interconnection wird so vereinbart, dass der zu erwartende Verkehr problemlos darüber abgewickelt wird.

Wenn es bei der Telekom in der Vergayngenheit anders ist oder war, so ist dies nicht zu akzeptieren.

Wenn aber nun plötzlich an einer Schnittstelle Faktor X ankommt, dann  säuft sie halt ab. Was kann da der Edge Router dafür?

Über welche Schnittstelle was zu erwarten ist wird normalerweise über BGP gesteuert. Auf keinen Fall ist das ein Zufallsprodukt.

Genau da scheint es aber irgendwo zu klemmen - Wo wäre schön zu wissen und an die Stelle darf man dann auch gerne Vorwürfe richten. Wenn es die Telekom ist - gilt das ebenso. Aktuell weiss ich es nicht und du auch nicht.

 

Wenn du ein Haus mit einer 5m breiten Hofeinfahrt hast und auf der andern Seite ein Gartentor und zu einer Feier mit 300 Menschen einlädst - nach Corona natürlich - und die Adresse der Hofheinfahrt auf die Einladung schreibst, es kommen aber alle durch das Gartentor - was machst du dann ?

 

a. Du sagt, kommt doch bitte vorne rum, wie ich es euch gesagt habe.

b. Du reisst deine Gartenpforte ab und macht eine weitere 5m Einfahrt - weil irgendeiner gefragt hat, warum sind dein deine Eingänge nicht alle gleich bereit?

 

Zwischen AWS und Telekom direkt - ist auch alles "Grün" und nun?

 

Ich bin hier Telekom Kunde wie du auch. Weder direkt noch indirekt von der Telekom abhängig.

Nur dadurch dass ich auch Community Guide bin, werde ich Unsinn und Quatsch trotzdem Unsinn und Quatsch nennen.

 


@Stefan  schrieb:

a. Du sagt, kommt doch bitte vorne rum, wie ich es euch gesagt habe.

b. Du reisst deine Gartenpforte ab und macht eine weitere 5m Einfahrt - weil irgendeiner gefragt hat, warum sind dein deine Eingänge nicht alle gleich bereit?

Ah, jetzt kommen wir der Sache näher: Die Telekom sagt die ganze Zeit "a", aber ich möchte wirklich, dass mein Provider bitte auch "b" ermöglicht und überall große Zugänge bereit hält. Daher meine - zugegebenermaßen polemische - Frage, ob die Telekom nicht genügend Glasfaserkapazität hat. Oder anders gefragt: Wieviel Geld muss ich der Telekom noch zahlen, damit sie das tut?

 

Ich bin hier Telekom Kunde wie du auch. Weder direkt noch indirekt von der Telekom abhängig.

Nur dadurch dass ich auch Community Guide bin, werde ich Unsinn und Quatsch trotzdem Unsinn und Quatsch nennen.

Tut mir leid. Ein "Guide" suggeriert mir eine engere Verbindung mit der Telekom. Sollte man vielleicht anders bezeichnen. Ich würde dann gerne mal von den richtigen Telekom-Mitarbeitern eine Stellungnahme hören. Hat ja wenig Sinn, wenn sich zwei Unwissende miteinander unterhalten. Ich möchte ja, dass das Problem gelöst wird.

Hallo,

 

ich bin per Suche auf diesen Faden gestoßen. Ich habe ebenfalls seit mehreren Wochen schon Probleme mit Downloads von Github mit meinem Telekom VDSL 100 Anschluss. Die Downloads laufen dann immer nur mit einstelligen kb/s Raten und brechen dann nach einigen Minuten ab.

 

Bisher ging ich davon aus das sich das in einigen Tagen von selber erledigt, aber dem ist leider nicht so da der Zustand jetzt schon wie gesagt mehrere Wochen so bei mir ist.

 

Momentan lade ich dann meine Github Downloads über meine O2 LTE Verbindung mit dem Smartphone runter, dort dann halt auch mit vollen 50 Mbit/s. Das ist aber keine Dauerlösung für größere Downloads.

 

Gibt es hier mittlerweile eine Lösung das ich mit meinem Festnetzanschluss die Downloads wieder durchführen kann?

 

Danke und Grüße

 

P.S. Router neustarten bringt auch nix.

Sensationelle 50 KB/s von Github und das hier schon seit dem 4. Januar. Es darf echt mal was passieren.

Ich schließe mich mal an. Habe exakt die gleichen Probleme wie die hier beschriebenen und bin auch durch die Diskussionen auf Github auf diesen Thread hier gestoßen.
Mit meinem VDSL250 schaffe ich es bestenfalls auf ein KB/s. Meist bricht der Download zwischendurch komplett zusammen.

Wenn ich dann den Traffic über den VPN meines Arbeitgebers leite (Deutscher Standort, 2km Luftlinie vom Home-Office entfernt) läuft alles wie am Schnürchen 


@Stefan  schrieb:

@marc.sowen  schrieb:

@FelixKruemel  schrieb:

Und ich finde es daher auch schade, dass man da keine Lösung findet doch alle über die funktionierenden Routen zu leiten. Da muss doch AWS mal was tun...


Warum sind nicht alle Routen ausreichend dimensioniert? Wo ist das Problem? Warum müssen Anbieter wie Github/Amazon darauf achten, Traffic nur über bestimmte Routen zu schicken? Hat die Telekom nicht genug Glasfaserkapazität?


Hallo Erde an @marc.sowen ??

Wie soll dies den gehen ? 

Alleine die Frage wo das Problem liegt beweisst das totale nichtverstehen von fundamentalen Konzepten im Internet.

 


Ruhig bleiben.. Ganz abwegig ist das ja nicht, das Peering zwischen Cogent und der Telekom scheint aus allen Nähten zu platzen, und dass das ganze schon lange erweitert werden müsste, hat Cogent ja bereits in 2015 angemerkt. Passier ist bis dato nix. 

Sicher wäre ausgehend von AWS das direkte Peering mit der Telekom die bessere Route, aber es gibt eben neben AWS auch noch andere Anbieter ohne direktes Peering zur Telekom, die über Cogent routen. Die sind genauso von dem Problem betroffen und haben vermutlich keine andere Möglichkeit..


@sral96  schrieb:

Sicher wäre ausgehend von AWS das direkte Peering mit der Telekom die bessere Route, aber es gibt eben neben AWS auch noch andere Anbieter ohne direktes Peering zur Telekom, die über Cogent routen. Die sind genauso von dem Problem betroffen und haben vermutlich keine andere Möglichkeit..


Ist doch ein Wasserhahn Problem.

Wenn andere durch das Cogent Peering müssen ist das doch kein Problem, wenn nicht das AWS Peering den Überlauf verursacht.

Woher weisst du das seit 2015 NICHTS passiert ist? Ich gehe üerigens ja auch über Cogent von der AWS.

Es ist also mitnichten so, dass das ganze Cogent Telekom peering überlaufen ist.


@sral96  schrieb:

Sicher wäre ausgehend von AWS das direkte Peering mit der Telekom die bessere Route, aber es gibt eben neben AWS auch noch andere Anbieter ohne direktes Peering zur Telekom, die über Cogent routen. Die sind genauso von dem Problem betroffen und haben vermutlich keine andere Möglichkeit..


Es ist ja nicht so, daß zu allen Anschlüssen so lahme Routen sind. Ich habe eben gerade über den Hybrid Anschluss eine mehr als ausreichende Geschwindigkei gehabt. Nur bei unserem DSL lahmt es.

Hallo!
Ich reihe mich ebenfalls als (frustrierter) Betroffener ein. Zu Tages- und Abendszeiten ist es mir unmöglich, Dateien von Github herunterzuladen (angegebene ETA mehrere Tage!).

Mitten in der Nacht (2, 3, 4 Uhr) ist der Download halbwegs akzeptabel (für wenige MB dauert es dann ca 10-30 Minuten). Natürlich kann das aber nicht eine dauerhafte Lösung für mich sein.

 

Im Übrigen finde ich es ein wenig anmaßend, den Thread als gelöst zu markieren. (Ich bin mir bewusst, dass dies gemacht wurde, um Beiträge zu pinnen). Jedoch ist es für mich als Laien eben ganz einfach folgendermaßen: Ich stelle diese Probleme im Dezember fest. Ich beobachte das Problem ein paar Tage doch es löst sich leider nicht von selbst. Ich beginne mit der Recherche im WWW und freue mich, dass es diesbezüglich bereits Beiträge gibt. "Juhu, selbst im Telekomfourm ist das Problem bereits bekannt". Nun steht dort allerdings auch, dass das Problem als gelöst markiert ist. Aber Moment, ich persönliche habe dieses Problem weiterhin?!? Also warten. Tja und dann... und dann? Warum kann ich Ende Januar immer noch nicht mit Github arbeiten, wenn das Problem doch gelöst ist? Da fühle ich mich als Laie schon etwas veralbert.

 

Ich bin mir bewusst, dass viele technische Probleme eben nicht innerhalb weniger Stunden zu lösen sind. Natürlich kann es auch mal vorkommen, dass ein gewisses Problem eben 14 Tage oder auch 3 Wochen benötigt, um gelöst zu werden. Volles Verständnis dafür! Allerdings wäre es dann seitens der Telekom wirklich hilfreich, wenn man ungefähre Angaben macht. Wenn ich beispielsweise höre/lese, dass dieses Problem voraussichtlich Mitte März 2021 behoben ist, dann kann ich mich darauf einstellen. Die jetzige (ungewisse) Situation ist aus meiner Sicht aber wirklich kundenunfreundlich.

 

Zu den vorgeschlagenen Lösungen: Was ist, wenn die in diesem Thread vorgeschlagenen Lösungen für meine spezielle Situation nicht anwendbar sind? Was ist, wenn ich aus verschiedenen Gründen kein VPN aufsetzen kann und auch der Umweg mit den Einzeldatei-Downloads nicht in Frage? Die Gründe spielen übrigens keine Rolle. Sie sollten egal sein! Es könnte ja schlichtweg sein, dass mir als Laie einfach das Know-How und der Mut fehlt.

Ich habe einen Vertrag mit der Telekom. In diesem ist die die Downloadgeschwindigkeit/Bandbreite (und auch die minimale Downloadgeschwindigkeit) geregelt. Außerdem ist auch die mittlere Verfügbarkeit geregelt. Es kann nun natürlich gut sein, dass die "Engstellen" gar nicht in der Hand der Telekom liegen. Das ist zwar technisch und rechtlich interessant, nützt mir als Kunden aber wenig. Als Laie möchte in einen Vertrag abschließen, es soll (die meiste Zeit) funktionieren. Punkt.

 

Besondere Frustration kommt hinzu, da ich in den Jahren (ungefähr) 2012-2013 ebenfalls Routingprobleme hatte. Damals habe ich in einer anderen Stadt gelebt. Internetanbieter war die Telekom.

Beim Umzug und bei den darauffolgenden Umzügen habe ich aus verschiedenen Gründen keinen Telekomvertrag gehabt. Interessanterweise gab es dann auch keine feststellbaren Routingprobleme.

Seit 2020 bin ich wieder bei der Telekom und den Rest der Geschichte kennt ihr.

 

So, nun habe auch ich meinen Senf dazu gegeben. Vielen Dank für's Lesen!

Grüße!


@felix.guben  schrieb:

 

Im Übrigen finde ich es ein wenig anmaßend, den Thread als gelöst zu markieren. (Ich bin mir bewusst, dass dies gemacht wurde, um Beiträge zu pinnen).

Hallo

Wenn dir der Grund klar ist, frage ich mich was daran anmassend ist?

In andern Thread wird gefragt, kann ich auch vorzeitig aus meinem Vertrag, weil er mir zu teuer ist.

Die Antwort ist "nein". Das stellt für den Frage auch keine befriedigende Lösung dar, ist aber einfach die korrekte Antwort auf die Frage.

 

Ich stimme dir zu, dass die Forensoftware bezuüglich ihrer Möglichkeiten etwas hervorzuheben suboptimal ist.

Dinge im Leben sind aber selten optimal

 

Weder die minimale noch die mittlergeschwindigkeit regelt die Geschwindigkeit zu einem bestimmten Server.

Die DSL Geschwindigkeit beschreibt die Gesamtgeschwindigkeit die in Summe aller aktiven Übertragungen gleichzeitig erreicht werden können. 1000 gleichzeitige Downloads mit max 100kbit/s wären auch VDSL100 konform.

Aber auch das wurde hier schon mehrfach durchgekaut.

 

Befriedigend ist die Situation für keinen Beteiligten

 

Hallo Stefan,

 


Wenn dir der Grund klar ist, frage ich mich was daran anmassend ist?


Die Antwort habe ich direkt im nächsten Satz geschrieben:)

 

 


Weder die minimale noch die mittlergeschwindigkeit regelt die Geschwindigkeit zu einem bestimmten Server.

Die DSL Geschwindigkeit beschreibt die Gesamtgeschwindigkeit die in Summe aller aktiven Übertragungen gleichzeitig erreicht werden können. 1000 gleichzeitige Downloads mit max 100kbit/s wären auch VDSL100 konform.


Danke für die Erklärung, auch wenn mir persönlich das vorher durchaus bewusst war. Aber was sagt der Laie dazu? Vielleicht: Ich habe einen Vertrag über eine 100er Leitung (Down-Richtung). Natürlich liefert nicht jeder Server mit dieser Geschwindigkeit. Muss er ja auch nicht. Allerdings: gibt es an einzelnen Tagen zu einzelnen Servern Probleme im Bereich, also Downloadraten im Bereich Kb/s, dann ist das vollkommen OK. Gibt es dauerhaft(!) Probleme, dann bin ich unzufrieden. Bin halt auch nur ein Laie!

 

 


Befriedigend ist die Situation für keinen Beteiligten


Zustimmung!

@Kugic, ich vermute, dass ein kompletter Scale-Out an einen zweiten Standort nicht wirklich eine Option für Github darstellt. Wenn du dir die Größe der dort gesamt gehosteten Projekte vor Augen führst, dann siehst du, dass eine solche Aktion mit zu hohen Kosten verbunden ist. Github "gehört" zwar jetzt Microsoft, aber das heißt noch lange nicht, dass sie Geld auf Heuwagen in die heiligen Hallen gefahren bekommen Zwinkernd

Beste Grüße
Karsten

@byteborg  schrieb:
Github "gehört" zwar jetzt Microsoft, aber das heißt noch lange nicht, dass sie Geld auf Heuwagen in die heiligen Hallen gefahren bekommen


Dann sollen sie es auf Azure umziehen, dann kostet es Microsoft vermutlich effektiv mit Standortreplikation so viel wie heute

@byteborg
Ich wollt damit ja auch nur sagen, dass sie schon Möglichkeiten haben, es aus der EU besser erreichbar zu machen. Aber eben das Geld nicht ausgeben wollen.

Auch die tragen es also auf dem Rücken der Kunden aus.

Das es bei Amazon und Telekom so lange dauert, liegt an der Unternehmensgröße der beiden. Je größer der Kahn, desto weniger flexibel bei der Steuerung.

Hi,

 

bei mir scheint es gerade in diesem Moment wieder richtig zu funktionieren (> 20 MegaByte/s). Habe es aber nur mit Freecad und prusaslicer probiert. Habe immer noch eine 84er Adresse.

 

Wie sieht es bei den anderen aus?

Habe aktuell ne IP aus 84.128.0.0/10 und bei mir kommen 100MBit Full Speed an.

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

Seit zwei drei Tagen bestimmt keine Probleme mehr bei mir gehabt. Interessant wären jetzt wieder die anderen IP Bereiche.

Mir wurde gestern auch eine neue IP Adresse zugewiesen, sogar aus dem gleichen Bereich 91.50.x.x wie vorher auch.

In der Grafik kann man erkennen dass der Download Speed nicht gleich verfügbar war, jedoch ab ca. 19:00 Uhr langsam anstieg. Seither gab es auch keine Limitierung der Bandbreite wie es in der Woche zuvor jeden Morgen passierte.

Ich bin gespannt wie es sich die kommenden Tage verhält.

 

luddinho_0-1611417355635.png

 

Ich habe gerade auch den Download nochmal gestartet und siehe da, es ist sehr schnell (6MB/s) gewesen. Meine IP liegt gerade im Bereich: 91.62.X.X

Mein letzter Disconnect ist vom 18.01.2021 um 04:38. Ich habe gerade eben auch nochmal einen Anruf der Telekom zu meinen geöffneten Ticket bekommen. Scheinbar war dieses doch noch nicht geschlossen, aber wurde auch nicht wirklich weiter gereicht. Allerdings fehlt ja noch eine offizielle Mitteilung der Telekom, ob diese etwas erreicht haben. Das habe ich nochmal den Service-Mitarbeiter mitgegeben, dass er dies bitte nochmal weiterreichen soll und ein Update hier gegeben wird.

Es wäre aber echt schön, wenn das Thema nun langfristig gelöst ist.

@Stefan 

Genau, weil ein Umzug von einer Cloud Plattform auf die andere nix kostet, keinerlei Risikostruktur hat und die Betriebskosten danach auch weg sind. Naja. Das müssten Microsoft/Github wissen, aber du kannst sie ja gerne mal für die anstehende Migration beraten...