ForumAndy schrieb:
Manche Leute sind doch echt nur zum stänkern in Foren unterwegs.
Nur als kleiner Tipp:
@blastinMot ist einer der kompetentesten Leute hier im Forum zum Thema VDSL, insofern solltest Du mit Deinem Urteil vielleicht etwas zurückhaltend sein.
Ich kann seine Reaktion verstehen, wenn man viele Jahre in Foren wie diesem oder z.B. bei Telekom Hilft unterwegs ist, dann hat man schon hunderte von Threads dieser Art, wo Leute Fehlerzähler, Spektren und ähnliches akribisch verfolgen.
Ich bin auch langjähriger VDSL Kunde, und war in diesem Rabbit Hole auch schon.
Meine Erfahrung:
VDSL Leitungen schwanken in ihrer Qualität, unterschiedliche Modems haben durchaus auch Auswirkungen, genauso leider auch die Modems der Nachbarn (weil sie im gleichen Vectoring Verbund sind).
Solange man keine ständigen Resyncs oder massive Probleme hat, einfach alles so lassen. Meine Leitung macht z.B. 1-3 mal im Jahr aus nicht so ganz geklärten Gründen Probleme. Meistens drosselt dann ASSIA für 4-6 Wochen ein wenig (meist auf 100000/37000) und damit ist es dann wieder stabil. Ja, die Drosselung hat mich früher genervt, aber eigentlich fällt der Unterschied in Wirklichkeit nicht auf.
Die Fritzboxen zeigen die FECs ja im Standard nicht mehr an, aber die durch G.INP korrigierten (bzw. nicht korrigierten) DTUs. Wenn man da regelmäßig viele hat, dann wird der Durchsatz geringer (G.INP korrigiert durch neu senden der DTU). Das kann man an der „minimalen effektiven Datenrate“ erkennen. Ist die erkennbar niedriger als die aktuelle Datenrate, deutet das auf eine relevantes Fehlerereignis hin. Aber es sagt nichts über die Häufigkeit aus.
Mal ein Hinweis zu den Werten: Wenn man eine DTU Größe von 4096 Bit annimmt (ich weiß leider nicht welche Größe die Telekom verwendet, die G.INP/G.998.4 erlaubt verschiedene Größen), dann werden pro Minute ca. 1,4 Mio DTUs übertragen. D.h selbst 1000 korrigierte DTUs / Minute merkst Du kaum.
Fehler die unkorrigiert bis auf die TCP/IP Ebene „durchschlagen“, merkt man hingegen schon in geringer Zahl sehr deutlich, da dass TCP Protokoll daraufhin sein Übertragungsfenster ( Anzahl Bytes die ohne ohne auf eine Bestätigung zu warten übertragen werden können) zurücksetzt, und das bremst ordentlich. Daher hat man sowas wie G.INP eingeführt.