Interleaving (Echtzeitanwendungen)

[Zuckersüß]

Die Faktenlage ist: Wenn ich den Router einfach machen lasse, habe ich spätestens ab dem 2. Tag diverse Probleme. Egal ob FritzBox oder Asus. Mein ISP (O2) macht genau nichts. Ich bin jetzt seit 3 Monaten Kunde und kann mich nicht mal in deren Community registrieren. Der Support macht wirklich nichts.

Neu: Wenn ich G.INP im Router (Asus DSL-AX82U) deaktiviere, läuft meine Echtzeitanwendung für eine gewisse Zeit sehr sehr gut. Meine Interleaving-Depth steigt zwar auf 1247 im Download und 178 im Upload, aber die Anwendung funktioniert wie sie sollte.



Leider bleibt es nicht konstant so.

Ping liegt bei 17-18ms statt 8-9ms.

 

[tango501]

Wenn ich G.INP im Router (Asus DSL-AX82U) deaktiviere

Leider keine so gute Idee. Damals in den Screenshots bei der 7530 AX war G.INP immer an, siehe Screenshots in #73.
G.INP ist ein Fehlerkorrekturverfahren, das Impulsstörungen und Paketverluste ausgeglichen soll. Bei AVM ist das nicht manuell schaltbar. Asus schreibt in der FAQ dazu "G.INP bedeutet Impulse Noise Protection. Diese Einstellung funktioniert nur bei ADSL2, ADSL2+ und VDSL2. Die Aktivierung bietet erweiterten Schutz gegen Impulsrauschen und verbessert die Effizienz der Einstellung gegen Impulsrauschen. Falls Ihr DSLAM dies nicht unterstützt, sollten Sie die Funktion deaktivieren." Vgl. dazu bitte https://www.asus.com/de/support/faq/1015709/
Nach den Screenshots von der 7530 AX unterstützt der DSLAM aber G.INP. Ist G.INP aber im Router deaktiviert und kommt es dann zu Impulsstörungen, dann sind die Probleme wie hier geschildert leider erwartbar.
G.INP besser aktiviert lassen, aber gerne in der FAQ von ASUS und unter dem Link nachsehen, welche Möglichkeiten es dort noch gibt.

 

[Zuckersüß]

Wenn ich es deaktiviere, kann ich ein paar sehr gute (wirklich ausgezeichnet gute) Runden spielen. Nach einer Zeit wird es aber leider wieder schlechter.

Ich habe aktuell wieder alles aktiviert (Standard) aber die SNR um 10dB erhöht. Jetzt habe ich eine SNR von ~16dB (sonst 5-6dB) und die FEC-Fehler sind viel niedriger. Leider kostet es ca. 100 MBit im Download.

 

[tango501]

Das wäre auch bei AVM nicht viel anders. man könnte in der FB 5690 pro die Stabilität erhöhen, es kostet dann aber auch Bandbreite. Diese Funktionen waren damals in der Firmware der FB 7530 AX ja leider nicht vorhanden.
Statt beim Asus DSL-AX82U einzelne Einstellungen durchzutestet, wären Stabilitötsanpassungen in der FB 5690 pro auch ein gangbarer Weg. Das würde ich testen, bevor es zu einem Anbieterwechsel kommt.
Kommt dann eigentlich ein Servicetechniker raus und misst die Leitung einmal durch?

 

[Zuckersüß]

Ich vermute jedenfalls, dass mein Problem etwas mit Interleaving, Retransmissions, Queueing Delay usw. zu tun hat.

 

[Zuckersüß]

Ich habe die letzten 24 Stunden alles mögliche getestet und auch mehrfach verifiziert und bin mir sicher, dass Problem gefunden zu haben. Mittlerweile habe ich leider auch ASSIA getriggert.

Faktenlage:

Modem/Router Standardeinstellungen:
- Interleave Depth 16 zu 8 (8 zu 4 mit maximal möglicher SNR von ca. 20dB)
- INP 62 zu 30
- Hoher FEC-Counter im Download
- Ping von 8-9ms zum Server in Frankfurt

