Telefonkabel DLM Thread - Dynamic Line Management

[xdjbx]

war ich gedrosselt, und es bedurfte den Kontakt zu jemandem, der es resetten konnte.

Das geht innerhalb weniger Tage im besten Fall sogar über Nacht automatisch. DSL Expresse erkennt ziemlich genau den Grund des Ausfalls, und auch ob der plötzlich kommt oder sich mit Fehlern anküdigt und bewertet das entsprechend mit.

 

[frid0lin]

Also ein Freund von mir hat kürzlich "Wireguard" in seiner Fritzbox eingebaut. Damit kann seine Familie in der Türkei den Erdogan Filter umgehen ;-). Er musste aber ein paar mal das Image korrigieren, leider jedesmal mit Reload nach dem Flashen. Nun hängt er seitdem seit ca einem Monat schon in der Drossel. Also ganz so schlau ist das Zeugs nicht.... Die Firmware und die Box ist die selbe geblieben, 7.29 gefreetz, die Box eine 7590. Immerhin ging es nun nach 4 Wochen (!) einen Schritt hoch, von 32000 up und 90000 down auf 37000 up 100 000 down . (Zielwert war 42,6 Mbit Upload 113 M down)

(Wenn man tunnelt, und selber den VPN Server hat, kann man nicht genug Upload haben)

 

[rentek]

Möglicherweise gibt es unterschiedliche Software-Stände von ASSIA DSL-Expresse, der eine reagiert so, der andere so.

 

[chartmix]

Doch, ist genau so dumm. Ich war nie gedrosselt, nach dem mehrfachen Stromausfall wegen eines Körperschlusses bei der Heizung war ich gedrosselt,

Ein Stromausfall ist kein Neustart eines Routers. Bei einem Neustart gibt es eine Info darüber an die Gegenstelle.

 

[frid0lin]

Beim Reload sollte das Death rattle, das "Todesröcheln" gesendet werden, das sollte man auf dem DSLAM und damit auch auf der Assia Seite erkennen. Um so unverständlicher die Drosselung danach beim wiederholten Flaschen einer Fritzbox und dem Reload danach. Was das "dumm" bestätigt. Q.e.d.

Darum habe ich ja ein Modem vorgeschaltet, da man bei dem Modem eigentlich kaum Updates machen muss und der Sync (außer bei Stromausfällen) immer gehalten wird, läuft man kaum in Stress mit dem DLM Gedöns beim Basteln an der Fritzbox etc.

 

[chartmix]

Also ein Freund von mir hat kürzlich "Wireguard" in seiner Fritzbox eingebaut. Damit kann seine Familie in der Türkei den Erdogan Filter umgehen ;-). Er musste aber ein paar mal das Image korrigieren, leider jedesmal mit Reload nach dem Flashen. Nun hängt er seitdem seit ca einem Monat schon in der Drossel. Also ganz so schlau ist das Zeugs nicht....

Mehrere Abbrüche der DSL Synchronisation interpretiert DLM wohl als instabile Leitung. Wird schon.
Jetzt weiß der Freund hoffentlich Bescheid.
Aber Wireguard wird "nativ" auch für die 7590 kommen. Es gibt bereits eine interne Firmware. Als nächstes kommen dann die Laborfirmwares.

Ergänzung (31. Dezember 2021)

Beim Reload

Ein Stromausfall ist aber kein Neustart und ich wüsste nicht das die Fritzbox ohne Strom noch was sendet.

 

[frid0lin]

Zitat:
Ein Stromausfall ist aber kein Neustart und ich wüsste nicht das die Fritzbox ohne Strom noch was sendet.

Eben. Du sagst es.

Träte das Drosseln NUR beim Stromausfall auf, verstünde man es ja. Aber auch nur bedingt. Siehe unten.
Es geht darum, dass es EGAL ist, ob Reload oder Stromausfall. Beim Reload mit Death rattle tritt es AUCH auf.

