Gelöst
VDSL2 MagentaZuhause L - Vectoring aber leider kein G.INP geschaltet.
vor 6 Jahren
Guten Tag liebes Telekom-Hilft Team,
auch hier möchte ich gerne einmal mein Anliegen / Problem schildern und nett darum beten, dieses so schnellstmöglich
weiterzuleiten / in die Wege zu leiten.
________________________________________________________________________
Wir waren mit unserem Anschluss immer zufrieden gewesen (16k mit fastpath) und als dann die
Umschaltung auch endlich bei uns auf IP umgestellt wurde war schnell die Ernüchterung groß -
Schwankungen im Download und aus dem vorherhigen schönen 19-25ms Ping war nur ein 48-55ms
Ping geworden (für Gaming tatsächlich sehr unangenehm spürbar auch wenn 48-55ms eigentlich
Meckern auf hohem Niveau ist ;-)).
Viele Gespräche hin und her geführt mit der Hotline telefoniert etc. nichts ergab sich - bis dann bei
einer Störungsbehebung uns ein Techniker fragte wieso wir denn nicht auf 100k wechseln würden
mit Hilfe des Regio Services - da würde man den Ping auch wieder drastisch nach unten bringen
wenn nicht sogar noch verbessern mit Hilfe von Vectoring + G.INP Schaltung. Gesagt - getan sofort
wurde Magenta L bestellt und nach einem Monat sitze ich hier freu mich das alles klappt ohne große
Komplikationen und muss dann doch leider ernüchternd feststellen, dass sich am Ping trotz Schaltung
leider nichts getan hat der Traum war geplatzt dachte ich aber die Ursache dann am Ende des Tages doch
durch Hilfe eines Fritzbox runters gefunden - denn bei mir ist G.INP gar nicht geschaltet / an. Alle meiner
Kollegen mit Magenta L haben in Ihrem Status G.INP an und Latenz "fast" nur leider ist das bei mir nicht
der Fall (verlgieche Fotos).
Hier also die Bitte, dass man mir ebenfalls G.INP anschaltet(?) - Gruß !:)
PS: Bekomme auch von vielen Mitarbeitern die Bestätigung, dass bei VDSL Vectoring Anschlüssen
G.INP generell immer geschaltet / an sein sollte und Sie das komisch finden. Also was ist der nächste
Schritt damit noch dieser kleine "Fehler" behoben wird und wir restlos glücklich sein können?
1153
20
Akzeptierte Lösung
akzeptiert von
vor 6 Jahren
Die Laufzeiten sind aus anderen Gründen kürzer. Aber nicht wegen G.INP. Die Natur einer Fehlerkorrektur SIND höhere Laufzeiten. Wenn man im Internet ein wenig sucht, findet man auch berichte darüber, dass die Telekom sich auch von G.INP trennt.
Die Natur einer Fehlerkorrektur SIND höhere Laufzeiten.
Wenn man im Internet ein wenig sucht, findet man auch berichte darüber, dass die Telekom sich auch von G.INP trennt.
Bei G.INP werden dagegen fehlerhafte Frames erneut angefordert (hier gibt es im Gegensatz zu INP auch nur on/off) und kostet im Gegensatz zu INP auch keine zusätzliche Bandbreite (zumindest solange keine fehlerhaften Frames auftauchen und wenn dann auch nur in dem Umfang wie für die erneute Übertragung erforderlich ist) während eine höhere INP-Stufe permanent Bandbreite kostet, zumindest wenn man sich am Ziel-SNR bewegt (was bei dir jedoch nicht der Fall ist, da macht eine höhere INP-Stufe also durchaus Sinn auch wenn dadurch der SNR/die Leitungskapazität sinkt um u.a. z.B. potentielle FEC/HEC/CRC-Fehler zu vermeiden bzw. deren Anzahl zu reduzieren und/oder auch die DSL-Verbindung allgemein stabiler für Impulsstörungen zu machen).
Bei einer problematischen/instabilen Leitung mit Sync am Ziel-SNR hat man somit z.B. die Wahl die DSL-Verbindung mit INP bzw. einer höheren INP-Stufe auf Kosten der Bandbreite zu stabilisieren oder (ebenfalls auf Kosten der Bandbreite) einen höheren Ziel-SNR festzulegen. Man kann natürlich auch beides kombinieren, also entweder INP oder erhöhter Ziel-SNR oder auch beides zusammen.
I"Vergleich dazu hat man bei aktivem G.INP die Möglichkeit auf das (bzgl. Latenz langsamere) Interleaving als Korrekturverfahren (damit nicht jeder FEC-Fehler als CRC-Fehler durchschlägt) zu verzichten und somit Fastpath bzw. Interleavingtiefe=0 zu nutzen um somit die Latenz auf der DSL-Verbindung wesentlich zu minimieren. Im Gegensatz zum klassischen Fastpath, womit die CRC-Fehlerwahrscheinlichkeit enorm steigen würde gegenüber Interleaving, ist die wiederholte Anforderung von fehlerhaft übertragenen Informationen wesentlich effektiver/schneller als beim klassischen CRC da sie bei G.INP eine Ebene tiefer ansetzt (es kommt also mit G.INP gar nicht erst zu den "gefürchteten" bzw. "zeitraubenden" CRC-Fehlern die man früher mit Interleaving versucht hat zu reduzieren)"
Und genau so haben mir das auch 2 Telekom Techniker gesagt. Das G.INP abgeschaltet werden soll stimmt ebenfalls nicht, das hat mir eine Dame gestern bestätigt, sie weiß nur nicht welche Vorraussetzungen man erfüllen muss.
0
Uneingeloggter Nutzer
Antwort
von