= Echtzeitanwendungen laufen mal so und mal so aber überwiegend nicht gut

Vermutung: Es liegt an den FECs und den daraus resultierenden konsequenzen (Verworfene Pakete, Retransmissions usw.)

Modem/Router ohne G.INP
- Interleave Depth 1247 zu 178 (SNR auf 22.6 dB / nicht einstellbar)
- INP 2 zu 1
- Deutlich niedrigerer FEC-Counter, dafür ein paar CRC und ES Fehler im Upload (Download nicht betroffen)
- Ping von 17-18ms zum Server in Frankfurt

= Echtzeitanwendungen laufen grundsätzlich viel besser

Vermutung: Keine verworfenen Pakete, Retransmissions usw.

Ursache: Leitungsstörung

Ich warte jetzt den ISP-Wechsel ab und hoffe, dass net.D mir da weiterhilft. Ich habe kein Nerv mehr mich mit den O2 zu unterhalten, die dann eh nichts in die Wege leiten, außer mir FritzBoxen anzudrehen. Wenn Du vom Support schon hörst, dann man selber (ich) mehr wissen würde als sie, dann weisste bescheid.

PS: Mit maximal möglicher SNR (+14dB) von ~20dB habe ich nahezu keine FECs, aber es ändert leider nichts am extrem schlechten Erlebnis. Es kostet nur Bandbreite und scheint kosmetischer Natur.

 

[Novize]

Vermutung: Es liegt an den FECs und den daraus resultierenden konsequenzen (Verworfene Pakete, Retransmissions usw.)

Du hast das Prinzip FEC auch nach 226 Beiträgen scheinbar immer noch nicht richtig verstanden...
Bei FEC (Forward Error Correction) werden, wie der Name schon vermuten lässt, aus den einzelnen verschachtelten Paketen mit geringen Fehlern die Pakete wieder fehlerfrei herausgerechnet. Da gibt es dann keine verworfenen Pakete, keine neu angeforderten, da die Empfänger, Dein PC, fehlerfreie Pakete erhält.
Werden die Pakete schon im Router verworfen, weil die nicht mehr korrigiert werden können, dann landen die im Zähler für "Nicht behebbare Fehler".
Und auf die gesamten Datenpakete ins Verhältnis gesetzt im DTU-Zähler
Weiterhin suchst Du krampfhaft auf der letzten Meile den Grund für Deine Probleme. Doch die Verbindung zum DLSAM ist schon echt gut, die paar Fehler sind vernachlässigbar und würden schon statistisch gesehen kaum was an Deinen Problemen ausmachen. dann müssten ca 50% der Datenpakete betroffen sein - beachte, auch ohne Nutz-Daten werden immer die gesamte Bandbreite mit (leeren) Datenpakete gefüllt und diese fließen auch in die Bewertung der FECs, DTU usw ein.

 

[Zuckersüß]

Ich suche auf der letzten Meile, weil auch andere hier davon betroffen sind.

 

[tango501]

Ich suche auf der letzten Meile

Dann bitte die FB 5690 pro direkt an den Anschluss, da dort Fehler besser dokumentiert werden. Den ASUS Router bei einer Fehlersuche einzusetzen ist leider suboptimal.

 

[Zuckersüß]

Es bringt leider eh alles nichts. Ich stehe vor einem Problem, worüber ich keinerlei Kontrolle habe.

Ich kann nur hoffen, dass das FTTH schnell fertiggestellt wird und nicht so ein Murks ist wie man hier und da liest. Ich hoffe auch, dass man nach 2 Jahren auch zu einem anderen Anbieter wechseln kann.

Die Telekom muss ihre Infrastruktur teilen (vermieten). Ich hoffe, dass diese Synvia das dann auch muss.

Vom Peering und Ping ist O2 wirklich gut. Leider ist der Support richtiger Müll.

 

[tango501]

Leider ist der Support richtiger Müll.

Genau deswegen die FB 5690 pro direkt an den Anschluss, bei Problemen an den Routerhersteller wenden und Supportdaten übermitteln. Bei AVM / FRitz! funktioniert das (meistens). Und bei ASUS? Die FW ist dort vom Mai 2025 und es wird wohl keine weiteren Anpassungen mehr geben.

 

