Wie sauberen DSL disconnect auslösen ?

[totalverrückteruser]

An einem stabilen Anschluss spielt das garkeine Rolle.
An einem instabilen Anschluss passiert es so oder so irgendwann.

Ich kann das gegeiere um das letzte Bit im Up/Down nicht nachvollziehen. In keinem mir bekannten Szenario bemerkt man es effektiv, wenn der Anschluss 5% weniger Bruttodatenrate hat.

Im Zeifel verlang vom Techniker nach der Aktion nen vollständigen Portreset.

 

[Lecter]

Nochmal: Es gibt da keine besonderen Vorgehensweisen! Wenn nach einem gewollten oder ungewollten Leitungsunterbrechung eine niedrigere Geschwindigkeit eingestellt wird, hat die Leitung zum Zeitpunkt der Unterbrechung und Wiederaufbau der Verbindung genau diese Qualität zur Verfügung gestellt. Je nach Auslastung der Leitung kann das große Sprünge machen. Wenn dann die Leitung schlechter Bewertet wurde einfach laufen lassen, nach wenigen Wochen ist sie wieder an ihrem Maximum angekommen.

 

[Exodus88]

Ein großes Problem dabei ist, dass viele unterschiedliche Erfahrungen vorliegen...

Auch der Telekom Service hat hierfür widersprüchliche Aussagen. Anders ausgedrückt, du stellst ein und dieselbe Frage 5 verschiedenen Servicetechnikern oder der Hotline, wirst du auch unterschiedliche Aussagen bekommen.

Hier mal ein Auszug von der Telekomantwort:

Wenn du den Router aus der Weboberfläche neustartes oder wenn du ein Update machst, soll es nicht passieren. Ich hab es bisher einmal erlebt, dass DLM sich trotzdem eingeschaltet hat.

Durch den guten Kontakt mit der TK, hatten wir das an meinem 100/40 Anschluss ausprobiert.
2x Neustart an einem Tag und die DSLAM-Datenrate Max. wurde von 47000 auf 37000 kbit/s reduziert.
2 Tage später erneut 2x Neustarts über die GUI und dann landete ich bei 32000 kbit/s im UL.

Anschließend wurde mit einem Portreset der Anschluss zurückgesetzt und ich hatte wieder volle Leistung im UL.

Um die DSLAM-Datenrate Max. Anzupassen, braucht es nicht einmal einen reboot bzw. Neustart der Box. Es reichen sogar Resyncs, damit DLM die Rate reduziert.

Bei mir findet diese Leitungsanpassung immer 2 Tage später zwischen 2 und 3 Uhr früh statt.
Um das besser zu verdeutlichen, würde ich jetzt 3x die Box über die GUI neu starten oder den Button "Neu verbinden" - unter Internet/Online Monitor betätigen, würde mir die UL am Sonntag zwischen 2 und 4 Uhr reduziert.

Das dieses kein Mytos an meinem Anschluss ist, habe ich schon mehrfach hier im Forum belegt:

3x Resync (ohne Neustart der Box) - https://www.ip-phone-forum.de/threa...-39-7-50-7-51-sammelthema.312202/post-2509157

2 Tage später - UL Reduzierung - https://www.ip-phone-forum.de/threa...-39-7-50-7-51-sammelthema.312202/post-2509290

weitere Reduzierung auf 32000 - https://www.ip-phone-forum.de/threa...06-2023-7-57-v-04-09-2023.315506/post-2521223

Und wie man hier gut erkennen kann, gab es keine Anpassung mehr nach oben. Erst nachdem der Service eingegriffen hat, war die Leitungskapazität im UL wieder ausgelastet.
Im Übrigen waren das keine 3 Monate, sondern 4 Monate, wo an meinem Anschluss nichts passiert ist.

Hier noch die Daten meines Anschlusses in NBY.



CRC Fehler gibt es nur bei Gewitter, und das im Normalfall im einstelligen Bereich. Am Sonntag war das etwas anders, da gab es stundenlang Dauerdonnern.

Gruß

Roland

 

[mp37c4]

@Exodus88 Viele unterschiedliche Erfahrungen, ja! Bei mir ist es genau anders als bei dir: ich habe die letzten 2 Tage sehr oft die Boxen gewechselt (von 7590 auf 7690), rebooted, Einstellungen geändert, neue Firmware, wieder zurück auf die alte, wieder auf die neue usw. Aber DLM hat sich nicht gemeldet! Die Werte stehen bei 116/42. Leider synced die 7690 nicht so gut wie die 7590 (111 zu 116), deshalb habe ich eben einen Port-Reset machen lassen und jetzt hat sie sich immerhin mit 114 verbunden. Ich lasse das jetzt mal so unberührt laufen und beobachte die Situation. Sollte der Port-Reset die DLM Fehler resettet haben?

 

[maik005]

Hab zwar damit Vollsync von knapp 290MBit/s, allerdings mit hunderttausenden "korrigierten DTUs" pro 15Min. Nachdem die Fehler plötzlich aufgetreten sind, hab ich mir T-Techniker bestellt

