TBB Graph sieht viel besser aus, Netzseitige Anpassung?

[Der.Ede]

Nutzt von euch jemand die FritzLabor für die 6591 Cable?
Seit ich die Version nutze, zeigt TBB nur noch Rot an.
Firewall im Stealth Mode ist deaktiviert und IP ist auch erreichbar.

Bei mir sieht das seit dem 10.06. @ 09:00 Uhr genauso aus. Habe auch nichts verändert.
Das Monitoring habe ich vor zwei Tagen deaktiviert und vorhin wieder aktiviert, schauen wir mal wie es morgen aussieht...

 

[MartinP_Do]

Wenn d

Ich nutze eine Domain (CNAME auf die myfritz Adresse).
Ich habe aber gerade mal einen anderen Test gemacht und den Monitor mit der gleichen Adresse neu hinzugefügt, und dort wird etwas angezeigt.
ich gehe mal davon aus, dass mit dem alten Graphen etwas nicht stimmt.
Ist aber schon komisch, dass es genau ab Einspielung der Labor-Version passiert ist (oder einfach nur dummer Zufall?)

Das fügt auf Thinkbroadband-Seite natürlich eine Stufe der Komplexität hinzu. Ich habe vorsichtshalber direkt die IP-Adressen aus der entsprechen Fritzbox Web-Interface-Seite genommen so muss ich mich nicht auf die TBB Namensauflösung verlassen. Da kann man dann DNS Probleme ausschließen - außerdem will ich bei meinem Dual Stack Anschluss natürlich IPv4 und -6 testen. Wüsste nicht, wie man da beim DNS gezielt selektieren könnte ... gibt keinen entsprechenden IPv4 IPv6 Haken in der TBB konfiguration...

 

[MartinP_Do]

Es wäre möglich, dass Thinkbroadband nur EINMALIG die DNS-Auflösung macht, wenn der Monitor angelegt wird, und ab dann unter der Motorhaube mit der dabei ermittelten IP-Adresse weiterarbeitet ...
Interessant wäre, was passiert, wenn Du den alten Monitor editierst

 

[why_]

Es wäre möglich, dass Thinkbroadband nur EINMALIG die DNS-Auflösung macht, wenn der Monitor angelegt wird, und ab dann unter der Motorhaube mit der dabei ermittelten IP-Adresse weiterarbeitet ...

Das ist nicht der Fall.

 

[blu3bird]

Es wäre möglich, dass Thinkbroadband nur EINMALIG die DNS-Auflösung macht, wenn der Monitor angelegt wird, und ab dann unter der Motorhaube mit der dabei ermittelten IP-Adresse weiterarbeitet ...
Interessant wäre, was passiert, wenn Du den alten Monitor editierst

Ich habe den Monitor geändert und die IPv4-Adresse direkt eingegeben. Nun funktioniert die Anzeige wieder (kein Timeout).
Ich habe den Monitor wieder auf die DNS-Adresse geändert, was ebenfalls funktioniert.

Eventuell schreibe ich mir ein Script, das mir die IPv4- und IPv6-Records (A/AAAA) auf meiner Domain aktualisiert (eigene Nameserver + eigene Domain).

 

[blu3bird]

Wollte meinen Beitrag heute nochmal editieren, aber keine Möglichkeit.

Graph mit DNS:





Graph IPv6:



Graph IPv4:


Ich würde das gerne aus der technischen Sicht verstehen.

 

[MartinP_Do]

Schwer zu sagen, was da klemmt. Scheint mir nicht auf Anschlusseite zu liegen, da unterschiedliche Muster.
Interessant ist, dass das "DNS" Muster und das "IPv6" Muster in etwa invertiert zueinander sind: Die Rot-Blöcke lösen sich zeitlich nach Augenschein ab.
Vielleicht wird der Abstand der Pings aus gleicher Quelle bei zwei aktiven Monitors auf die gleiche IPv6 Adresse zu kurz, und ein Sicherheitsmechamismus der Fritzbox schlägt an.

 