[Zuckersüß]

Ich habe vorhin gelesen, dass ein Mieter auch bei Synvia war und zu einem anderen ISP wechseln konnte.

Die FritzBox wird nicht mehr angeschlossen. Mein Asus ist viel besser.

 

[Ldwg2002]

Ich suche auf der letzten Meile, weil auch andere hier davon betroffen sind.

Also bist du im Gespräch mit Nachbarn. Wann beginnt ihr mit einem belastbaren Monitoring über den gesamten Tagesverlauf?

Du hast das Prinzip FEC auch nach 226 Beiträgen scheinbar immer noch nicht richtig verstanden.

Die Diagnose ist doch schon bekannt und lautet "Interleaving". Der Schuldige ist ebenfalls seit #1 bekannt.

Das Verständnis von anderen Zusammenhängen "fühlt sich für mich mangelhaft an". "Fühlen" bleibt immer subjektiv. Nur Messen bzw. Monitoring ist objektiv. Magst du - @Zuckersüß - nochmal zu _#142_ zurückkehren und mit deinen vielen Betroffenen smokeping auf irgendeiner (oder vielen) Linuxmaschine aufsetzen? Nein, dann kann dir kaum jemand helfen.

Was macht dich so sicher, dass dein Gefühl im öffentlichen IP-Netz gestört wird? Was macht dich so sicher, dass du den Fehler "interleaving" treffsicher in einem Netzteil diagnostizierst und zugleich über diesen Netzteil nur Vermutungen anstellen kannst. Mir fehlt die eindeutige Abgrenzung als "nächster Schritt in deinem Fühlen" bzw. deiner Fehleranalyse.

Paketverluste (packet loss) im öffentlichen Netz auf Layer 3/4 zu großen ISP oder großen Anbietern (z.B. gaming server in den USA) kann ich mit meinem Monitoring nicht bestätigen. Zur Illustration die letzten 30h zu einer beliebigen IPv4 85.190.136.164 https://www.nslookup.io/ip/85.190.136.164/domain-names/ monsterserver.de nitrado.net https://www.iplocation.net/ip-lookup IP ADDRESS: 85.190.136.164 COUNTRY: United States


Paketverluste (packet loss) im öffentlichen Netz auf Layer 3/4 zu winzigen Endverbrauchern die dynDNS-Dienste nutzen, wie z.B. MyFritz.net, kann ich mit meinem monitoring nur temporär bestätigen. _z.B. in diesen Beiträgen_

In meinem Monitoring-Pool zeigt sich Paketverlust (packet loss) zwischen zwei lokalen Netzwerken / FritzBoxen (mit dynDNS) ausnahmsweise kurzzeitig. Zur Illustration die letzten 30h zu immer der gleichen FritzBox7490. Einmal der dynDNS-Dienstleister, dann dynDNS-MyFritz.NET, zuletzt im VPN - Ein VPN, das kostet Rechenleistung auf beiden Seiten. Die Interpretation und Diagnose überlasse ich euch. Erwartungsgemäß liefert traceroute für beide dynDNS-Adressen die gleiche Route mit 4 hops. Wenn ich mal Zeit finde suche ich nach der Ursache, die m.E. nicht bei MyFritz.net liegt, weil MyFritz zu anderen FritzBoxen/DNS ohne Probleme funktioniert. Bis dahin erfolgt die IP-Sec-Netzkopplung, das VPN, mit welcher dynDNS-Adresse?


Mit deinen Nachbarn diagnostizierst du zuerst eindeutig Paketverlust (packet loss) im öffentlichen Netz zu bestimmten Zielen zu bestimmten Zeiten hinter euren Routern (oder nur hinter deinem?), indem andere Fehlerquellen ausgeschlossen werden. Dann ergänzt ihr jeweils um die traceroute und erstellt Tickets bei euren ISP. Gibt es Paketverlust zu jedem beliebigen Ziel, dann suchst du weiter bei FEC (Layer 1/2).

