vdsl 50 speed

[little_skunk]

Ok das sind ja tausend meinungsverschiedenheiten, aber wenn du mir nicht glauben willst ist mir doch egal. Ich bin auch kein Techniker und kann nur die kurze Version aufbringen.

Mir ist es auch egal ob du mir glaubst oder dem Telekomtechniker.

Wegen dem h264 Material, also HD wird zu 100% h264 gestreamt.
SD Material weiß ich nicht, denke aber mpeg2 mpeg4. Das wird aber bestimmt nicht so richtig sein.

Ja so in der Art dachte ich mir das auch. So und jetzt die Quizfrage. Warum lässt du dir vom Techniker etwas vom Pferd erzählen. Kannst du HD-TV empfangen? Das gibts nur im PayTV soweit ich weiß. Der Techniker sagt dir also sinngemäß. "Sie können kein Fastpath haben, da das nicht mit HD-TV funktioniert" und denkt sich dabei "auch wenn sie es garnicht empfangen können weil wir es nur gegen Bezahlung anbieten". Genau aus diesem Grund verstehe ich diese Begründung überhaupt nicht und selbst wenn müsste WOW genau die gleichen Probleme mit Fastpath haben wie der HD-TV Steam.

 

[firefox888]

Ja komplettes Bundle, 80 Euro im Monat mich interessierte auch nicht Fernsehen, haben wir nur gebucht weil wir noch satelit hatten.
Mich hat ganz einzig und allein interessiert wieso ich kein fastpath haben kann und die Antwort dazu habe ich gefunden, durch Foren und den Techniker.

Es funktioniert allgemein nicht, ich denke nicht das sich SD so groß von HD unterscheidet.
Außerdem verstehe ich nicht wie du ein Computerspiel jetzt mit Fernsehen auf IP TV Basis vergleichen kannst.

 

[little_skunk]

Hab im moment leider keine Zeit. Ich mach es kurz bevor ich in den Feierabend gehe.

Die Antwort des Technikers ist schwachsinn. Natürlich bekommst du mit Fastpath wie schon gesagt eine höhere Fehlerquote. Das kann (muss aber nicht) Auswirkungen auf zum Beispiel dein TV Stream haben. Wenn es Auswirkungen hat, dann aber auch auf Spiele wie WOW, da diese dank UDP ebenfalls Probleme mit zu viele verlorengegangen Datenpacketen hätte. Bei Radiosteams sieht es nicht anders aus obwohl da da natürlich Rechts hast. Stream ist nicht gleich Stream. Es gibt da ein paar Unterschiede.

 

[firefox888]

da diese dank UDP ebenfalls Probleme mit zu viele verlorengegangen Datenpacketen hätte.

Naja dann laagt es, die verbindung wird aber erst nach einer bestimmten Zeit, wo keine Packete mehr angekommen sind vollständig geschlossen.
Ich frage mich dann auch wieder ob jeder VDSL Kunde so ein Technikbasierter 1337 l33t uhaxxor Progamer ist und Computerspiele spielt oder einfach vernünftig ohne "Bildstörungen" was auch immer kommen wird fern will.

 

[okatomy]

interleaving beim telekom IPTV braucht man weil jeder CRC fehler der auf der DSL übertragung entsteht, in einem bildfehler (kurze pixelbildung) endet.

umso mehr interleaving tiefe man hat, umso mehr fehler kann man durch FEC (forward error correction) ausgleichen und somit verlust (CRC) vermeiden.

fehler auf der DSL übertragung sind normal, aber IPTV läuft fehlerfreier mit interleaving.
wenn beim surfen ein packet verloren geht (wir rede hier von packeten auf DSL ebene, nicht von TCP oder UDP) dann wird es halt neu angefordert und kommt 5ms später an.
beim IPTV mündet das aber direkt in bildfehler, denn das bild wartet keine 5ms.

EDIT:
ich denke was viele hier nicht verstehen: interleaving arbeitet nicht auf TCP/UDP ebene (OSI schicht 4) sondern auf OSI Modell schicht 2, genauso wie CSMA/CD bei ethernet verbindungen das bedeutet carrier sense multiple access/collision detection. bei DSL ist das gegenstück halt CRC, FEC und interleaving.

 

[infinity_dev]

fehler auf der DSL übertragung sind normal, aber IPTV läuft fehlerfreier mit interleaving.

Prinzipiell könnte man auch auf Interleaving des kompletten Anschlusses verzichten. Man könnte UDP-Pakete (wenig Overhead) mit interleavten Daten+Reed Solomon-Code darin nehmen. Dadurch wäre der Header zwar nicht mehr gegen Burst-Fehler geschützt, aber immerhin die Nutzdaten, was immer noch der weit größere Teil der Bits ist. Alternativ hätte die Telekom auch selbst ein Protokoll für IPTV stricken und es den Modems beibringen können, da es ja sowieso nur netzintern funktioniert.

