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  


@Stefan  schrieb:

Schau einfach ins Routerlog um drei uhr nachts.

Vermutlich wirst du das neu connected, weil ASSIA deine reconnects als Fehler wertet und dein Profil reconnected.

 


auf wen bezog sich das jetzt?


@hg42  schrieb:

@Stefan  schrieb:

Schau einfach ins Routerlog um drei uhr nachts.

Vermutlich wirst du das neu connected, weil ASSIA deine reconnects als Fehler wertet und dein Profil reconnected.

 


auf wen bezog sich das jetzt?


Die Antwort ist im falschen Thread gelandet. zu viele offene Fenster.


Wie oft muss eigentlich noch geschrieben werden, dass die traceroutes von euch _ZU_ AWS wertlos sind.

Eure Seite der Autobahn Richtung AWS ist frei, ja das wissen wir. Auf dem Rückweg ist aber Stau...


Neueinsteiger finden das alles bei den 450 Posts nicht...
statt der "Lösung", die keine ist, sollte stattdessen eine Zusammenfassung angeheftet werden, wie z.B. diese:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...
Wer kann das machen? Ich vermute mal, ich kann es nicht...

Oder vielleicht besser eine Link-Liste einiger Beiträge, wozu dann auch die jetzige "Lösung" gehört, wie auch der andere Beitrag vom Team.
Dann auch dieser:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...
aber auch der:
https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-ni...

einfach damit das Thema von allen Seiten beleuchtet ist.

Und sorry, wenn da noch nicht alles dabei ist, ich hab noch weitere 100 Posts zu lesen...


@Stefan  schrieb:

@sral96 

Wenn also irgend eine Webseite auf der Welt  aus technischen Gründen ausfällt, dann hast du ein Sonderkündigungsrecht nach setzen einer Nachfrist.  Eher nicht.


zu dem Beitrag hast Du soweit ich bisher (bis etwa Beitrag 350) gelesen habe, noch nichts gesagt...

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

der deutet meiner Meinung nach schon auf eine bewusste Reduzierung der Bandbreite hin.
Da fällt übrigens auch das Stichwort Netzneutralität...

Das wiederholte Herunterbeten des Arguments, dass der Vertrag letztlich nur die Leitung vom "Internet" zu meiner Wohnung beinhaltet, mag vielleicht juristisch so sein, ist aber nach meinem Verständnis zu naiv.
Es gehören sicher auch die Anbindung an die Infrastruktur und das geeignete Vorhalten derselben sowie das Peering dazu.
Sonst wäre es ja möglich, die Leitung am Kasten auf der Strasse enden zu lassen.

Natürlich ist die Telekom nicht für die Server verantwortlich, die die Daten erzeugen und auch nicht für das Routing bis zum Telekom-Netz (soweit sie keine Einfluss darauf haben), wohl aber für die Bekanntmachung von Zugängen und auch für passend große Türen.


@hg42  schrieb:
Da fällt übrigens auch das Stichwort Netzneutralität...


das Stichwort fällt mehrfach, ändert aber nichts daran dass es falsch ist und lediglich zeigt das nicht verstanden wird was Netzneutralität bedeutet.


@hg42  schrieb:
Natürlich ist die Telekom nicht für die Server verantwortlich, die die Daten erzeugen und auch nicht für das Routing bis zum Telekom-Netz (soweit sie keine Einfluss darauf haben), wohl aber für die Bekanntmachung von Zugängen und auch für passend große Türen.


Darum geht es doch, die Tür zur AWS ist nach Aussage der Telekom da und auch groß genug.

Dass passt ja auch dazu, dass es nachweislich nur ein Teil der Telekom Kunden trifft.

 

Wer nun dafür verantwortlich ist, dass die Daten beim anderen Teil durch den Kriechgang kommen ist genau zu klären.

Ich weiß es nicht und ihr halt auch nicht, ich habe hier nie etwas anderes geschrieben,

 

Die zitierten Probleme aus der Vergangenheit sind mir bekannt.  Und ich kenne auch die kontroversen Diskussionen über die Peering Politik der Telekom. Die Wahrheit dürfte wie oft in der Mitte der Argumente liegen.

Versuche gerade eine 3,9 MB Datei zu laden. Notepad++. 0 Bytes/s. Toll. VPN kann ich nicht installieren, da dies ein Firmenrechner fürs HomeOffice ist.
Telekom, lasst euch bitte mal was einfallen und tragt nicht den Streit mit Amazon oder wem auch immer auf dem Rücken der Kunden aus.
Habe Notepad++ jetzt über heise.de heruntergeladen. Jetzt brauche ich das compare plugin. Wo liegt das wohl? Richtig auf Github. Ich bin am verzweifeln. So kann man doch nicht vernünftig arbeiten. Ich bete jetzt, das er es irgendwie hinbekommt die paar kb zu laden. Hoffentlich noch heute.