Und wenn der Strom ausfällt und nicht sofort wiederkommt, kann das Training gar nicht starten. Also auch das KÖNNTE man von einem instabilen Sync wegen schlechter Leitung schon unterscheiden.

Wenn man die Soft vernünftig macht oder konfiguriert......

 

[chartmix]

Um so unverständlicher die Drosselung danach beim wiederholten Flaschen einer Fritzbox und dem Reload danach.

Das hört sich für mich aber nicht nach einem normalen Neustart an.
Ich weiß aber auch nicht was beim flashen und danach genau passiert.

 

[frid0lin]

Das Script macht am Ende nach dem Entpacken und Schreiben des Images ins Flash einen ganz normalen Reload, nur, dass dann auf die andere Speicherbank umgeschaltet wird. Aus Sicht des DSL Treibers genau das Selbe wie beim normalen Reload. Es wird letztlich ein ganz normaler Reload vollzogen. Das ist ja das Schöne an der Fritte und Projekten wie Freetz. Der Code ist zugänglich. Alles recht gut nachvollziehbar.

 

[ookee]

Ein Stromausfall ist aber kein Neustart und ich wüsste nicht das die Fritzbox ohne Strom noch was sendet.

Doch, das ist schon so vorgesehen, dass ein DSL-Modem den Einbruch der Versorgungsspannung erkennt und der Gegenstelle signalisiert (Abschnitt 11.3.3 in G.993.2 und Abschnitt 7.1.1.2.3 in G.997.1).

Und in einem Test mit einem ALL126AM2 und einer Fritzbox 7412 mit OpenWrt scheint das auch tatsächlich zu funktionieren (meistens zumindest). Auf dem ALL126AM2 lässt sich kurz nach dem Ziehen des Stromsteckers der Fritzbox folgendes auslesen:

/ifx/vdsl2 # ./dsl_pipe G997_LineFailuresStatusGet 0 0                                           
nReturn=0 nLine=0 nDirection=0 nLineFailures=4

/ifx/vdsl2 # ./dsl_pipe G997_LineFailuresStatusGet 0 1
nReturn=0 nLine=0 nDirection=1 nLineFailures=1

Beim Wert nDirection steht 0 für Near End und 1 für Far End. Die Werte für nLineFailures dürfte denen des aktuellen Treibers entsprechen. Demzufolge hat das ALL126AM2 lokal einen loss-of-signal erkannt, und für die Gegenstelle korrekterweise einen loss-of-power. Das hat bei ein paar Versuchen (5 oder so) meistens geklappt, einmal habe ich stattdessen aber auch nLineFailures=4 gesehen, also loss-of-signal.

Zum Vergleich: Wenn ich das DSL-Modem der Fritzbox geordnet deaktivere, bleibt der Wert für Near- als auch Far-End bei 0 (dieser Wert wird auch bei aktiver Verbindung für beide Enden ausgegeben). Wenn ich nur das DSL-Kabel unterbreche, berichtet das ALL126AM2 für das Near End einen loss-of-signal, und für das Far End weiterhin 0.

Evtl. kann ich das auch noch mit ein paar anderen Modems testen, um zu sehen, ob das da auch funktioniert.

Beim Reload sollte das Death rattle, das "Todesröcheln" gesendet werden

Kann es sein, dass du das mit der oben beschrieben Power-Loss-Erkennung verwechselst? Der Name "Death rattle" würde ja wie der tatsächlich in G.993.2 genannte Begriff "Dying gasp" eher dazu passen, als zu einer geordneten Trennung.

Ich würde erwarten, dass bei einer geordneten Trennung der DSL-Verbindung (und das sollte ja bei einem Reboot des Modems passieren), eher ein L3 Request gesendet wird (Abschnitt 11.2.3.9.1 in G.993.2). L3 steht bei VDSL2 für den Link State, in dem keine aktive Verbindung besteht.