wenn beim surfen ein packet verloren geht (wir rede hier von packeten auf DSL ebene, nicht von TCP oder UDP) dann wird es halt neu angefordert und kommt 5ms später an.

Meines Wissens nach sind bei DSL die Pakete so geschachtelt: Ethernet(PPPoE(IP(TCP/UDP))). Eventuell spielt noch ATM mit. Außer TCP hat aber keines der Protokolle Checksummen, folglich kann es eigentlich keine Retransmission vom Provider geben. Oder werden da solche Späße wie HDLC eingesetzt?

beim IPTV mündet das aber direkt in bildfehler, denn das bild wartet keine 5ms.

Dann müsste die Telekom aber sehr aggressives QoS fahren, sowohl netzintern als auch zum Kunden, wenn es keine Pufferung von wenigstens 1-2 Sekunden gibt.

 

[okatomy]

wie gesagt das interleaving bei DSL gehört zur bitübertragungsschicht wie CSMA/CD bei ethernet, solange das nicht verstanden wird hat eine diskussion keinen sinn^^

http://de.wikipedia.org/wiki/OSI-Modell

es geht auch ausdrücklich nicht um TCP/UPD packete die zu sichern sind/wären

TCP/UPD läuft auf schicht 4 ab:
http://de.wikipedia.org/wiki/OSI-Modell#Schicht_4_.E2.80.93_Transportschicht

es geht wie gesagt um die bits auf einer DSL strecke zwischen modem und DSLAM
und diese sind mit vielen prüfeinrichtungen gegen fehler gesichert: CRC, FEC in verbindung mit interleaving, HEC.

QoS ist natürlich das A und O, daswegen gibts ja die VLAN trennung (ID7 internet, ID8 IPTV) unter anderem auch.
das IPTV kommt aber mit nichten "aus dem internet" sondern von sehr regional stehenden servern, die ausschließlich dafür arbeiten. insofern ist die strecke die ein IP-TV IP-Packet zurücklegt sehr gering, und eine Pufferung nach versand gibs es nicht.

die größte gefahr für ein IPTV packet ist also eine fehlerbehaftete DSL verbindung, bei der übertragungsfehler direkt auf bitübertragungsschicht entstehen, weit von TCP/IP entfernt.

überlege mal: TCP/IP läuft über: enternet, DSL, koaxialkabel, glasfaser, DVB-S(satellit) ja sogar mit analogmodem (langsam).

hier gehts um techniken die erst ein TCP packet oder jedes beliebige andere, fehlerfrei über die kupferleitung befördern kann, dazu gehört interleaving.

P.S. stelle dir die bildfehler so vor wie die pixel/artefakt bildung bei satelliten-tv bei gewitter. auch hier entstehen übertragungsfehler, das übertragungsverfahren heißt DVB-S und nicht DSL. die übertragung heißt hier broadcast, fehler die auf der übertragung entstehen münden unmittelbar in bildfehler, packete neu anfordern kann man nicht. genauso ist es beim IP-TV multicast. der multicast ist für alle kunden am server der gleiche, dashalb zeitkritisch.

webradio, videostraming, ist alles unicast hier wirst du keine probleme durch verlorgen gegangene packete haben, egal auf wecher Schicht des OSI modell sie verloren gehen, sie werden von ihr (der schicht) neu angefordert. auch wenn man gestörtes IPTV hat, bedingt durch einefehlerhafte DSL übertragung, ist z.b. der video streaming dienst für spielfilme, genannt vieoload, auf dem selben receiver ohne bildstörungen zu nutzen, da unicast.

 

[little_skunk]

Das mit den Osi-Schichten ist schon klar. Es kommt aber so oder so immer zu ein paar Packetverlusten. Aus diesem Grund ist Interleaving nicht die einziege Absicherung sondern es gibt in den darüber liegenden Schichten ebenfalls Absicherungsmaßnahmen. Die Frage ist, ob man mit Fastpath oder sogar ganz deaktivierten Interleaving und geeigneten anderen Absicherungen nicht das gleiche Ergebnis erziehlen kann.

Ob Unicast oder Multicast ist völlig egal. Entscheidend ist, ob der Server verloren gegangene Packete erneut versendet. Dafür gibt es diverse Möglichkeiten. Zum Beispiel kann der Server einfach alle Daten oder zumindestens die wichtigen Daten Zeitversetzt doppelt schicken. Das wäre auch bei Multicast möglich. Egal ob TV Steam oder Radio Stream sie haben alle ein Problem. Die Bandbreite des Servers. Jedes erneut zu versende Packet bedeutet zustäzliche Kosten. Desshalb verzichtet Telekom darauf aber einige andere Streams eben auch. Unter anderem sind auch einige Radiostreams davon betroffen.