ich habe den Workarround mittels Proxy nun als "Lösung" oben angepinnt, mit dem Ziel, dass sie für Neueinstieger für die diese langt einfacher zu finden ist.

Danke Stefan, aber das funktioniert nicht für Downloads. Versuche ich z.B. folgende URL: https://github.com/phhusson/treble_experimentations/releases/download/v300.l/system-roar-arm32_binde... kommt eine 4kb Datei zurück. Mit texteditor geöffnet sieht man, dass es eine html datei ist. Die Datei enthält eine Fehlermeldung.

@Sascha33 

dann nutze diesen, habe ich gerade mit deinem Download getestet - hat funktioniert.

 

Die Alternative habe ich oben auch eingefügt.

 

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

 


@der_Lutz  schrieb:

@hg42  schrieb:
Da fällt übrigens auch das Stichwort Netzneutralität...

das Stichwort fällt mehrfach, ändert aber nichts daran dass es falsch ist und lediglich zeigt das nicht verstanden wird was Netzneutralität bedeutet.


ich verstehe schon was Du meinst, aber ich bezweifle mal, dass das Wort so eindeutig definiert ist (nach welchem Standard? DIN? irgendein Gesetz? politisch), dass Du es in diesem Fall einfach so ablehnen kannst.
Ich betrachte es moralisch/sozial/gesellschaftspolitisch...ob das in Rechtsform schon so existiert oder durchgesetzt wird ist mir dabei egal, zumal es sich um Weltpolitik handelt.

Fakt ist doch, dass hier Preis-Politik durch Reduzierung der Bandbreite gegenüber bestimmten Peering-Partnern betrieben wurde (und vermutlich auch noch wird). Man könnte das übrigens auch verschleiern, indem man nur einen Teil der Pakete verlangsamen oder ähnliches, insofern sind Gegenbeispiele kein Gegenbeweis.

aus Wikipedia:
"Netzneutrale Internetdienstanbieter behandeln alle Datenpakete bei der Übertragung gleich, unabhängig von Sender und Empfänger, dem Inhalt der Pakete und der Anwendung, die diese Pakete generiert hat."
und komm mir jetzt nicht mit Wikipedia ist kein Standard...natürlich ebensowenig wie irgendeine andere Definition, aber immerhin in gewisser Weise ausdiskutiert.

Netzneutralität kann man also auf Inhalte beziehen oder auf Quelle und Senke.
Frage 1 ist dabei, ob das Generieren der Pakete nur am Ursprung passiert, oder ob es bei jeder Weiterleitung neu passiert.
Frage 2 ist, ob es bewusst geschieht.

Das bewusste Einschränken eines Partners betrachte ich als Diskriminierung.
Denn selbst wenn es sich dabei nur um das Einschränken einer Zwischenstation handelt (in dem Falle dass man nur den Ursprung als Generator akzeptiert), ist es eine Diskrimierung des gesamten Bereiches hinter dieser Übergabestelle, was im Grunde noch viel schwerer wiegt als nur eine einzelne Quelle. Es ist nicht eindeutig wo man dann die Grenze ziehen soll oder will. Faktisch werden wir in der Nutzung von github und Co. eingeschränkt mit der Aussage, dass die zuviel Verkehr generieren. Es wurde ja auch versucht die Quellen z.B. Youtube direkt abzuschöpfen, was meiner Ansicht nach sehr klar zeigt wie der Hase läuft.

Über die Absichtlichkeit kann man spekulieren. Die oben angeführten Sachverhalte aus der Vergangenheit zeigen aber, dass eine Absicht dahinter lag, es ist zumindest nicht auszuschließen, dass dies immer noch der Fall ist.

Insgesamt sehe ich übrigens das Problem gesellschaftlich auch nicht unbedingt bei der Telekom. Letztlich hat man einen Dienstleister irgendwo in der Welt und möchte ihn als Gesellschaft nutzen. Die Kosten für den Transport müssten also auf die Nutzer umgelegt werden. Wenn das System der Betreiber das nicht leistet, muss man sich fragen, was da falsch läuft.
Ich denke, dass die Telekom hier auf einem zu hohen Ross sitzt. Denn sie profitiert natürlich auch von den Inhalten. Wenn sie den Verkehr bezahlt haben möchte, müsste sie im Gegenzug auch für Inhalte bezahlen, die die Attraktivität von schnellen Anschlüssen bei den Kunden erhöht.