[blu3bird]

Schwer zu sagen, was da klemmt. Scheint mir nicht auf Anschlusseite zu liegen, da unterschiedliche Muster.
Interessant ist, dass das "DNS" Muster und das "IPv6" Muster in etwa invertiert zueinander sind: Die Rot-Blöcke lösen sich zeitlich nach Augenschein ab.
Vielleicht wird der Abstand der Pings aus gleicher Quelle bei zwei aktiven Monitors auf die gleiche IPv6 Adresse zu kurz, und ein Sicherheitsmechamismus der Fritzbox schlägt an.

Möglich wäre es.
TBB ist damit aber für mich "unbrauchbar".

 

[MartinP_Do]

Läge dann ja an der Fritzbox.

 

[why_]

Ich habe weder mit IPv4 noch IPv6 und Thinkbroadband irgendeine Problem. Allerdings habe ich auch ein Arris 3500b und einen Router den ich unter Kontrolle habe. Vielleicht mal bei AVM anfragen was die da für einen Müll machen?

 

[MartinP_Do]

Ich habe auch eine Fritzbox,sogar ein Gerät vom Provider. Keine Probleme mit Thinkbroadband.

 

[robert_s]

Ich habe weder mit IPv4 noch IPv6 und Thinkbroadband irgendeine Problem. Allerdings habe ich auch ein Arris 3500b und einen Router den ich unter Kontrolle habe. Vielleicht mal bei AVM anfragen was die da für einen Müll machen?

AVM bzw. vielleicht auch schon der Puma7 messen Pings auf den Router wohl nicht so viel Wert bei wie Broadcom.

Ich habe hier eine Fritz!Box 6690 Cable (MaxLinear Puma7) und einen Vodafone Ultra Hub 7 (Broadcom BCM3392) parallel am Kabel, beide mit Dual Stack, mit dicht beieinander liegenden IPv4-Adressen (letzte Stelle unterscheidet sich nur um 8). DOCSIS-Signal ist fehlerfrei (unkorrigierte Fehler in der Fritz!Box tagelang auf 0), und ein rausgehender Ping über die Fritz!Box zeigt auch über länger Zeit keine verlorenen Pakete, d.h. beide Router dürften dasselbe Routing von TBB haben, und über dasselbe fehlerfreie DOCSIS-Segment zum Kabelrouter kommen.

Aber der Graph der Fritz!Box 6690 Cable sieht dann so aus:

Und der GLEICHZEITIGE Graph des Ultra Hub 7 so:

Da zu beiden aber die Pings gleichermaßen durchkommen sollten, und der Fritz!Box beim Senden nichts verlorengeht, komme ich zu dem Schluss, dass die Fritz!Box die Ping-Requests bekommt, aber nicht immer darauf antwortet. Was ja an sich kein Problem ist, denn außer TBB hat man keine wirkliche Verwendung für Pings auf den Router.

Eigentlich zeigt das nur, dass TBB nicht wirklich zur Qualitätsbemessung taugt, denn bei der Latenzmessung des Ookla-Speedtests kommt die Fritz!Box während des Uploads auf stabile 5ms mit Jitter <1ms, während der Ultra Hub zwischen 10-20ms herumzappelt. Also LLD kann die Fritz!Box deutlich besser als der Ultra Hub 7. Und das ist praxisrelevant. Die TBB-Pings sind es nicht.

 

[racekos]

Die Fritzboxen haben halt ein Rate Limit von ca. 1 Ping pro Sekunde.

Der Graph von @robert_s zeigt das recht typische Ergebnis. Wenn man das Monitoring per Thinkbroadband mit einer Fritzbox nutzen will, würde ich deshalb immer IPv6 empfehlen (wenigstens zusätzlich). Da tritt das üblicherweise nicht auf, weil es weniger Hintergrundrauschen gibt, das den Rate Limiter auslöst.

 

[robert_s]

Die Fritzboxen haben halt ein Rate Limit von ca. 1 Ping pro Sekunde.