Ich wiederhole es gern nochmal. Mir geht es nicht um sinn oder unsinn von Interleaving. Mir geht es um die Begründung des Telekomtechnikers warum Fastpath angeblich nicht möglich sein sollte. Der Hauptgrund warum ich es anzweifel ist einfach. Bei dem einen funktioniert noch alles mit Fastpath beim nächsten wiederum nicht. Warum also nicht wenigstens mal versuchen? Der Techniker tut gerade so als ob mit Fastpath alles funktioniert nur der TV Stream nicht mehr. Die Wahrheit ist aber, dass man bei TV Stream vermutlich noch als erstes die Folgen von Fastpath sieht und sich beschweren würde. Die Bildfehler sind aber nur die Folgen. Der Grund für diese Fehler sind zu viele verlorengegangene Datenpackete und das betrifft dann aber eben auch jede andere Anwendung, die in den höheren OSI Schichten nicht abgesichert ist. Zum Beispiel würde WoW vermutlich anfangen zu laggen. Also stellt sich mir die Frage warum die Telekom nicht einfach mal testweise Fastpath aktiviert und dem Kunden erklärt, was das für Folgen haben kann und sollten diese Folgen eintreten, muss man Fastpath eben wieder deaktiveren. Bei vielen Kunden dürfte Fastpath aber keine Auswirkung auf den TV Stream haben. Fastpath bedeutet ja nur, dass Interleaving runtergeschraubt nicht aber ganz deaktiviert wird.

So und nun wünsche euch ein schönes Wochenende. Das schöne Wetter ruft

 

[firefox888]

Du hast es immer noch nicht verstanden.
okatomy hat genau das was ich versucht habe zu erklären noch einmal richtig deutlich gemacht und du versuchst hier weiterhin alles auf die Telekom zu schieben. Es ist nunmal wie es ist und niemand will Bildfehler haben. Klar sie hätten es auch anders machen können (traffic ist eher nicht das Problem laut Andreas,Telekom Mitarbeiter)
Aber wieso sollte man es anders machen für die paar tausend freaks die meinen sie würden einen unterschied zwischen 15 und 30ms merken?
Da muss ich selbst als QDSL Veteran passen.
Es gibt keinen unterschied beim Recoilverhalten, das ist reines placebo verursacht durch die "fehlerhafte" Clientberechnung des Spieles.

Bei wem funktioniert denn VDSL IP TV mit fastpath?? Es gibt imo keinen der das hat und wenn dann unoffiziell weil er evtl. kontakte hat und die das einfach mal ausprobieren wollten.
Wow fängt eigentlich erst dann an zu laagen, wenn extermer packet loss besteht und das ist aber nicht der fall, fals die Leitung vernünftig mit fastpath läuft und sie nicht schon am äußerstem Limit rennt.
Bei live-fern sieht man die Folgen einfach direkt und das kannst du auch nicht bestreiten oder hast du das schon alles gesehen??

Bei der Telekom ist immer interleaving aktiviert, aber wie geschrieben reicht dieses low profil nicht um Daten rechtzeitig neu anzufordern.
Arcor und QSC schalten komplett interleaving aus, ich kann mich hier auch nur auf die Profile beziehen Telekom fastpath 1/1 Arcor und QSC 0/0 somit hat man bei der telekom immer einen höheren Ping von 2ms.

Dir wurde hier alles klar gemacht und du versuchst immer noch alles zu bestreiten und auf deinen komischen Link zu verweisen, den ich doch mal durchlesen sollte? Wie ich auch schon angedeutet habe und okatomy noch einmal bestätigt habe ist TCP/UDP erst einmal nebensache.

 

[little_skunk]

Du hast es immer noch nicht verstanden.
okatomy hat genau das was ich versucht habe zu erklären noch einmal richtig deutlich gemacht und du versuchst hier weiterhin alles auf die Telekom zu schieben. Es ist nunmal wie es ist und niemand will Bildfehler haben. Klar sie hätten es auch anders machen können (traffic ist eher nicht das Problem laut Andreas,Telekom Mitarbeiter)

Was schieben ich denn bitte auf die Telekom? Alle Provider sind doch in diesem Punkt gleich. Am Telefon sagen sie das was der Kunde hören will. In deinem Fall sagte der Techniker, dass Fastpath nicht ginge, weil das zu Bildfehler füren würde und, dass es ohne den TV Stream gehen würde. Den 1. Teil bestreite ich nicht. Es kann zu Bildfehler füren aber der 2. Teil ist schwachsinn. Wenn es zu Bildfehlern kommt, macht auch Fastpath ohne den TV Stream keinen Sinn. Das ist keine Kritik an Telekom. Jeder andere Techniker hätte genauso gehandelt damit der Kunde ruhe gibt. Ist genauso wie mit Mediamarktverkäufern. Da ist alles erlaubt solange der Kunde zahlt.

