DLM Thread - Dynamic Line Management

[pufferueberlauf]

So, hier mal ein Versuch alle Informationionen zum Thema DLM zu buendeln.

Einleitung:
Eine Reihe von Nutzer haben hier und in anderen Foren berichtet, dass bei Ihren VDSL-Leitungen plötzlich die maximalen Grenzen im Vergleich zum "normalen" Ausgangszustand abgesenkt wurden, z.B. von 109.NNN Mbps auf exakt 100 Mbs oder noch geringer. Die Reaktion von Telekom Mitarbeitern im Telekom-Hilft Team und auf der Telekom Support Community deuten an, dass es sich dabei nicht um Fehler handelt sondern um ein bewusstes Eingreifen in die Leitungsparameter wohl mit dem Ziel die Leitung zu stabilisieren (wobei möglicherweise diese Stabilisierung fuer ein ganzes Kabel-Bündel durchgeführt wird, so dass auch solche Leitungen betroffen sein können, die selber gar keine Stabilitätsprobleme gezeigt haben). Es fehlt jedoch an wirklich belastbaren Aussagen zur Funktionsweise und zu den Schwellenwerten deren Unter- oder Überschreiten solche Eingriffe auslösen (und genau dieses Problem sollte dieser Thread behandeln).

In Großbritannien wird ein solches System unter dem Namen DLM bereits seit einigen Jahren eingesetzt und darum gibt es dort bereits mehr Informationen zu diesem Thema. Auch wenn nicht klar ist welches System die Telekom verwendet, ist davon auszugehen, dass es wohl sehr ähnlich zu den britischen Systemen sein wird. D.h. wie TCP auf verlorene Pakete mit einer Reduzierung der Geschwindigkeit reagiert, wird das System versuchen bei Störungen (die eine bestimmte Schwelle überschreiten) die Stabilität zu erhöhen, was in der Regel mit Erhöhung der Latenz und Reduzierung der Bandbreite einhergeht (welche den Kunden dann auffallen). Und genau so wie TCP dann _langsam_ die Sendebandbreite wieder erhoeht sollte auch ein DLM-System die Eingriffe langsam zurücknehmen so weit bis der Bereich gefunden ist in dem die Leitung nach der internen Definition des DLM Systems stabilisier ist. (Dieser Zustand zeichnet sich dadurch aus, dass eine weitere Reduktion der Latenz oder Erhoehung der Bandbreite wieder zu ueberschwellig vielen Fehlerereignissen fuehrt oderdass bereits wieder die maximale Profilgrenze erreicht wuerde).


Hier mal eine Beschreibung eines solchen System vom britischen ISP plusnet:
https://web.archive.org/web/20180410...s/ba-p/1322799


Es waere schoen wenn wir hier weitere technische Beschreibungen zur Existenz und zur Funktionsweise zu DLM im allgemeinen und zur Implementierung der Telekom im speziellen hier sammeln könnten. Die Diskussionen zur Kundenzufriedenheit und zur Vertrags-Konformität sind IMHO besser in den Unterforen der jeweiligen ISPs aufgehoben

Gruss
P.

[NokDar]

Meine Vermutung: Die gekappten Profile (Deckelprofile) werden durch die Anzahl an G.INP Re-Transmissions in einem bestimmten Zeitraum beeinflusst. Die Anzahl an Re-Syncs scheint daran eher weniger beteiligt zu sein.

Auch die im anderen Thema geäußerten Vermutung das hänge mit der INP-Stufe zusammen bezweifle ich. Die höheren INP-Stufen sind eine Folge (nicht Ursache) des Deckelprofil, so wie mit einem Deckelprofil auch ein höherer SNR ausgehandelt wird.

[robert_s]

Zitat von pufferueberlauf

Es waere schoen wenn wir hier weitere technische Beschreibungen zur Existenz und zur Funktionsweise zu DLM im allgemeinen und zur Implementierung der Telekom im speziellen hier sammeln könnten.

Sprich: Die Arbeit leisten, welche die überforderten und unterqualifizierten Mitarbeiter der DSL-Fachabteilung bei der Telekom nicht zu erledigen vermögen. Aber ich denke, hier helfen viele gerne technisch Unbegabten, und das ist ja auch ok.

Nur soviel dazu. Und jetzt viel Spaß bei der Beschäftigung mit dem Thema.

[pufferueberlauf]