ich frage mich warum du da einen Techniker bestellst.
korrigierte Fehler sind ja praktisch keine Fehler mehr, da die Fehlerkorrektur das gemacht hat wofür sie da ist.
Oder gab es tatsächliche Probleme mit der Übertragungsgeschwindigkeit oder Paketverlusten?

 

[Grisu_]

Nein, in dieser Größenordnung ist das alles andere als normal und dann kommen zwangsläufig auch immer häufiger unkorrigierbare dazu.

 

[guidox]

korrigierte Fehler sind ja praktisch keine Fehler mehr, da die Fehlerkorrektur das gemacht hat wofür sie da ist.
Oder gab es tatsächliche Probleme mit der Übertragungsgeschwindigkeit oder Paketverlusten?

Auch korrigierte Fehler nerven, da das surfen sich zäh anfühlt. Die Fehler haben auch in der Regel eine Ursache, die sich beheben lässt.

 

[stoney]

Korrigierte Fehler führen ja auch zu einer erneuten Anforderung dieser (TCP) Pakete und dementprechend bemerkt man hier natürlich eine gewisse Latzen.

Kommt natürlich immer auf die Anwendung an, ob hier eine Prüfung der übertragenen Daten nötig ist oder nicht. (Echtzeitanwendungen sollte dementsprechend immer über TCP laufen)

 

[maik005]

da das surfen sich zäh anfühlt.

Gefühl oder Fakt?
Ich tippe auf Gefühl.
Denn von korrigierten Fehlern wirst du sicherlich nichts merken können.

Korrigierte Fehler führen ja auch zu einer erneuten Anforderung dieser (TCP) Pakete und dementprechend bemerkt man hier natürlich eine gewisse Latzen.

wie kommst du darauf?
Davon merkt TCP gar nichts und auch das Zielgerät im Netzwerk merkt nichts von den korrigierten DTU.

Selbst bei unkorrigierten DTU, sendet die Quelle das TCP Paket nicht neu, sondern die DTU wird vom DSLAM direkt erneut gesendet.

Hilfe FRITZ!Box 7590 - DSL

service.avm.de

-- Zusammenführung Doppelpost by stoney

Echtzeitanwendungen sollte dementsprechend immer über TCP laufen

niemals über TCP sondern über UDP.

 

[Novize]

Korrigierte Fehler führen ja auch zu einer erneuten Anforderung dieser (TCP) Pakete

Verwechselst Du das nicht mit den unkorrigierbaren Fehlern?
Korrigierte Fehler werden doch anhand der (bei TCP) mit gesandten Korrekturdaten wieder rekonstruiert und das in Echtzeit. Das dürfte man gerade beim "nur surfen" nicht wirklich fühlen.
Die nicht korrigierbaren Pakete werden erneut angefordert (weil der Router diese nicht mit seinen eigenen Mitteln korrigieren kann) und das dauert halt

 

[PeterPawn]

anhand der (bei TCP) mit gesandten Korrekturdaten wieder rekonstruiert