Aber wieso sollte man es anders machen für die paar tausend freaks die meinen sie würden einen unterschied zwischen 15 und 30ms merken?

Habe ich das jemals behauptet?

Bei wem funktioniert denn VDSL IP TV mit fastpath?? Es gibt imo keinen der das hat und wenn dann unoffiziell weil er evtl. kontakte hat und die das einfach mal ausprobieren wollten.

Die Frage, die ich gestellt habe ist eine andere. Gibt es jemanden, bei dem Fastpath mit TV Stream nicht funktioniert aber ohne TV Stream schon? Genau das hat der Telekomtechniker behauptet oder nicht? Offiziell gibt es dazu natürlich auch keine Antwort.

Wow fängt eigentlich erst dann an zu laagen, wenn extermer packet loss besteht und das ist aber nicht der fall, fals die Leitung vernünftig mit fastpath läuft und sie nicht schon am äußerstem Limit rennt.

Wieviel Packete sind nötig um von extremen Packetverlust zu sprechen? Packetverlust hast du so oder so immer. Jede Anwendung verkraftet unterschiedlich viele verlorengegangene Packete bevor der Benutzer davon etwas merkt. Ich habe WoW lediglich als Beispiel genommen, das du kennst. Die Frage ist nur noch wieviel Packetverluste nötig sind, damit es zu lags kommt und wieviel Packetverluste darüber hinaus noch nötig sind, damit der Benutzer es überhaupt mitbekommt. Mir geht es nicht mal um WoW. Es gibt genügend andere Programme. Es geht mir nur um die Auswirkungen von Fastpath, die alle Programme beeinflussen und nicht nur den TV Stream.

Bei der Telekom ist immer interleaving aktiviert, aber wie geschrieben reicht dieses low profil nicht um Daten rechtzeitig neu anzufordern.

Berichtige mich bitte wenn ich falsch liege aber selbst mit dem höchsten Profil hat Interleaving nicht mit Daten neu anfordern zu tun.

Arcor und QSC schalten komplett interleaving aus, ich kann mich hier auch nur auf die Profile beziehen Telekom fastpath 1/1 Arcor und QSC 0/0 somit hat man bei der telekom immer einen höheren Ping von 2ms.

Sind da irgendwelche Probleme bekannt? Wenn ja, dann frage ich mich warum der Techniker die Schuld auf den TV Stream schiebt und Arcor trotz fehlendem TV Stream Probleme hat. Wenn nein, dann frage ich mich ob sie auch den TV Stream fehlerfrei empfangen könnten. Oder anders gesagt: Würde ein Kunde, der wegen aktiviertem Fastpath Bildfehler sieht, sich auch ohne den TV Stream über die erhöhte Fehlerrate beschweren?

Dir wurde hier alles klar gemacht und du versuchst immer noch alles zu bestreiten und auf deinen komischen Link zu verweisen, den ich doch mal durchlesen sollte?

Bitte klär mich auf. Ich habe alles bestritten? Auf den komischen Link verweise ich schon lage nicht mehr. Ich finde es aber schade, dass du nicht bereit bist ihn durchzulesen.

Wie ich auch schon angedeutet habe und okatomy noch einmal bestätigt habe ist TCP/UDP erst einmal nebensache.

Habe ich jemals behauptet, dass Interleaving nebensache ist? Ich sage nur, dass eine erhöhte Fehlerrate, die Fastpath nunmal mitsichbringt, nicht nur auf den TV Stream auswirkungen hat.

Jetzt bleibe bitte bei dem was ich gesagt habe und interpretier nicht irgendwas hinein, was ich garnicht gesagt habe. Fastpath fürt zu einer erhöhten Fehlerrate und jede Anwendung, die sich auf den höheren OSI Schichten nicht dagegen absichert, kann mit der erhöhten Fehlerquote Probleme bekommen. Das schließt unter anderem den TV Stream ein aber eben auch andere Programme.

 

[firefox888]

Du verstehst es immer noch nicht, es geht doch um TV nicht um Anwendungen wie Spiele, wo sich das nicht bemerkbar macht.

Interleaving schickt keine packete neu, aber man kann es so verstehen.
Es werden die Daten sozusagen erst gecheckt, das sie auch angekommen sind und deshalb ist der Ping auch doppelt so hoch.
Einfach zu erklären es wird 2x die gleichen Daten geschickt. Das ist natürlich nicht so, aber die prozedur das erst eine bestätigung abgewartet wird ist so ziemlich damit zu vergleichen.

