Laufen schon in den niedrigsten Auflösungen nicht.

Laufen auch beide bei mir in 223XX mit VDSL50/Entertain nicht, zudem habe ich seit Tagen Probleme mit anderen Seiten, besonders auf Facebook laden Bilder und Videos extrem langsam oder gar nicht.

Danke für die Mühe, jkeil und Ulrich,

hier PLZ 44xxx.

Mittlerweile habe ich mir mit Wireshark die Streams angeschaut.
Bei den problematischen Streams geht's auch bei mir nach Indien:

orion:~ admin$ traceroute 182.79.251.15
traceroute to 182.79.251.15 (182.79.251.15), 64 hops max, 52 byte packets
1 fritz.box (192.168.22.1) 15.841 ms 1.590 ms 1.546 ms
2 217.0.116.123 (217.0.116.123) 18.656 ms 19.534 ms 18.150 ms
3 87.186.242.198 (87.186.242.198) 21.691 ms
87.186.242.206 (87.186.242.206) 21.965 ms
87.186.242.194 (87.186.242.194) 22.216 ms
4 * 217.239.37.173 (217.239.37.173) 731.921 ms 614.373 ms
5 80.150.168.102 (80.150.168.102) 614.156 ms 368.232 ms 553.139 ms
6 aes-static-017.37.144.59.airtel.in (59.144.37.17) 614.987 ms *
182.79.252.70 (182.79.252.70) 835.479 ms
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
^C

In diesem Zusammenhang kursieren seit einigen Tages im Ausland Beiträge, die CDNs für die ganze Misere verantwortlich machen. Da die IP-Adress-Bereiche der dort ermittelten CDNs für Deutschland nicht passen, bin ich einfach mal den Tipps gefolgt und habe die indische CDN -Server-Farm eingesetzt:

orion:~ admin$ sudo ipfw list
Password:
65535 allow ip from any to any
orion:~ admin$ sudo ipfw add reject src-ip 182.79.251.0/24 in
00100 reject ip from 182.79.251.0/24 to any in

Nun wird nach einigen Sekunden Wartezeit auf einen anderen Streaming-Server zurückgegriffen, der zügig arbeitet/angebunden ist:

orion:~ admin$ traceroute 208.117.236.18
traceroute to 208.117.236.18 (208.117.236.18), 64 hops max, 52 byte packets
1 fritz.box (192.168.22.1) 2.340 ms 0.893 ms 0.751 ms
2 217.0.116.123 (217.0.116.123) 25.360 ms 19.970 ms 18.911 ms
3 87.186.242.202 (87.186.242.202) 21.372 ms
87.186.242.198 (87.186.242.198) 20.818 ms
87.186.242.206 (87.186.242.206) 21.804 ms
4 f-ed5-i.f.de.net.dtag.de (217.5.95.54) 23.570 ms 23.782 ms 23.692 ms
5 62.157.249.50 (62.157.249.50) 23.403 ms 25.775 ms 55.510 ms
6 xe-4-0-1.par20.ip4.tinet.net (141.136.108.77) 35.934 ms
xe-8-2-1.par20.ip4.tinet.net (141.136.108.89) 37.525 ms
xe-4-0-1.par20.ip4.tinet.net (141.136.108.77) 35.480 ms
7 google-france-gw.ip4.tinet.net (77.67.67.150) 48.273 ms 34.333 ms 121.465 ms
8 208.117.236.18 (208.117.236.18) 34.881 ms 33.418 ms 33.839 ms
orion:~ admin$

Tja, damit bekomme ich temporär meinen iMac zum Laufen. Das YoutTube-Turbo-Plugin für Firefox hatte auch funktioniert, ist momentan aber ausgeschaltet. Ich möchte verstehen, was da passiert.
Damit bekomme ich aber nur einen Rechner zum Laufen, vor allem nicht die Smartphones. Deshalb greifen DD-WRT-Benutzer in ihrem Router über Linux in die Firewall ein.
Geht aber nicht bei meiner FRITZ!Box, schon gar nicht bei Speedports.

Soweit erstmal ohne Wertung, wer diesen Mist verzapft hat.

Danke auch an die anderen, die sich mittlerweile zurückgeldet haben!

Probiert doch mal bitte folgendes aus: http://mitchribar.com/2013/02/how-to-stop-youtube-sucking-windows-guide/

Damit blockt ihr das CDN und bekommt alles direkt von YouTube. Bei mir funktioniert es echt super.


Mit freundlichen Grüßen

Tobias Timpe

Schönen guten Abend,

ein einziges Trauerspiel mit Call & Surf Comfort IP Speed (VDSL 25) im Raum München, PLZ 85386. Verschiedene Speed-Tests ergeben Einbußen bis zu 50 %. Speziell YouTube lädt selbst in der niedrigsten Auflösung nur extrem schleppend und stockt trotzdem noch.

Mein Anruf bei der Störungsstelle am gestrigen Abend ergab wie erwartet nichts. Es kann keine Einschränkung an meinem Anschluss festgestellt werden, etc. pp. Warum es mit aktivem VPN über die Firma allerdings läuft, konnte mir der Kollege selbstverständlich nicht erklären.