Hier bringst auch Du imho etwas durcheinander - es werden keine zusätzlichen Informationen zur Fehlerkorrektur (wie z.B. bei ECC-Verfahren) gesendet, sondern nur eine Prüfsumme über das Paket gebildet (https://en.m.wikipedia.org/wiki/Transmission_Control_Protocol#Error_detection), mit der der Empfänger verfälschte Pakete erkennen kann. Heutzutage bieten das praktisch alle Netzwerk-Chips schon als "Offloading" an, was dann direkt auf der Hardware geprüft wird und dann wird höchstens noch ein Fehler an den Treiber gemeldet oder das Paket gleich komplett "unterschlagen".

Es gibt bei TCP auch kein explizites "negative ACK" (NACK) für das gezielte Anfordern des erneuten Sendens EINES speziellen Pakets - das wird über "duplicate ACK" für das letzte erfolgreich empfangene Paket ausgelöst (was eben die Latenz deutlich erhöht, da dieses ACK-Paket erst mal wieder beim Sender ankommen muß), wobei heutzutage auch fast alles mit "selective ACK" (SACK) ausgehandelt wird, wo aber der Empfänger immer noch nur positive Quittungen versenden kann und sich eine negative Quittung aus dem Ausbleiben der positiven Meldung ergibt (anders als z.B. bei HDLC).

 

[maik005]

korrigierte Fehler werden doch anhand der (bei TCP) mit gesandten Korrekturdaten wieder rekonstruiert

Du verwechselst die DSL Ebene mit der IP Ebene.

Korrigierte und nicht korrigierte DTU konnten direkt vom Modem korrigiert werden und sind die über DSL übertragenen Daten.
Nicht korrigierte DTU werden vom DSLAM erneut gesendet.
Erst bei CRC Fehlern werden Pakete wirklich verworfen und mussten vom entfernten Sender, statt vom DSLAM, neu gesendet werden?

 

[_jan_]

DTUs werden durch erneute Übertragung korrigiert. Die Übertragung wird so oft wiederholt, bis entweder das Empfänger-Modem den korrekten Empfang bestätigt, oder ein Timer abläuft. Wenn der Timeout erreicht wurde, ist die DTU endgültig verloren und wird als unkorrigiert gezählt.

Der CRC-Zähler wird bei aktivem G.INP aus den unkorrigierten DTUs berechnet (jedes 17-ms-Interval mit mindestens einer unkorrigierten DTU erhöht den Zähler um eins).

Die Vorwärtsfehlerkorrektur (FEC), bei der Fehler ohne erneute Übertragung aus redundanten Daten korrigiert werden können, gibt es zusätzlich auch noch. Das hat aber mit DTUs nichts zu tun, sondern erfolgt eine Ebene darunter.

Die Beschreibung zu den DTU-Zählern in der Hilfe von AVM (woher die oft wiederholte falsche Erklärung vermutlich kommt) ist leider falsch. Dabei gibt es in der G.INP-Spezifikation (ITU-T G.998.4) sogar eine kurze Beschreibung, die hätte man nur übersetzen müssen.

 

[mp37c4]

@_jan_ Danke, das würde auch erklären, warum viele "korrigierte DTUs" die verfügbare Bandbreite drücken.

 

[totalverrückteruser]

Nicht, dass es nicht hochinteressant ist, aber kann mir von hier mal eine*r den Bogen zur Eingangsfrage spannen?
Oder bin ich falsch abgebogen?

 

[stoney]

Du hast wohl nicht mitbekommen, dass es nach wie vor hier kein einheitliches Vorgehen gibt, welches zu dem gewünschten "Todesröcheln" führt

Dying gasp - Wikipedia

en.wikipedia.org

Ich habe den englischen Artikel verlinkt, da im Deutschen mMn das Wichtigste diesbezüglich fehlt.

 

[_jan_]

@_jan_ Danke, das würde auch erklären, warum viele "korrigierte DTUs" die verfügbare Bandbreite drücken.

Genau, und die geringste Datenrate, die durch Retransmissions aufgetreten ist, wird über den Parameter MINEFTR (minimum effective throughput, in der Fritzbox "Min effektive Datenrate") angegeben,

Du hast wohl nicht mitbekommen, dass es nach wie vor hier kein einheitliches Vorgehen gibt, welches zu dem gewünschten "Todesröcheln" führt

Den Dying gasp kann man recht einfach auslösen: Einfach den Stecker vom Modem(-router) aus der Steckdose ziehen.

Das funktionierte als ich es vor einiger Zeit mal ausprobiert hatte zuverlässig mit Fritzboxen (7530 und 7412) sowie einem Speedport Smart 2 (Gegenstelle für den Test war ein Allnet ALL126AM2). Bei Geräten von anderen Herstellern sollte man aber eher nicht damit rechnen, dass es klappt (mit einem Asus DSL-N17U und einem Draytek Vigor 130 ging es nämlich nicht).

Bei einem Neustart wird kein Dying gasp gesendet, der ist nur für unvorhergesehene Ausfälle der Spannungsversorgung vorgesehen.

 

[stoney]

Also wäre dies (unvorhergesehener Verbindungsverlust, durch zB Stromunterbrechung des Modems) die einzige Möglichkeit DLM nicht zu triggern, alles andere würde als "Störung" gewertet und dabei ist wie Du schreibst, das nicht bei allen Routern so, dass diese das "Röcheln" noch rausbekommen - es also sozusagen ein Glückspiel bzw. Try and Error ist?

 

[maik005]

Dabei gibt es in der G.INP-Spezifikation (ITU-T G.998.4) sogar eine kurze Beschreibung, die hätte man nur übersetzen müssen.

Wärst du so freundlich, die Seite zu nennen und den Bereich in dem das steht?

 

[_jan_]

@stoney: Wenn man sich die Spezifikation für VDSL2 anschaut (ITU-T G.993.2), dann gibt es mit dem "L3 request" (siehe Link-State-Diagramm in Abschnitt 12) in jedem Fall einen Mechanismus für eine saubere Abmeldung.

Ob das tatsächlich in den üblichen Modems ordentlich umgesetzt ist, weiß ich aber nicht. Beim ALL126AM2 war im Test ein Neustart nicht von einer sonstigen Verbindungstrennung unterscheidbar, aber das kann ja auch an dem Gerät selber liegen.

Ansonsten, zur Funktion vom Dying gasp: Ich würde davon ausgehen, dass wenigstens diejenigen Geräte, die vom Hersteller für den Betrieb im Netz der Telekom entwickelt worden sind, das ordentlich unterstützen. Immerhin ist es ja in der Schnittstellenbeschreibung vorgeschrieben.

@maik005: Wollte ich eigentlich gleich dazuschreiben, aber hab es dann wohl vergessen: Es geht um Abschnitt 12 (Seite 40).