Arcor, Alice und 1und1 nutzen alle Unicast wie okatomy es mit dem Streaming von Videoload geschrieben hat.

Du schreibst immer das gleiche, meinst ich hätte keine ahnung und selbst vergleichst du Hunde mit Katzen.

Das packete bei spielen nicht verloren gehen hat unter anderem auch damit zu tun, das die packete sehr viel kleiner sind.
Vergleich mal ein Spiel wie Wow ca. 8kb/s down und up zusammen mit IP TV dort werden allein schon über 10mbit fürs Fernsehen reserviert und da ist es nur logisch das bei 2. die Chance das packete verloren gehen mit fastpath viel höher wäre.

//Du hast nicht behauptet, das du ein Progamer bist der einen niedrigen Ping braucht.
Aber du versuchst hier die ganze Zeit zu behaupten das die Telekom an allem Schuld ist, die keine ahnung hätten was sie machen und dem Armen User doch fastpath geschaltet werden soll...

 

[Jean Pernod]

Jungs... little_skunk sagt doch nur, dass es noch andere Möglichkeiten (der Fehler"vermeidung/umgang") als die Nutzung von Interleaving bei IPTV gibt. Als Beispiel nannte er dafür Verfahren auf höheren OSI-Schichten.
Damit wäre dann Fastpath + IPTV möglich und die Aussage des Telekom-MA (IPTV + Fastpath ist technisch nicht möglich) wäre widerlegt. End of Story.

 

[icebeer]

Jungs... little_skunk sagt doch nur, dass es noch andere Möglichkeiten (der Fehler"vermeidung/umgang") als die Nutzung von Interleaving bei IPTV gibt. Als Beispiel nannte er dafür Verfahren auf höheren OSI-Schichten.
Damit wäre dann Fastpath + IPTV möglich und die Aussage des Telekom-MA (IPTV + Fastpath ist technisch nicht möglich) wäre widerlegt. End of Story.

DANKE!

Mehr wollte ich ursprünglich auch nicht sagen. Dass es mit dem IP-TV nicht anders ginge als ohne Fastpath ist von einem tehnischen Standpunkt her schlichtweg falsch, egal wie oft das die hochkompetenten "Techniker" sagen und andere User es anschließend nachplappern.

 

[okatomy]

DANKE!

Mehr wollte ich ursprünglich auch nicht sagen. Dass es mit dem IP-TV nicht anders ginge als ohne Fastpath ist von einem tehnischen Standpunkt her schlichtweg falsch, egal wie oft das die hochkompetenten "Techniker" sagen und andere User es anschließend nachplappern.

dann stelle du erst mal so ein hochkomplexes IPTV system zusammen, da du ja offenbar weißt wie es "besser" geht.

und natürlich ist es technisch korrekt, dass mit dem aktuellen equipment das bei entertain auf kunden und netzseite eingesetzt wird, interleaving nötig ist.
warum hier als auf dem angeblich so inkompetenten techniker rumgeritten wird, ist ja lächerlich.

dann die gegenfrage: warum sollte man ein prima feherkorrekturverfahren der übertragungstechnik DSL abschalten und nicht nutzen, dafür ein viel mehr rechenleistung und resourcen benötgende pufferung und Ip-packet check auf kundenseite einführen, was um in echtzeit fehler auf IP ebene korrigieren kann, größere, teurere, mehr leistung verbrauchende media receiver auf kundenseite benötigt, nur damit 1% der kundschaft, ping-fanatiker; selbsternannte profi-gamer und CS-kiddys auf ihre kosten kommen?

richtig das macht gar keinen sinn, weder technisch noch wirtschaftlich.

 

[icebeer]

dann die gegenfrage: warum sollte man ein prima feherkorrekturverfahren der übertragungstechnik DSL abschalten und nicht nutzen, dafür ein viel mehr rechenleistung und resourcen benötgende pufferung und Ip-packet check auf kundenseite einführen, was um in echtzeit fehler auf IP ebene korrigieren kann, größere, teurere, mehr leistung verbrauchende media receiver auf kundenseite benötigt, nur damit 1% der kundschaft, ping-fanatiker; selbsternannte profi-gamer und CS-kiddys auf ihre kosten kommen?

richtig das macht gar keinen sinn, weder technisch noch wirtschaftlich.

Das war auch nie die Frage. Wenn Du eine Seite zurückblätterst wirst Du feststellen, dass mir nur die eben nochmals beschriebene Behauptung sauer aufgestoßen ist. Es gibt Leute, die sowas lesen (Interleaving ist bei IP-TV technisch nötig), das dann ohne zu hinterfragen glauben und blind weitererzählen. Das muss und sollte nicht sein. Nur daher brachte ich den Stein ins Rollen.