Ich suche auf der letzten Meile, weil auch andere hier davon betroffen sind.

Gibt es Paketverlust von allen deinen Nachbarn zu jedem beliebigen Ziel, dann wird der ISP jeden von euch glücklich machen können.

Wenn der ISP das Ticket mit Begründung (Ausschluss) ernst nimmt und etwas von IP-Netzen versteht, wird er auf der Route nach einem Defekt auf Layer 2 und/oder Layer 1 suchen, vielleicht auch Überlast (auf Layer 3/4). Von IP-Netzen versteht jeder ISP mehr als du und ich zusammen. Dann ist es egal ob ein Modem vor der FritzBox hängt oder die FritzBox direkt verbunden ist. Es geht nur um die Abgrenzung der Verantwortlichkeit. "Fühlen" hilft nicht weiter, in Foren lamentieren auch nicht. Ganz selten müssen auch beide ran, ISP und Router/Modem-Hersteller. Für Gefühle kann es es viele Ursachen geben.

Ich muss immer an den Level 3 oder 4 Techniker der Telekom denken: "Unsere Leitung kann nicht ausgelastet werden"

 

[Zuckersüß]

Ich kann so ein Tool auch selber schreiben. Mal schauen.

 

[Ldwg2002]

Wenn das schneller geht als installieren, warum tust du es nicht?

 

[Zuckersüß]

Ich muss mir dafür 2-3 Tage Zeit nehmen und das ganze an meine Bedürfnisse anpassen. 5 Pings pro Sekunde sind zu wenig. Ich muss das unter reelen Gegebenheiten prüfen (60 Pakete pro Sekunde).

Das hier war auch von mir:

 

[tango501]

Bislang gab es hier im Thread nur DSL Geräte. Jetzt kommt auch eine FRITZ!Box 6690 Cable dazu. Wie ist da der Zusammenhang?

 

[Ldwg2002]

How to setup smokeping in 20 minutes?

Nach einer halben Stunde hättest du schon 20 ICMP Echo Pings every 300s.
In der nächsten Stunde würdest du wissen ob sich die 2-3 Tage lohnen können.

Nach einer weiteren Suchanfrage könntest du 2-3 Tage die Füße hoch legen.

1. Increase Pings per Probe (Adjusting Probes)
By default, SmokePing might send 20 pings every 5 minutes (step). You can increase the number of packets (pings) sent in each cycle, or change the step to run more frequently.

1. Open the Probes configuration file (e.g., /etc/smokeping/config.d/Probes or the main /etc/smokeping/config).

So gilt: Wo kein Wille, da kein Weg. Lässt sich zusammenfassen: beratungsresistent. Deine mir unbekannte Kompetenz möchte ich nicht anzweifeln.

Tracking Latency and Packet Loss with SmokePing - Viel Erfolg weiterhin.

 

[Zuckersüß]

Wie ist da der Zusammenhang?

Störung auf der Leitung, die ich angefangen habe zu dokumentieren.

Ich frage mich, ob der Dienst von thinkbroadband auch brauchtbar wäre?

 

[Ldwg2002]

Störung auf der Leitung, die ich angefangen habe zu dokumentieren.

Unglaublich! Wie dokumentierst du? Punktuell und gefühlt?

Ich frage mich, ob der Dienst von thinkbroadband auch brauchtbar wäre?

Das fragen sich andere auch. Aus dieser Antwort (Deutsche Glasfaser) gefallen mir diese Abschnitte (Zitate) besonders gut

Grundsätzlich sind Messungen zu nur einem Ziel nicht aussagekräftig - es kann ja auch am Ziel liegen.

Dann kann die Quelle das Problem sein. Es ist und bleibt lediglich eine Verbindung, und da kann jeder Hop zwischendurch das Problem sein und absolut gar nichts mit deinem Anschluss zu tun haben.

Woher willst du wissen, dass es die letzte Meile ist? Das Problem kann doch auch viel später im Netz auftreten. Diese komische englische Seite kann dir das auch nicht sagen.