(Das scheint übrigens unter OpenWrt nicht korrekt zu funktioneren, nach einem Reboot der mit OpenWrt laufenden Fritzbox zeigt das ALL126AM2 nämlich einen Near-End loss-of-signal, genau wie bei der Trennung des DSL-Kabels).

 

[Sebbi]

Bei Telekom-eigenen Anschlüssen entweder gar nicht oder nur mit viel Hilfe (@Telekom hilft) möglich.

mit dem Team stehe ich schon in Kontakt, weil es eben ein Problem gab mit der Leitung die zu der extremen DLM Drossel auf 40 MBit/s Nutzrate geführt hatte, weil die Leitung nur eben so nen geringen Widerstand gegen Erde hatte.
Nach der Behebung durch den Leitungstechniker lief eben alles einige Tage tutti, dann eben 2x herunterstufen auf aktuell 53 Mbit/s Nutzrate, weil kurze CRC fehlerwellen am Tag waren, was DLM wieder getriggert hat scheinbar. Liegt aber eben noch im Vertragsrahmen, daher kann aktuell nicht gemacht werden.
Erst bei der nächsten Stufe wenn die Nutzrate auf <50 Mbit/s absinken wird, gehts wieder an die Findung, warum DLM anspringt und wie man das beheben kann.

 

[pufferueberlauf]

Das geht innerhalb weniger Tage im besten Fall sogar über Nacht automatisch. DSL Expresse erkennt ziemlich genau den Grund des Ausfalls, und auch ob der plötzlich kommt oder sich mit Fehlern anküdigt und bewertet das entsprechend mit.

Das ist halt erst mal nur Theorie, in der Praxis ist DSLExpresse auch nicht unfehlbar... Sehe ich an meinem Link der zwischen 1 mal die Woche und mehrmals am Tag resynct und vom DLM immer gesxhmeidig im 116/37 Korridor gehalten wird... (also DLM nur im Uplink aktiv) obwohl es zu regelmaessigen FEC, G.INP Retransmissionen (auch wiederholten) und gelegentlich zu nicht erfolgreichen Retransmissionen kommt. Da waere auch ein schaeferes Vorgehen diskutabel um die Stabilität des Links zu erhöhen...

Das soll jetzt keine Kritik an DSLExpresse sein, oder dass die Telekom das einsetzt, kann ich alles nachvollziehen und unterstützte dessen Einsatz voll; aber es zeigt, dass DSLExpresse eher mit Heuristik als mit kausaler Analyse arbeitet... und das heisst manchmal klappt's halt nicht so gut mit der Stabilisierung.... letztlich kaum anders zu loesen, wenn man bedenkt, dass DSLExpresse mit DSLAMs und Modems verschiedenster Hersteller arbeiten muss.

 

[myfan]

@myfan Poste mal bitte einen Screenshot der Tabelle "DSL" unter "DSL-Informationen", da sieht man, ob SRA aktiv ist.

Ach, hab schon selber geschaut, sie steht auf aus.
Nahtlose Ratenadaption aus aus

 

[frid0lin]

Kann es sein, dass du das mit der oben beschrieben Power-Loss-Erkennung verwechselst? Der Name "Death rattle" würde ja wie der tatsächlich in G.993.2 genannte Begriff "Dying gasp" eher dazu passen, als zu einer geordneten Trennung.

Ich würde erwarten, dass bei einer geordneten Trennung der DSL-Verbindung (und das sollte ja bei einem Reboot des Modems passieren), eher ein L3 Request gesendet wird (Abschnitt 11.2.3.9.1 in G.993.2). L3 steht bei VDSL2 für den Link State, in dem keine aktive Verbindung besteht.

Ja, du hast Recht. Ich habe den Artikel dazu, den ich mir mal heruntergeladen hatte, wiedergefunden.