Mir persönlich geht das sonst sowas von hintenrum vorbei. 10 ms mehr Ping, "I couldn't care less" - und so wird es auch der Telefom bei der Planung des Netzes/Dienstes gegangen sein. Meiner Meinung nach kann man das durchaus vertreten.

 

[firefox888]

Jungs... little_skunk sagt doch nur

Das wurde schon auf der 1. Seite geklärt.
Nur anfangs wollten zwei User ja nur auf mir rumhacken von wegen sie würden alles besser wissen.
Der eine hat dann noch behauptet, das man keine andere Technik "benötigt"
Nachdem okatomy und anfangs meine Beiträge ein bisschen aufschluss gegeben haben hieß es dann blablabla und blalabla
Ich liebe sowelche User, die meinen alles rumzudrehen um immer im Recht zu sein.
Ganz am anfang ging es einfach nur darum das fastpath bei VDSL mit TV möglich ist oder nicht.
Das dann wieder so weit ausgeholt wird und überall das rumhacken und was man besser hätte machen können.
Freut euch doch lieber darum das bald überall Breitband verfügbar ist, weil Telekom und Resale mehr Geld fürs Buddeln ausgeben als VDSL weiter für die paar ultrahaxxxor gamer zu optimieren..

 

[infinity_dev]

Interleaving schickt keine packete neu, aber man kann es so verstehen.
Es werden die Daten sozusagen erst gecheckt, das sie auch angekommen sind und deshalb ist der Ping auch doppelt so hoch.
Einfach zu erklären es wird 2x die gleichen Daten geschickt. Das ist natürlich nicht so, aber die prozedur das erst eine bestätigung abgewartet wird ist so ziemlich damit zu vergleichen.

Deine Beschreibung von Interleaving triffts nicht so ganz. Es wird nicht gecheckt ob etwas angekommen ist, sondern es werden so lange Datenpakete gesammelt (z.B. 5), bis man diese ineinander verschränken, mit Checksumme und Recovery Informationen versehen kann. Wenn man die 5 Pakete+das Recovery Paket verschränkt hat, hat man ein großes Paket, das übertragen wird. Das Modem macht nach Prüfung der Checksumme und ggf. Recovery die Verschränkung rückgängig und schickt die ursprünglichen Pakete ins LAN. Durch dieses Aggregieren entsteht die zusätzliche Latenz. Eine perfekte Fehlerkorrektur ist Interleaving dabei aber auch nicht. Sind mehr Bits gekippt, als Recovery-Informationen vorhanden sind, sind alle Pakete im interleavten Paket für die Katz.

Nur als allgemeine Ergänzung.

 

[little_skunk]

Jungs... little_skunk sagt doch nur, dass es noch andere Möglichkeiten (der Fehler"vermeidung/umgang") als die Nutzung von Interleaving bei IPTV gibt. Als Beispiel nannte er dafür Verfahren auf höheren OSI-Schichten.
Damit wäre dann Fastpath + IPTV möglich und die Aussage des Telekom-MA (IPTV + Fastpath ist technisch nicht möglich) wäre widerlegt. End of Story.

So kann manes auch ausdrücken. Ich meinte aber eigentlich genau das Gegenteil. Ich behaupte, dass Fastpath unabhängig vom IP TV funktioniert oder zu Problemen führt. Es gibt diverse andere Programme, die genauso fehleranfällig sind wie IP TV. Deine Aussage würde ich aber auch voll und ganz unterschreiben.

Du verstehst es immer noch nicht, es geht doch um TV nicht um Anwendungen wie Spiele, wo sich das nicht bemerkbar macht.

Und du verstehst von meinem Text nur das was du verstehen willst und blendest den Rest aus. Hast du verlässliche Daten, die belegen, dass alle anderen Anwendung von den Problemen, die mit Fastpath verbunden sind, nicht betroffen sind? In keiner Weise? Trifft das auch auf alle TV und Radio Stream zu?

Interleaving schickt keine packete neu, aber man kann es so verstehen.
Es werden die Daten sozusagen erst gecheckt, das sie auch angekommen sind und deshalb ist der Ping auch doppelt so hoch.
Einfach zu erklären es wird 2x die gleichen Daten geschickt. Das ist natürlich nicht so, aber die prozedur das erst eine bestätigung abgewartet wird ist so ziemlich damit zu vergleichen.

Weiter oben wurde ja bereits erklärt, wie es wirklich funktioniert. Besser hätte ich es auch nicht schreiben können und möchte mich an dieser Stelle auch für die einfach verständliche Erklärung bedanken.
Interleaving schützt nicht zu 100% vor Datenverlust und wenn Daten verloren gehen, dann werden sie nicht neu angefordert. Jedenfalls nicht auf dieser OSI-Schicht. Das erneute Anfordern von Daten wird von höheren OSI Schichten übernommen. Es gibt aber Anwendungen, die genauso wie IP TV auch auf den höheren OSI Schichten Daten nicht erneut anfordern oder sich sonst irgendwie vor Datenverlust absichern.