Hier noch eine weitere englische Quelle zur Funktionsweise des dortigen DLMs:
http://www.kitz.co.uk/adsl/DLM.htm

[thom53281]

Zitat von pufferueberlauf

Es fehlt jedoch an wirklich belastbaren Aussagen zur Funktionsweise und zu den Schwellenwerten deren Unter- oder Überschreiten solche Eingriffe auslösen (und genau dieses Problem sollte dieser Thread behandeln).

Sehr schade ist halt auch, dass die Diagnosedaten der Fritzboxen mittlerweile bei weitem nicht mehr so aussagekräftig sind, wie früher. Gerade die Zähler für FEC-Fehler und Retransmissions wären hier sehr interessant. Nur wurden die ja in neuen Firmwares ausgeblendet, da sich viele Benutzer aufgrund der Zähler Sorgen machten. Ich schätze, dass dieses Verhalten wohl am ehesten an diesen Zählern festgemacht wird.

Ich bin mir gerade nicht sicher ob man die FEC-Fehler in der Fritzbox noch mittels telnet auslesen kann. Schätze schon, dass das geht und der Wert nur in der Oberfläche entfernt wurde. Falls ja, wäre es schön, wenn das einmal jemand mit Deckelproblem machen könnte. Und am besten mit anderem Router zum Vergleich.

Zitat von robert_s

Sprich: Die Arbeit leisten, welche die überforderten und unterqualifizierten Mitarbeiter der DSL-Fachabteilung bei der Telekom nicht zu erledigen vermögen.

Es wäre schön, wenn wir zumindest diesen Thread vorurteilsfrei halten könnten. Wir können das ja gerne im anderen Thread weiterdiskutieren.

[A1B2C3D4]

Die Werte (FEC-Fehler, Retransmissions, ...) stehen in den Supportdaten.

Zitat von AVM Supportdaten

DS RTX uncorrected DTUs: 0
DS RTX corrected DTUs: 0
DS RTX retransmitted DTUs: 0

US RTX uncorrected DTUs: 0
US RTX corrected DTUs: 0
US RTX retransmitted DTUs: 0

https://avm.de/service/fritzbox/frit...ten-erstellen/

[Kurz]

Im TelekomHilft Forum wurden diese Links gepostet:
https://support.zen.co.uk/kb/Knowled...Keywords=linek
https://support.zen.co.uk/kb/Knowled...rticleid=11511

[NokDar]

Zitat von A1B2C3D4

Die Werte (FEC-Fehler, Retransmissions, ...) stehen in den Supportdaten.

Problem für viele dürfte sein, dass man die Daten haben müsste (kurz) bevor das DLM ein Deckelprofil veranlasst hat. Nach dem verpassten Deckel dürften sich in den meisten Fällen die Anzahl der Fehler vermutlich reduzieren.

[robert_s]

Hat jemand denn schon erfasst mit welchen DSLAM-Firmware-Versionen bzw. DSLAM-Herstellern das Phänomen überhaupt schon beobachtet wurde? Und welche Downgrade-Profile es eigentlich gibt?

Ansonsten würde ich anregen, ein Script zu basteln, welches regelmässig (vielleicht alle 15 oder 30 Minuten) die Supportdaten von einer Fritz!Box zieht und parset nach:

1. Fritz!Box Modell und Firmware-Version
2. DSLAM-Firmware-Version
3. Fehler/Retransmit-Zähler
4. max. DSLAM-Datenrate

Und natürlich insbesondere bei Abweichungen von 4. von den Normalwerten "Alarm schlägt".

Idealerweise wird daraus ein "verteiltes Community-Projekt" mit zentraler Datensammlung, sodass man auswerten kann, in welchen Konstellationen der "Deckel" auftritt - und in welchen nicht, sowie welche "Deckel" es eigentlich gibt, ob der "Deckel" tatsächlich wieder verschwindet, etc...

[robert_s]

Näher ausgeführt:

Das Script sollte die kompletten Supportdaten lokal archivieren (damit man sie ggf. später noch manuell auswerten kann) und die obigen Daten 1., 2. und 4. als eine Art "Hash" über den Anschlusszustand speichern. Bei jeder Änderung dieses "Hashes" (also auch initial) werden diese Daten an die zentrale Datensammlung übermittelt, inkl. einer Kennung des Absenders für eventuelle Rückfragen.