Ich hoffe hier wird sehr bald etwas unternommen, sonst kann auch ich mir diese Premium-Preise beim besten Willen nicht länger rechtfertigen! Man achte allein auf das Alter dieses Threads.


Bis dahin ein kleiner Workaround aus der eigenen Trickkiste:

Folgendes Script habe ich als "proxy.pac" auf dem Homeserver abgelegt und bei sämtlichen Geräten (MacBook, iPad, iPhone,..) zur automatischen Proxy-Konfiguration eingetragen. Funktioniert einwandfrei, sogar fast mit vollen 25 MBit/s.

function FindProxyForURL(url, host) {
if (isInNet(host, "127.0.0.0", "255.0.0.0")) {
return "DIRECT";
}
if (isInNet(host, "10.0.0.0", "255.0.0.0")) {
return "DIRECT";
}
if (isInNet(host, "172.16.0.0", "255.240.0.0")) {
return "DIRECT";
}
if (isInNet(host, "192.168.0.0", "255.255.0.0")) {
return "DIRECT";
}
return "PROXY www-proxy.t-online.de:80; DIRECT";
}

Wem das zu technisch ist, kann auch einfach nur die URL "www-proxy.t-online.de" mit Port 80 als Proxy in seinem Browser eintragen.


Grüße aus München,

Daniel

Hier kommen weitere Erklärungen:
https://news.ycombinator.com/item?id=5276772

Und jetzt kommt die Wertung:
Was hat uns die Telekom hier erklärt?

Sie hätten die Peering -Kapazitäten zu Google verdreifacht.
Google würde alles aufhalten. Sie - die Telekom - müsste auf Google warten.

Was kommt jetzt raus?
Die Telekom greift auf CDNs zurück. Die Streams kommen gar nicht direkt von Google, sondern z.Z. von katastrophalen Server-Farmen in Indien, die zum Cachen der Videos dienen.

Davon war bisher seitens der Telekom nie die Rede, sondern von Peering mit Google.

Aber immer schön Beschäftigungstherapie mit den Leuten hier machen, um die Ursachen zu ergründen. eMails verschicken an die Telekom. Wochenlang angeblich Analyse. Ohne Ergebnisse. Jetzt kommt so etwas zu Tage.

Und die Name-Server der Telekom jubeln uns das CDN unter. Nicht allen Kunden. Die DN Server sind ja regional unterschiedlich. Einige müssen halt dran glauben.

Danke Telekom für diesen "offenen und ehrlichen" Umgang mit euren zahlenden Kunden.

Was kommt jetzt raus? Die Telekom greift auf CDNs zurück. Die Streams kommen gar nicht direkt von Google, sondern z.Z. von katastrophalen Server-Farmen in Indien, die zum Cachen der Videos dienen.

Da bin ich mir aber nicht so sicher ob da die Telekom für verantwortlich ist.
Google / Youtube dürfte das CDN aufgebaut / installiert haben. Nutzen sie ja
für diverse Google Dienste, und eben auch für Youtube. Und vermutlich gibt es
da auch den ein oder anderen CDN Server der innerhalb des Telekom Netzes steht,
oder zumindest recht gut aus dem Telekomnetz erreichbar ist.

Warum nun für bestimmte Telekom Benutzer ein völlig ungeeigneter CDN Server,
dazu noch in einem anderen Kontinent, für Video Streams ausgewählt wird,
das ist natürlich eine spannende Frage. Aber auch hier muss nicht die
Telekom Schuld haben.

Tja, was tun, damit alles wieder funktioniert?

und ich dachte schon ich hätte meine firewall und weiss ich noch was falsch eingestellt...also ist es doch die telekom,wie ich zuerst dachte...hier sind binnen kurzer zeit 26 seiten aufgelaufen...das ist eine sauerei.
und ich lasse mir noch VDSL50 aufschwatzen...jetzt sitzt man da und kann nicht mal stinknormale videos anschauen.

und downloads braucht man nicht probieren...lädt mit 45 kb/s ... unfassbar!!!

zu erreichen ist auch niemand...nach 20 minuten warteschleife einfach rausgekickt.

und ich dachte schon ich hätte meine firewall und weiss ich noch was falsch eingestellt...also ist es doch die telekom,wie ich zuerst dachte...hier sind binnen kurzer zeit 26 seiten aufgelaufen...das ist eine sauerei. und ich lasse mir noch VDSL50 aufschwatzen...jetzt sitzt man da und kann nicht mal stinknormale videos anschauen. und downloads braucht man nicht probieren...lädt mit 45 kb/s ... unfassbar!!! zu erreichen ist auch niemand...nach 20 minuten warteschleife einfach rausgekickt.

Du kannst normalerweise mit VDSL 50 keine 45 KB/s Download´s haben. Oder meinst Du die Downloadrate der Videos auf YouTube?

Solltest Du solche 45 KB/s Downloads auch außerhalb von YouTube haben, hast Du entweder kein VDSL, sondern DSL 384, oder Du hast ne Störung -> zu geringen Datendurchsatz.

Grüße.