Arcor, Alice und 1und1 nutzen alle Unicast wie okatomy es mit dem Streaming von Videoload geschrieben hat.

Wie ich bereits erklärt habe, hat Unicast erstmal keinen Unterschied zum Multicast, der hier jetzt eine Rolle spielt.

Du schreibst immer das gleiche, meinst ich hätte keine ahnung und selbst vergleichst du Hunde mit Katzen.

Tue ich das? Wo ist denn der Unterschied zwischen IP TV und einem Radiostream oder TV Stream, der nicht auf den höheren OSI Schichten abgesichert ist?

das die packete sehr viel kleiner sind.
Vergleich mal ein Spiel wie Wow ca. 8kb/s down und up zusammen mit IP TV dort werden allein schon über 10mbit fürs Fernsehen reserviert und da ist es nur logisch das bei 2. die Chance das packete verloren gehen mit fastpath viel höher wäre.

Die Packete sind annähernd gleich groß. Frag mich bitte nicht wie groß genau. Es gibt aber einen Unterschied in der Anzahl der Packete, die pro Minute versendet werden müssen. Diese liegen bei IP TV etwas höher.
BTW es sind keine 10Mbit/s sondern erheblich weniger. Für 720p Filme kommen bei 2h Film ca 4GB zusammen. Macht ca 0,5 MBit/s. Je nach Komprimierungsgrad könnten es auch mehr oder weniger sein. Die 10MBit wäre für einen unkomprimierten 1080p Film notwendig aber sowas verschickt niemand. Soweit ich weiß wird im TV sowieso nur 720p verschickt.

Aber du versuchst hier die ganze Zeit zu behaupten das die Telekom an allem Schuld ist, die keine ahnung hätten was sie machen und dem Armen User doch fastpath geschaltet werden soll...

Bitte ließ nochmal genau nach. Ich behaupte, dass der Techniker unabhängig von seiner Herkunft zum Teil unsinn erzählt hat. Ich betone nochmals, dass es keine Kritik an Telekom ist.

Das wurde schon auf der 1. Seite geklärt.
Nur anfangs wollten zwei User ja nur auf mir rumhacken von wegen sie würden alles besser wissen.
Der eine hat dann noch behauptet, das man keine andere Technik "benötigt"
Nachdem okatomy und anfangs meine Beiträge ein bisschen aufschluss gegeben haben hieß es dann blablabla und blalabla
Ich liebe sowelche User, die meinen alles rumzudrehen um immer im Recht zu sein.
Ganz am anfang ging es einfach nur darum das fastpath bei VDSL mit TV möglich ist oder nicht.
Das dann wieder so weit ausgeholt wird und überall das rumhacken und was man besser hätte machen können.
Freut euch doch lieber darum das bald überall Breitband verfügbar ist, weil Telekom und Resale mehr Geld fürs Buddeln ausgeben als VDSL weiter für die paar ultrahaxxxor gamer zu optimieren..

Ließ dir aber bitte nochmal dein eigenen Beitrag durch und überlege dir genau wer hier auf wem Rumhackt bzw beleidigt. Ließ dir vieleicht dazu auch nochmal den Anfang durch, wo du icebeer für dumm erklärt hast. Wie man in den Wald ruft, so schallt es aus ihm heraus...

---------- Beitrag hinzugefügt um 00:20 ---------- Vorheriger Beitrag war um 00:11 ----------

Ich machs dir mal einfach. Damit hat alles angefangen:

@ icebeer mit dieser Aussage hast du gezeigt, das du überhaupt keine ahnung hast.

Für eventuelle Beleidigungen meinerseits, möchte ich mich vorsichtshalber entschuldigen. Ich habe mich (hoffentlich) bemüht sachlich zu bleiben.

 

[firefox888]

Ich habe doch schon mehrere male geschrieben, das IP TV über multicast sendet dort werden die Daten nicht neu angefordert (jetzt ganz allein auf Telekoms Dienst bezogen)
Wenn du einen TV STREAM oder Radio STREAM hast, dann wird über unicast gesendet, es wird gebuffert, du merkst nichts davon wenn du Radio hörst und packete verloren gehen, im schlimmsten Fall läd er Daten nach und stoppt den Stream kurzzeitig oder du merkst nichts davon, der Stream geht ganz normal weiter aber du bist schon 100ms hinter der Liveausgabe.
Wie schon oft geschrieben können Daten erneut gesendet werden, bei Telekoms Dienst funktioniert das nicht.
Ob man jetzt Unicast oder Multicast nutzt, anscheinend funktioniert ja bei beiden Protokollen das nachschicken der Daten? ist dann ja erst einmal egal. Fakt ist, das bei der Telekom nunmal keine Daten nachgeschickt werden jetzt zum 10. mal.