Ah, stimmt! Das kann ich mit pings über den Ultra Hub 7 auf die Fritz!Box nachvollziehen. Pinge ich alle 100ms, wird nur jeder 10. Ping beantwortet.

Pinge ich umgekehrt über die Fritz!Box auf den Ultra Hub 7 alle 100ms, wird jeder 2. Ping beantwortet. Ändere ich das Intervall auf 200ms, beantwortet der Ultra Hub 7 alles.

Also zumindest die Unterschiede bei den Paketverlusten lassen sich wohl dadurch erklären, dass die Fritz!Box ein Rate Limit von 1 Ping pro Sekunde verwendet, der Ultra Hub dagegen eines von 1 Ping alle 200ms...

P.S.: Wenn man mal in die gespeicherten Einstellungen der Fritz!Box reinschaut, sieht es so aus als könnte man vielleicht das Rate Limit zumindest für IPv6 dort anpassen?

 } { enabled = yes; name = "icmpEchoRequest"; type = qos_cfg_system; iface = qos_lan; rule = "ip.version 6 icmp.type 128"; packets = 10; interval = 1s; early = 0; } { enabled = yes; name = "icmpEchoReply"; type = qos_cfg_system; iface = qos_lan; rule = "ip.version 6 icmp.type 129"; packets = 10; interval = 1s; early = 0; } {

 

[why_]

Eigentlich zeigt das nur, dass TBB nicht wirklich zur Qualitätsbemessung taugt, denn bei der Latenzmessung des Ookla-Speedtests kommt die Fritz!Box während des Uploads auf stabile 5ms mit Jitter <1ms

TBB ist da aussagekräftiger als was der Ookla-Speedtests während des uploads anzeigt, normale Nutzer nutzen ihren Anschluss eher während da quasi nichts an traffic drüber geht und nicht während der upload bei 100% Auslastung ist. Wenn ich streame komme ich auch nur auf 40 mbps dauerlast des uploads, weil bei mehr bei scenen wechsel durch bitrate spikes sonst frames verworfen werden.

 

[robert_s]

TBB ist da aussagekräftiger als was der Ookla-Speedtests während des uploads anzeigt, normale Nutzer nutzen ihren Anschluss eher während da quasi nichts an traffic drüber geht und nicht während der upload bei 100% Auslastung ist.

Es gibt außer Diagnose keine Anwendung, welche ICMP Echo Requests verwendet, von daher sagt TBB bei den Fritz!Boxen primär etwas über deren Rate Limiting aus, aber nichts über die Qualität bei tatsächlichen Anwendungen.

Der Ookla-Speedtest sagt dagegen sehr viel über das Buffer Management des Kabelrouters aus, d.h. wie gut der Anschluss noch für interaktive Anwendungen nutzbar ist, während man den Upstream auslastet. Gerade bei dem "dünnen" Upstream von Kabel-Internet können Uploads ja auch mal länger dauern, und da ist das schon gut, wenn man das Internet derweil noch gut anderweitig nutzen kann.

 

[why_]

Es gibt außer Diagnose keine Anwendung, welche ICMP Echo Requests verwendet, von daher sagt TBB bei den Fritz!Boxen primär etwas über deren Rate Limiting aus, aber nichts über die Qualität bei tatsächlichen Anwendungen.

Fritzboxen droppen den request, es gibt aber keine implementierte logik die replies runter priorisiert, von daher Jitter auf der Leitung sieht man dadurch dann doch sehr wohl.

Der Ookla-Speedtest sagt dagegen sehr viel über das Buffer Management des Kabelrouters aus, d.h. wie gut der Anschluss noch für interaktive Anwendungen nutzbar ist, während man den Upstream auslastet. Gerade bei dem "dünnen" Upstream von Kabel-Internet können Uploads ja auch mal länger dauern, und da ist das schon gut, wenn man das Internet derweil noch gut anderweitig nutzen kann.

99,9% der Nutzungszeit wird dieser Zustand nicht erreicht, daher ja gutes Buffer Managment ist wichtig, aber das die Grundlatenz niedrig ist, ist sehr viel wichtiger als der niedrigste erreichbare wert im bestmöglichen Szenario dafür. Von daher wenn man den ookla speedtest unbedingt ran ziehen will sind die relevanten werte Idle Latency mit Jitter und high, sowie von Down- und Upload jitter und high. Low ist völlig irrelevant.

 

[robert_s]

99,9% der Nutzungszeit wird dieser Zustand nicht erreicht, daher ja gutes Buffer Managment ist wichtig, aber das die Grundlatenz niedrig ist, ist sehr viel wichtiger als der niedrigste erreichbare wert im bestmöglichen Szenario dafür. Von daher wenn man den ookla speedtest unbedingt ran ziehen will sind die relevanten werte Idle Latency mit Jitter und high, sowie von Down- und Upload jitter und high. Low ist völlig irrelevant.

Die "Grundlatenz" ist doch genau der niedrigste erreichbare Wert. Was da variabel oben drauf kommt ist der Jitter.

Und natürlich ist diese "Grundlatenz" relevant, denn wenn man z.B. zum ersten Hop nie unter 100ms kommt, dann macht's ein Jitter von 20ms auch kaum schlechter.

Liegt die "Grundlatenz" dagegen bei 3-4ms, dann fällt ein Jitter von 10ms schon ganz anders ins Gewicht.

 

[Der.Ede]

Wie aussagekräftig haltet ihr den Test von Cloudflare?

https://speed.cloudflare.com/

btw. Mein TBB Monitoring geht wieder, und zeigt Werte an wie sie davor waren, also gab es doch keine Veränderung

 

[why_]

Die "Grundlatenz" ist doch genau der niedrigste erreichbare Wert. Was da variabel oben drauf kommt ist der Jitter.

Die Grundlatenz ist bei Ookla die Idle Latency, du gehst allerdings immer auf die low latency während des uploads und der Wert ist irrelevant.

 

[robert_s]

Die Grundlatenz ist bei Ookla die Idle Latency,

Dieses Wort benutzt Ookla nicht. Ich sehe da "Ping ms" mit den Unterschriften "Leerlauf", "Herunterladen" und "Hochladen".

Wie kommst du also zu dieser Definition von "Grundlatenz" (und diesem Wort)?

du gehst allerdings immer auf die low latency während des uploads und der Wert ist irrelevant.

Beides falsch. Ich beobachte den Verlauf der Latenz des Ookla Upload-Tests mit dem offiziellen Kommandozeilentool, also nicht nur den minimalen Wert.

Und da sehe ich eben, dass bei einem Kabelmodem mit dem Broadcom BCM339x die Latenz wild zwischen 10 und 20ms herumzappelt, während sie sich mit der Fritz!Box auf stabile 5ms mit minimalem Jitter einstellt.

Auch wenn man die Messmethode von ookla anzweifelt, da mit demselben Tool und denselben Gegenstellen im selben Kabelsegment so unterschiedliche Ergebnisse erzielt werden, sagt das für mich etwas über die Qualität der DOCSIS LLD-Implementierung aus.

 

[why_]

Dieses Wort benutzt Ookla nicht. Ich sehe da "Ping ms" mit den Unterschriften "Leerlauf", "Herunterladen" und "Hochladen".
Wie kommst du also zu dieser Definition von "Grundlatenz" (und diesem Wort)?

Das ist die Nomenklatur von der speedtest cli von hier https://www.speedtest.net/de/apps/cli was du nutzt das das bei dir anders angezeigt wird keine Ahnung.

So sieht der offizielle ookla cli speedtest aus.

./speedtest

Speedtest by Ookla

Server: TeleData GmbH - Friedrichshafen (id: 69185)
ISP: Vodafone Germany
Idle Latency: 24.64 ms (jitter: 3.59ms, low: 21.45ms, high: 26.56ms)
Download: 1051.21 Mbps (data used: 1.3 GB)
113.99 ms (jitter: 34.25ms, low: 19.16ms, high: 231.68ms)
Upload: 48.83 Mbps (data used: 45.7 MB)
26.97 ms (jitter: 5.69ms, low: 17.54ms, high: 293.03ms)
Packet Loss: 0.0%
Result URL: https://www.speedtest.net/result/c/id

Auch wenn man die Messmethode von ookla anzweifelt, da mit demselben Tool und denselben Gegenstellen im selben Kabelsegment so unterschiedliche Ergebnisse erzielt werden, sagt das für mich etwas über die Qualität der DOCSIS LLD-Implementierung aus.

Dann erkläre mal warum DOCSIS LLD nur funktionieren sollte während der upload bei 100% Auslastung ist und sonst nichts machen sollte.

 

[robert_s]

Dann erkläre mal warum DOCSIS LLD nur funktionieren sollte während der upload bei 100% Auslastung ist und sonst nichts machen sollte.

DOCSIS LLD besteht aus mehreren Bestandteilen, vor allem:

1. CMTS-seitigem Advanced Queue Management
2. CM-seitigem Advanced Queue Management
3. CMTS- (bzw. PHY-) seitigem Proactive Grant Service

Bei Vodafone Kabel ist derzeit nur Punkt 2 aktiviert, es fehlt sowohl das CMTS-seitige Advanced Queue Management als auch der Proactive Grant Service.

Das CMTS-seitige Advanced Queue Management bräuchte man, damit auch beim Download-Speedtest die Latenz niedrig bleibt. Weil das fehlt, schnellt die Latenz beim Download-Speedtest auf bis zum 200ms hoch.

Der CMTS-seitigen Proactive Grant Service würde den Kabelmodems auch unangefordert Sendemöglichkeiten zur Verfügung stellen, damit vor allem die Idle-Latenz niedrig bleibt. Dafür braucht man aber auch ausreichend überschüssige Kapazität im Upstream, deshalb wird allgemein davon ausgegangen, dass das erst mit High-Split realisierbar ist.

Das CM-seitige Advanced Queue Management implementieren die Kabelmodems schon länger, wurde aber früher vom CMTS stets deaktiviert. Jetzt ist Vodafone immerhin so weit, dass auch zu aktivieren, aber als nur einer von den 3 Bausteinen kann das eben nur in dem begrenzten Fall funktionieren, dass ein Upload für regelmäßige Sendemöglichkeiten sorgt (ohne Upload braucht es eben den Proactive Grant Service dafür), weil dann das Advanced Queue Management die non-Buffering Pakete bevorzugt versendet und damit für stabile niedrige Latenzen sorgt.

 

[robert_s]

Aber der Graph der Fritz!Box 6690 Cable sieht dann so aus:

Und der GLEICHZEITIGE Graph des Ultra Hub 7 so:

Ich habe da einen Fehler gemacht - Die Voraussetzungen für beide waren doch nicht gleich: An der Fritz!Box hing noch die Vodafone Netztester-Box, welche regelmäßig Speedtests ausführt, und damit offenbar für diese "Ping Spikes" gesorgt hat.

Ich habe die Netztester-Box jetzt mal an den Ultra Hub umgehängt, und damit kehren sich auch die Bilder um.

Jetzt sieht der Graph der Fritz!Box 6690 Cable so aus:

Und der des Ultra Hub 7 so:


Also unter wirklich gleichen Voraussetzungen unterscheiden sich beide gar nicht mehr so sehr. Wobei die regelmäßigen Spikes durch die Netztester-Box beim Ultra Hub 7 deutlich höher ausfallen als bei der Fritz!Box. Was ja auch die Beobachtung bestätigt, dass die Fritz!Box beim DOCSIS LLD deutlich besser aussieht als Broadcom BCM339x Geräte.

 

[MartinP_Do]

Bei mir sind die IPv4 und IPv6 (echter Dual Stack) sehr unterschiedlich.
Bei IPv4 gibt es Packet-Loss...


Bei IPv6 nicht sichtbar ...


Harmonic CMTS (siehe Signatur)