Das kann auch einfach ICMP Limiting sein. Das macht die DG gern, ich hab beim ersten Hop nach meinem Router immer 30 - 70% Paketverlust, dennoch ist der Rest des Traces sauber. Das ist vollkommen normal, das machen viele Provider so, und es ist keine Einschränkung in der Dienstqualität. Ob da ein Problem mit Paketverlusten im ersten Hop vorliegt, kann man erst anhand der Antworten nach dem ersten Hop ablesen - und zwar an allen bis zum Ziel. Denn die Paketverluste müssen dann gleichmäßig bei allen Folgehops auftreten, sonst ist es was anderes. Und darüber gibt dir deine komische englische Seite absolut gar keinen Hinweis.

Und darüber gibt dir deine "komische englische Seite" thinkbroadband.com absolut gar keinen Hinweis. Allgemeine Infos https://atlas.ripe.net/statistics/

Eben wegen "ICMP Limiting" steht smokeping auf 20 ICMP Echo Pings every 300s, um niemanden zu verärgern (evtl. ASSIA triggern). Spaßvögel sehen das gerne anders, wollen know-how durch Masse ersetzen. Eine Grafik mit "Viel Rauch um nichts" erfordert etwas know-how, besonders wenn man aus dem Stand heraus Fehler interpretieren möchte. Erfahrungen gibt es seit Jahrzehnten: Aus dem Alltag eines Sysadmin: Smokeping, Linux-Magazin 04/2005. Durch geschickte Auswahl der Ziele und kombiniert mit traceroute (oder auch WinMTR) erhält man Hinweise auf Störungen (im eigenverantworteten Netzbereich) oder kann eigene Fehler/Störungen verlässlich ausschließen.

P.S. Sind zwanzig Minuten seit #238 vorbei? Was zeigt deine Dokumentation? Siehst du schon Rauchzeichen? Oder bist du in #223

ein paar sehr gute (wirklich ausgezeichnet gute) Runden spielen.

In #226 gehst du sehr tief in technische Details, zeigst know-how, damit kannst du leicht einen Raspberry Pi mit (dem betagten) smokeping aufsetzen und durch geschickte Auswahl deiner Ziele ungewöhnliche Paketverlustraten mühelos aufdecken. Anschluss per LAN-Kabel wird nur der vollständigkeithalber erwähnt.

Ich vermute jedenfalls, dass mein Problem etwas mit Interleaving, Retransmissions, Queueing Delay usw. zu tun hat.

Seltsam, du hast den o2-Support mit der technischen Fehlerursache beeindruckt, konntest aber nicht überzeugen. Vielleicht möchte o2 eine belastbare objektive Fehlerbeschreibung und dann die Ursache des Fehlers selbst in ihrem (gemieteten) Netz suchen (lassen)?

Es kostet nur Bandbreite und scheint kosmetischer Natur.

Kenne ich als Überprovisionierung der Telekom. Damit kann der Support (bei vermutetem Paketverlust Layer 1/2/3) immer sagen: "Sie haben doch XY Mbit/s, wie im Vertrag." Paketverlust gibt es solange nicht, bis du verlorene Pakete im "fremden Netz des ISP" außerhalb deiner Verantwortung nachweisen kannst, fühlen reicht nicht.

Irgendeine Breitbandmessung.de ist nutzlos, wenn du wirklich Paketverlust (auf Layer 1/2 oder Überlast auf Layer 3) vermutest. Was zeigt dir dieser online Test an? https://de.packetlosstest.com/ Das ist die einzige Testseite die sowohl vor als auch nach dem T-Technikertermin bei mir zum smokeping-Monitoring stimmige Ergebnisse lieferte. Nach dem Technikerbesuch gab es "keine späten Pakete", "keinen Paketverlust", wie jetzt auch - alles i.O. Bereits verlinkt in _#142_ oder Details: https://www.ip-phone-forum.de/threads/paketverlust-5590-glasfaser.323700/#post-2613593

Allmählich vermute ich, dass "dein Problem" mit deiner Entfernung zum Bildschirm korreliert. Ein Layer 8 Problem? Bin ich mit dieser Vermutung alleine?