Bei mir werden bei SD Material 3,5-4mbit/s reserviert und bei HD Material 9mbit/s.
Da ist sicherlich noch ein bisschen reserve mit drinn

Ich wüsste jetzt nicht wieso du icebeers aufpasser sein müsstest.
Im ersten Post von mir habe ich schon alles gesagt was überhaupt nötig gewesen wäre..

Zitat von firefox888 Beitrag anzeigen
Dein Ping wird niemals besser werden, da VDSL nur in Verbindung mit TV buchbar ist und dort interleaving im Download niemals ausgeschaltet werden kann (sonst würde es am Fernseher fals Daten mal nicht angekommen werden zu Bildfehlern/Buffern kommen)

icebeer meinte daraufhin

Schon mal den Unterschied zwischen TCP und UDP-Verbindungen erklärt bekommen? Auf Leitungsebene sichert man sowas aus daher auch nicht ab. Hast Du eine verlässliche Quelle, die das oben stehende bestätigen?

Ich wüsste nicht was der interleaving modus jetzt mit TCP oder UDP zu tun hat.

Daraufhin kam halt meine Aussage das er keine ahnung hat, hat er ja schon im Bezug auf den Bittorrent Tracker gezeigt. Was das keine ahnung haben bei mir im Bezug auf ihn nur noch verstärkt hat.

 

[little_skunk]

Ich habe doch schon mehrere male geschrieben, das IP TV über multicast sendet dort werden die Daten nicht neu angefordert (jetzt ganz allein auf Telekoms Dienst bezogen)
Wenn du einen TV STREAM oder Radio STREAM hast, dann wird über unicast gesendet, es wird gebuffert, du merkst nichts davon wenn du Radio hörst und packete verloren gehen, im schlimmsten Fall läd er Daten nach und stoppt den Stream kurzzeitig oder du merkst nichts davon, der Stream geht ganz normal weiter aber du bist schon 100ms hinter der Liveausgabe.
Wie schon oft geschrieben können Daten erneut gesendet werden, bei Telekoms Dienst funktioniert das nicht.
Ob man jetzt Unicast oder Multicast nutzt, anscheinend funktioniert ja bei beiden Protokollen das nachschicken der Daten? ist dann ja erst einmal egal. Fakt ist, das bei der Telekom nunmal keine Daten nachgeschickt werden jetzt zum 10. mal.

99% richtig. TV Streams und Radio Streams können Daten nachfordern. Sie müssen es aber nicht. Daraus folgt, dass es bei der riesigen Anzahl von TV Streams und Radio Streams eben auch welche gibt, die ebenfalls Bildfehler bzw Aussetzer hätten.
Es geht mir ja wie gesagt um die Aussage, dass ohne IP TV mit Fastpath überhaupt keine Probleme auftreten würden.

Den Puffer kannst du erstmal bei Seite lassen. Was hilft es dir, wenn du einen Film mit allen Übertragungsfehlern pufferst, wenn keine Daten neu angefordert werden. Der Puffer soll nur die unterschiedlichen Laufzeiten der Packete ausgleichen. Das neu Anfordern von Daten bedingt auch einen kleinen Puffer. Ein Puffer ist aber noch keine Garantie dafür, dass Daten auch wirklich neu angefordert werden!

Bei mir werden bei SD Material 3,5-4mbit/s reserviert und bei HD Material 9mbit/s.
Da ist sicherlich noch ein bisschen reserve mit drinn

Dann werden die Angaben vermutlich schon stimmen. Ich gehe nur von meinem lokalen Stream Server aus. Dort liegen die HD Filme komprimiert vor.

Ich wüsste jetzt nicht wieso du icebeers aufpasser sein müsstest.
Im ersten Post von mir habe ich schon alles gesagt was überhaupt nötig gewesen wäre..

Ich bin nicht sein Aufpasser. Ich schildere dir nur meine Sicht. Du bist meiner Meinung nach zuerst beleidigend geworden und nicht er. Er hat lediglich eine Frage gestellt, die du einfch mit Ja hättest beantworten können.

 

[Mario HD]

Lade mal durch "Rechtsklick und speichern unter" die Fette 1 GB Datei ! Da pendelt sich der Download gut ein und der Server ist irre schnell !

http://speedtest.netcologne.de/

Den upload kannste testen indem du eine 200 MB Datei hochlädst bei Rapidshare und die Zeit stoppst !