Das Todesröcheln wird beim Stromausfall vom DSL Chip gesendet, quasi mit dem letzten Rest Lebensenergie aus den Elkos ;-). Passt ja, die Wortwahl.

Dass die Restenergie im Netzteil dafür reicht, hatte ich nicht mehr auf dem Schirm, und hatte das Todesröcheln nun falsch mit Reboot assoziiert.

Beim Reboot wird ein anderes Link Down Signal gesendet. Also wenn alles korrekt implementiert ist, könnte Assia sowohl Power Off als auch Reboot korrekt erkennen. Also gibt es nich weniger Gründe dazu, diese Fälle als Drosselkriterium zu benutzen.

Mit dem Supervectoring Modem von Draytek, dem Vigor 165, bin ich ich alle Assia Probleme los geworden, denn das DGA4132, das ich zuvor hatte, erzeugte zu viele Retransmissionen, so dass Drosseln hier ja auch ein korrektes Verhalten war. Nun erreiche ich stabil bei einer Leitungslänge von 470 m 185 Mbit/sec down und 42,6 MBit/s up, was einem echten Durchsatz von 172 Mbit/sec down und 38Mbit /sec up entspricht. Und das auch im Sommer, wo die Leitungskapazität deutlich fällt. Spontane Resyncs gibt es nicht. Da wir gerade nachts oft im Homeoffice, auch vor Corona, per Fernwartung die Changes an der Medizin IT durchführen, sind die regelmäßigen 3 Uhr Resets im Falle der Assia Drosselung ein Albtraum. Der erste Befehl auf dem Remotesystem ist zwar eh immer "screen", um keinesfalls die offene Sitzung zu verlieren, aber man flucht dann schon, wenn der VPN wegfliegt.

 

[rentek]

Ich tippe noch immer darauf, dass es auch bei ASSIA unterschiedliche Software-Stände gibt, die im Rahmen von Wartungsarbeite am DSLAM eingespielt werden. Dies würde auch das unterschiedliche "(Ent)-Drosselungs"-Verhalten an verschiedensten Anschlüssen erklären (ältere Software-Stände haben noch Bugs, neuere nicht mehr).

 

[IliadZenith]

Ich denke immer noch das bei meinem Anschluss auch eine Variante von DLM aktiv ist, obwohl keine Profilgrenze vorhanden ist. Ich habe darüber ja schon auf Onlinekosten berichtet (MingoWave), möchte es aber hier nochmal festhalten, da es sonst vergessen gerät und es für einige vielleicht hilfreich ist, da es ja doch ein eher unbekanntes Verhalten ist. Es wird anscheinend die Sendeleistung während des Handshake auf den Vectoring Trägern zurückgehalten um einen künstlich niedrigeren Sync mit mehr Reserve zu erzwingen. Effektive habe ich 6/6 dB während des Handshake und kurz später dann aber 12/8. Grund dürften kurze und vereinzelt auftretend Störphasen sein.

Aber wer weiß, vielleicht ist es ja auch etwas ganz anderes. Werde ich wohl nie heraus finden. Es ist halt so eine intransparente Technologie, dieses DLM, das eventuell auch die Telekom die ganzen Details nicht versteht und die Effektivität des Ganzen möglicherweise auch nur auf höherer, abstrahierten Ebenen analysiert und sich sonst auf die Expertise von Assia verlässt.

Und das es nicht sonderlich schlau und flexibel ist, sieht man ja schon an diesen ewigen Wartezeiten um es wieder los zu werden.

Ergänzung (1. Januar 2022)

Bei mir gab es vor ein paar Tagen über eine Stunde verteilt mehrere Resync. Ich hatte schon die Hoffnung, das endlich etwas passiert, aber nein. Auch die Linecard Version blieb gleich. Sonst habe ich nie Resyncs. Ich befürchte schon fast, das etwas manuell eingestellt wurde bei meinem Vectoring-Verbund, auch wenn es vielleicht nicht (mehr) nötig ist.

 

