Inoffizielles Vodafone-Kabel-Forum

Wie hast du denn diese Werte gemessen?

Flole hat geschrieben: ↑01.11.2018, 15:52 Wie hast du denn diese Werte gemessen?

Mit dem Test von DSLReports.

Huch, jetzt hab ich in den Einstellungen mal 20/4 bei den Streams und 200 Mbit/s bei der Geschwindigkeit eingetragen, und HTTPS aktiviert.

Resultat: Ein A+ im Bufferbloat, die Geschwindigkeit im Downstream ist dafür etwas niedriger...
http://www.dslreports.com/speedtest/41186292

Bei mir sieht das (am Casa CMTS) alles super aus (und das trotz starker Auslastung des Segments), daher verstehe ich nicht wieso da einige Probleme mit haben. Hier ist die Analogabschaltung ja auch schon durch.....

Weniger Geschwindigkeit heißt ja, das der Bufferbloat gar nicht gemessen werden kann (da er ja nur Auftritt wenn die Puffer auch benutzt werden müssen, was sie nicht werden wenn die Daten schnell genug "abtransportiert" werden können).

Flole hat geschrieben: ↑01.11.2018, 16:14Weniger Geschwindigkeit heißt ja, das der Bufferbloat gar nicht gemessen werden kann (da er ja nur Auftritt wenn die Puffer auch benutzt werden müssen, was sie nicht werden wenn die Daten schnell genug "abtransportiert" werden können).

Blöde Frage: Das hängt doch nicht von der gebuchten Geschwindigkeit ab, sondern davon, was die Router im Netz noch an Kapazitäten haben, oder?

Die Frage ist gar nicht so blöd, und es kommt drauf an. Um das genau zu verstehen muss man sich erstmal vor Augen führen, was Bufferbloat überhaupt ist: Daten werden immer in Form von Paketen übertragen. Wenn (aus irgendeinem Grund) nun eine Leitung versucht mehr Daten zu übertragen als möglich (also das was eigentlich immer passiert), dann werden Daten in den Puffer geschrieben.

Das Phänomen Bufferbloat ist nun folgendes: Wenn die Daten in einem Puffer landen, kann es passieren das sie dort länger gefangen sind. So kommen Pakete in der falschen Reihenfolge an, einige haben sehr hohe Laufzeiten und einige werden eventuell sogar verworfen.

Kurzum: Bufferbloat kann überall auftreten, wo eine Geschwindigkeitsänderung stattfindet. In der Regel ist dies am Endgerät bzw. kurz davor (das Netz sollte ausreichende Kapazitäten haben). Es gibt außerdem verschiedene Verfahren um die Geschwindigkeit einer TCP Verbindung zu reduzieren und dabei die Buffer wenig zu nutzen. Ich denke mit der Vermutung das diese zwar beim drosseln auf die jeweilige Soll-Geschwindigkeit angewendet werden, nicht jedoch an einer Stelle wo unbekannt ist wie schnell Daten übertragen werden können, liege ich zumindest in der richtigen Ecke.

Nicht erst bei TCP. FlowControl aka IEEE 802.3x geschieht schon auf dem Ethernetlayer. Gibts sowas eig. auch für DOCSIS ?

sch4kal hat geschrieben: ↑01.11.2018, 20:33 Nicht erst bei TCP. FlowControl aka IEEE 802.3x geschieht schon auf dem Ethernetlayer. Gibts sowas eig. auch für DOCSIS ?

Ja... Damit wird z.B. die Telefonie via VoC gegenüber "normalem" Datenverkehr priorisiert.

Flole hat geschrieben: ↑01.11.2018, 16:40 Kurzum: Bufferbloat kann überall auftreten, wo eine Geschwindigkeitsänderung stattfindet. In der Regel ist dies am Endgerät bzw. kurz davor (das Netz sollte ausreichende Kapazitäten haben). Es gibt außerdem verschiedene Verfahren um die Geschwindigkeit einer TCP Verbindung zu reduzieren und dabei die Buffer wenig zu nutzen.

Was das ganze so kompliziert macht, ist, dass gute Pufferung für manche Anwendungen durchaus sehr wünschenswert ist. So hat das Arris-CMTS, als es noch mehrere Sekunden pufferte, zu hervorragend stabilen Download-Datenraten geführt, bei mir die 212Mbit/s durchgängig voll am Anschlag mit einem einzelnen Download. Dafür waren dann "interaktive" Anwendungen eben um mehrere Sekunden verzögert, was gar nicht wünschenswert ist.

Mit dem Softwareupdate für das Arris gab es zwar keine schlechte Bufferbloat-Noten mehr - aber dafür habe ich danach nie wieder die 212Mbit/s bis zum Anschlag ausreizen können.

Es gibt übrigens schon seit Jahren unzählige Papers zu dem Thema, Stichwort "Active Queue Management" - wie man die Puffer eben so managet, dass Downloads stabile Datenraten liefern, und interaktive Anwendungen niedrige Latenzen. Dass das nicht schon längst "standardmässig" umgesetzt ist, zeigt wohl, wie kompliziert die Thematik ist. Jeder Algorithmus hat wohl irgendeine "Macke", sodass man fast zu dem Schluss kommen könnte, dass das alles ein Nullsummenspiel ist...

Wenn ein längerer Download stattfindet, ist eine sinnvolle Pufferung ja in Ordnung. Aber wenn Lags aka "BufferBloat" schon im Idle und bei kleineren Downloads auftreten, oder es zu Anspruchsverzögerungen, zu langsam steigen Datenraten und horrenden RoundTrip-Times oder 30s-Hängern kommt, hört der Spass auf!

Da wartet man 'gerne' insgesamt mal 3-5s auf den Start des Aufbaus einer Website, oder Posts im Forum lassen das Browser-Tap 20-50s einfrieren. Und insgesamt ist die gefühlte Performance lausig, inkl. erheblichen Einbrüchen bei den Datenraten.