Darum geht es doch, die Tür zur AWS ist nach Aussage der Telekom da und auch groß genug.

Dass passt ja auch dazu, dass es nachweislich nur ein Teil der Telekom Kunden trifft.


gut, eine Tür ist da, eine andere ist aber zu eng...

warum nimmt Amazon nun die falsche Tür?
nach deren Angaben haben sie ja kein Interesse daran, einen langsamen Weg zu nehmen.

 

Fakt ist wie Du sagst, wir wissen es nicht und können es auch nicht herausfinden, z.B. weil uns auch gar nicht genug Information gegeben wird. Deswegen werden einige detektivisch tätig, um daraus die Ursache zu ermitteln, die man uns so genau nicht sagen möchte.

Übrigens: Fingerpointing betreiben sie nicht?
tun sie eben doch, denn "Amazon ist Schuld, wir können nichts machen" ist doch die Aussage.
Sie haben es ihnen gesagt und lehnen sich anscheinend zurück und warten. Da hätte ich dann doch gerne mal etwas mehr Transparenz...was war denn die Antwort von Amazon? gibt es das Problem nicht? ist es nicht lösbar? nur mit Beteiligung der Telekom? wollen sie nicht? Solange ich das nicht gesagt bekomme, verstehe ich das als Weigerung an dem Problem weiter arbeiten zu wollen. Die Dauer zeigt ja, dass es faktisch wohl auch so läuft. Wie berichtet wurde würden sie das Peering ja anpassen, wenn sie die entsprechenden IP-Bereiche wüssten.

Ich erwarte von einem Provider mit dem "besten Netz" und sowieso von einem der wesentliche Teile unserer Infrastruktur verwaltet, dass bei einem so gewichtigen Problem etwas mehr zur Lösung geschieht, und zwar ungeachtet dessen, wer dafür wieviel Schuld trägt (kein Fingerpointing!). Die Erfahrung zeigt, dass es bei sowas immer an mehreren liegt (z.B. könnte ja Cogent auch daran beteiligt sein). Wenn man sich zurücklehnt und wartet, passiert aber nichts. Aus Kundensicht sieht es jetzt seit geraumer Zeit genau nach Zurücklehnen aus, vielleicht lieg es an fehlender Berichterstattung/Transparenz, vielleicht ist es aber auch einfach so.

Warum hört man hier nichts mehr vom Team?

 