[ookee]

Zum Vergleich: Wenn ich das DSL-Modem der Fritzbox geordnet deaktivere, bleibt der Wert für Near- als auch Far-End bei 0 (dieser Wert wird auch bei aktiver Verbindung für beide Enden ausgegeben).

Diesen Teil muss ich revidieren. Ich hatte gedacht, dass sich unter OpenWrt mit /etc/init.d/dsl_control stop die DSL-Verbindung sauber trennen lässt. Tatsächlich wird dadurch aber nur der Userspace-Dienst gestoppt. Die eigentliche DSL-Verbindung bleibt laut dem ALL126AM2 bestehen bis man sie dann tatsächlich anderweitig trennt.

Damit ist auch nicht klar, ob die Verbindungstrennung beim Reboot tatsächlich unsauber war, oder ob der Failure Status beim ALL126AM2 da einfach keine Unterscheidung zulässt. Möglicherweise müsste man das auch anderweitig auslesen, falls es denn überhaupt geht.


Zusätzlich habe ich jetzt noch ein paar Tests mit anderen Modems gemacht (Speedport Smart 2, Fritzbox 7530, Fritzbox 7412 mit Original-Firmware, Draytek Vigor 130, Asus DSL-N17U, Netgear DGND3800B). Bei allen außer dem Asus mit seinem Mediatek-Modem und dem Vigor 130 funktioniert der Dying gasp.

Wie beim ursprünglichen Test der Fritzbox 7412 mit OpenWrt, wird bei allen Modems bei einem Reboot lediglich ein near-end loss-of-signal erkannt. Aber wie oben bereits erwähnt, muss das nicht unbedingt was bedeuten.

Übrigens braucht es für den Dying gasp tatsächlich nicht einmal unbedingt das Netzteil. Außer bei der Fritzbox 7530 funktioniert es bei allen Modems auch, wenn man das Kabel am Gerät aussteckt.


Aber ich denke insgesamt kann man davon ausgehen, dass der Dying gasp bei Stromausfall/Steckerziehen zumindest bei den gängigen Modems funktioniert (ist ja auch in der Schnittstellenbeschreibung der Telekom so vorgeschrieben).

 

[blastinMot]

Ich denke immer noch das bei meinem Anschluss auch eine Variante von DLM aktiv ist, obwohl keine Profilgrenze vorhanden ist.

Kannst du dazu nochmal deine DSL-Werte posten (Screenshots aus dem Router)?
Am besten wäre natürlich eine Fritzbox o.ä. um möglichst viele Werte betrachten zu können.

Es wird anscheinend die Sendeleistung während des Handshake auf den Vectoring Trägern zurückgehalten um einen künstlich niedrigeren Sync mit mehr Reserve zu erzwingen. Effektive habe ich 6/6 dB während des Handshake und kurz später dann aber 12/8. Grund dürften kurze und vereinzelt auftretend Störphasen sein.

Es ist bei Vectoring (mittlerweile?) normal, dass nach dem Sync. die Leitungskapazität/der SNR etwas ansteigt.
Bin nicht ganz sicher ob das schon immer so war, aber habe ich in letzter Zeit häufiger beobachtet.
Sehe da aber keinen wirklichen Zusammenhang zu Assia/DLM.

 

[IliadZenith]

@blastinMot

Ergänzung (1. Januar 2022)

Ich hatte ja schon bei AVM nachgefragt, aber es ist angeblich von ihrer Seite alles OK und ich denke bei O2 brauche ich es erst gar nicht zu versuchen. Habe wie gesagt auch schon andere FB und Einstellungen probiert.

 

[blastinMot]

Welche andere FB?
Screenshots von der auch zur Hand?

Müsste man sich ggf. andere Anschlüsse auf dem gleichen APL/DSLAM anschauen oder schauen ob Assia da tatsächlich was gemacht hat.