Poste mal die ersten 3 Bytes Deiner IPv4-Adresse (z.B. https://www.wieistmeineip.de/, IPv4 steht oben rechts) - dann schaue ich bei AWS nach über welche Route die Adresse erreicht wird.

kannst Du bitte mal folgende testen?
sicher langsam (zumindest als ich sie hatte):
84.166.166.253
84.166.166.81
84.166.166.46

fraglich (ich hatte an dem Tag keinen Reconnect gemacht, vielleicht hab ich es aber auch nur nicht gerafft oder brauchte nicht von github):
84.166.166.220

vermutlich langsam:
84.166.172.249

sicher schnell:
217.228.111.248

93.233.195.170


Bevor jetzt alle ihre Router so lange neu starten, bis eine "passende" IP-Adresse zugewiesen wird:

Ein häufiger Re-Sync des Routers führt dank DLM (Dynamic Link Management) dazu, dass die Datenrate über einen längeren Zeitraum (1-2 Wochen) gedrosselt wird - besser ist es daher, nur die logische DSL/PPPoE-Verbindung über das Webinterface des Routers trennen und wieder aufbauen (in der Fritzbox im Menü Internet/OnlineMonitor/Neu Verbinden).

das hört sich nicht 100% eindeutig an...ich sag es nochmal anders:
"Neu Verbinden" in der Fritzbox liefert eine neue IP ohne dabei die darunter liegende DSL-Verbindung neu zu synchronisieren.

Danke für diese Info, denn ich mache letzteres, da besteht also keine Gefahr.


Heute habe ich übrigens 52x eine IP aus dem Bereich 84.166.*.* bekommen, nur die erste war 84.166.166.*
Das scheint mir fast Absicht zu sein. Vielleicht sollte ich das mal erweitern und wieder einen engeren Bereich ablehnen (also 84.166.166.*) und bei 84.166.*.* einen Geschwindigkeitstest machen (z.B. einfach in der wget Antwort "written" und "MB" suchen).


@hg42  schrieb:
gut, eine Tür ist da, eine andere ist aber zu eng...

warum nimmt Amazon nun die falsche Tür?


Das ist genau die Frage.

Ressourcen werden immer dimensoniert, es legt ja auch kein Wasserwerk ein Rohr in dein Haus das 5000l/min liefert - für den Fall der Fälle. Und wenn bei korrekter Nutzung die andere Tür langen würde, wo ist dann das Problem? NE Ahnung was ein Hocheksitungsrouter kostet? 

 

Die Telekom betreibt kein Fingerpointing - genau deswegen wirst du auf den Block der Fragen keine Antwort bekommen.

 

 

 


@hg42  schrieb:

Heute habe ich übrigens 52x eine IP aus dem Bereich 84.166.*.* bekommen, nur die erste war 84.166.166.*
Das scheint mir fast Absicht zu sein. 

Klar, bei jedem Anmeldevorgang poppt bei einem Telekom Mitarbeiter ein Fenster auf an dem er entscheiden kann 

"Schnelles Peering" oder "den f... wir jetzt" Zwinkernd


@hg42  schrieb:
aus Wikipedia:
"Netzneutrale Internetdienstanbieter behandeln alle Datenpakete bei der Übertragung gleich, unabhängig von Sender und Empfänger, dem Inhalt der Pakete und der Anwendung, die diese Pakete generiert hat."


Genau, und wenn alle gleich langsam sind wird die Netzneutralität nicht beeinträchtigt, alles klar.

 


@Stefan  schrieb:

ich habe den Workarround mittels Proxy nun als "Lösung" oben angepinnt, mit dem Ziel, dass sie für Neueinstieger für die diese langt einfacher zu finden ist.


das ist schon mal besser...allerdings beleuchtet das eben nicht die Sache von mehreren Seiten, so dass man sich immer noch verschaukelt vorkommt, wenn man mit dem Thread anfängt. Ich hatte ja schon Vorschläge gemacht, was da noch verlinkt werden sollte.
Vor allem gehört die Ausaage noch hinein, dass es eben keine richtige Lösung ist und dass die Sache nicht abgehakt ist sondern (laut Auskunft) noch dran gearbeitet wird


@hg42  schrieb:
allerdings beleuchtet das eben nicht die Sache von mehreren Seiten, so dass man sich immer noch verschaukelt vorkommt, wenn man mit dem Thread anfängt. 
Vor allem gehört die Ausaage noch hinein, dass es eben keine richtige Lösung ist und dass die Sache nicht abgehakt ist sondern (laut Auskunft) noch dran gearbeitet wird

Das ist aber auch nicht an mir als Telekom Kunde - wie du auch - dies zu tun


@Stefan  schrieb:

@hg42  schrieb:

Heute habe ich übrigens 52x eine IP aus dem Bereich 84.166.*.* bekommen, nur die erste war 84.166.166.*
Das scheint mir fast Absicht zu sein. 

Klar, bei jedem Anmeldevorgang poppt bei einem Telekom Mitarbeiter ein Fenster auf an dem er entscheiden kann 

"Schnelles Peering" oder "den f... wir jetzt" Zwinkernd


Menno...es ist genauso Absicht, wenn jemand einen bestimmten Algorithmus gewählt oder eingestellt hat.
Das ganze Routing basiert ja auf so etwas...
Es wäre ja sinnvoll, wenn man in kurzer Zeit ein Neu-Verbinden anstößt, dass dann mal ein anderes Netz genommen wird.
Ich denke schon dass es da balancing-Algorithmen usw. gibt.

Damit das klar ist, ich meine damit natürlich nicht, dass jemand mich absichtlich so behandelt.
Mir scheint gewisse Leute hier (ich nenn sie mal die Telekom-Verteidiger, das ist zumindest der Eindruck der entsteht, ob gerechtfertigt oder nicht) sind da ein bisschen zu empfindlich.

Es wird einem hier und da vorgeworfen, etwas Böses zu sagen, wenn man eine vielleicht nicht ganz so 100% durchinformierte Kritik äußert und sie sich vielleicht ein wenig nach Verschwörungstheorie anhört.

Es ist aber nunmal so, dass viele hier vorher mit Call-Center und Co. zu tun hatten. Da kann einem schon mal leicht der Kragen platzen.
Man hangelt sich da eine kleine Ewigkeit von einer angeblichen Lösung zur nächsten, und letztlich sind die meistens der Meinung, das Problem liegt beim Kunden. Irgendwann kommt dann auch, dass man ja einen eigenen Router verwendet.
Wenn man hartnäckig bleibt und sich nicht runterbuttern lässt, dann wird am Ende aufgelegt und die Störung z.B. als behoben markiert.
Man muss auch jedes Mal von vorne anfangen und erst Mal nachweisen, dass das Problem überhaupt am Routing liegt.

Tut mir leid, diese strukturelle Abschottung des Konzerns (egal ob GmbH oder AG oder was...) empfinde ich auch als Gewalt.
Es wäre ja nur als eine Vorgehensweise durchaus möglich, in den Datenbanken github/AWS einzutragen, zusammen mit einem Hinweis, dass es ein gültiges Problem ist und einen Link. Auf meine Störungsmeldung hätte ich eigentlich sogar nur eine E-Mail mit dem Link hier erhalten können, statt mich 30min mit der Hotline rumzuschlagen (zu dem Zeitpunkt wusste ich noch gar nicht, dass es telekomhilft überhaupt gibt, warum wird das nicht leicht zugänglich gemacht, wenn man eine Störung hat?).


@hg42  schrieb:
Tut mir leid, diese strukturelle Abschottung des Konzerns (egal ob GmbH oder AG oder was...) empfinde ich auch als Gewalt.
Es wäre ja nur als eine Vorgehensweise durchaus möglich, in den Datenbanken github/AWS einzutragen, zusammen mit einem Hinweis, dass es ein gültiges Problem ist und einen Link. Auf meine Störungsmeldung hätte ich eigentlich sogar nur eine E-Mail mit dem Link hier erhalten können, statt mich 30min mit der Hotline rumzuschlagen (zu dem Zeitpunkt wusste ich noch gar nicht, dass es telekomhilft überhaupt gibt, warum wird das nicht leicht zugänglich gemacht, wenn man eine Störung hat?).


Da kann ich dir nur zustimmen.

Mit der internen Kommunikation hat es das Kommunikationsunternehmen Telekom nicht so. Ist ja nicht nur so dass damit Frust beim Kunden erzeugt wird, durch die Belastung der Call Center mit dieser Problematik werden ja auch Ressourcen verschwendet die in der aktuellen Lage, Shops geschlossen, dringend benötigt werden. Und damit den Frust bei Kunden mit anderen Problemen zusätzlich erhöhen.

 


Genau, und wenn alle gleich langsam sind wird die Netzneutralität nicht beeinträchtigt, alles klar.

tja, es kann sein, dass Neutralität ihren Preis hat, genau wie Demokratie ihren Preis hat (deswegen ist sie z.B. auch anfällig gegen Angriffe von autokratisch organisierten Strukturen, da die nicht erst diskutieren müssen).

Wir reden hier aber von einer Reduktion auf 1/100 bis runter auf 1/1000 nicht nur von 1/2 oder so.

Eigentlich denke ich, dass überhaupt keine Route im Internat heutzutage soooooo langsam sein sollte.
Es kann einfach gar nicht sein, dass ein paar Megabyte 3 Tage dauern soll (was der Auslöser für meine eigenen Nachforschungen war).
Ich bin überzeugt ich kann 10x nach Amerika und zurück routen und wäre immer noch schneller.

Und wir reden hier zudem nicht von einzelnen Fällen sondern einer ganzen (und ich glaube auch sehr großen) Gruppe von Usern, die den Zustand dauerhaft haben. Ich selbst bin ja noch glimpflich davon gekommen, weil ich den IP-Bereich noch wechseln kann und zwei riesige Bereiche habe, wo es gut läuft. Die meisten dieser User werden es noch gar nicht auf solche Problem zurückgeführt haben und lasten es vielleicht der Überlastung des Netzes an oder so...ich wette sonst wäre der Ansturm noch größer.

Das Abblitzen lassen an der Hotline-Front führt vermutlich nicht zu einer Eskalation, weil ja z.B. in meinem Fall die Störung angeblich gelöst wurde und ein Thread wie dieser hier erscheint auch in der Statistik als gelöst...ein vermutlich vorhandenes internes Ticketsystem hat vermutlich den Zustand, Warten auf Amazon...
Folglich wird nichts wirklich neues passieren, befürchte ich.

immerhin kannst Du aber einen Beitrag anpinnen...
ich denke wir sollten das hier mal selbst organisieren, weil es das Team ja nicht macht.
Ich hatte ja eine Beitragssammlung vorgeschlagen, das könne  wir gerne ergänzen oder drüber diskutieren was da noch reingehört.
Das ist jedenfalls weniger frustrierend für Dich, als jedesmal wieder etwas schon vorhandenes zu einem neuen User sagen zu müssen, was Dich ja offensichtlich aufregt (und was ich irgendwie auch verstehen kann).