Andere/Übergreifend Bufferbloat, wer, wie, was, wieso, weshalb, warum

[pufferueberlauf]

Das hier ist ein "Anker-Post" fuer Diskussionen rund um Bufferbloat oder Latenz-unter-Last-Zunahme.

Bufferbloat tritt üblicherweise dann auf wenn an Flaschenhals-Übergängen (neudeutsch "Bottleneck") von schnell zu langsam die Warteschlange (auch Pufferspeicher, neudeutsch "Buffer") zu groß ist und/oder zu schlecht verwaltet wird (neudeutsch "over-sized and under-managed"). Eine solche Situation tritt z.B. üblicherweise bei Internetzugängen auf da die Geschwindigkeit jedes einzelnen Anschlusses i.d.R. geringer ist als die Geschwindigkeit mit der das Edge-Element* des ISPs an dessen Backbone/das Internet angeschlossen ist. In Gegenrichtung passiert das im Modem/Router des Endkunden, da interne Netzwerke heute oft >= 1 Gbps-Ethernet verwenden während der Internet-Uplink meist << 1 Gbps ausfällt.

Warum kommt es genau zu dieser Latenzerhöhung?
"Dumme" Pufferspeicher sind meist als First In – First Out (FIFO; altdeutsch "der Reihe nach") organisiert, d.h. Pakete kommen am Ende dazu und werden Vorne weggenommen, d.h. jedes Paket wird erst dann weitergesendet wenn alle die vor ihm in der Warteschlange "sitzen" versendet wurden. Wenn jetzt die Neuzugangsrate am Hinter-Ende höher ist als die Senderate am Vorder-Ende, dann wird der Puffer immer voller, solange bis der Puffer die maximale konfigurierte Größe erreicht, dann werden neu dazukommende Pakete einfach verworfen (Taildrop). (Dieses Verwerfen führt bei TCP dazu, dass in betroffenen Flows auf einmal Pakete fehlen, was der Empfänger jedoch erst bemerkt wenn nach einem verlorenen Paket noch zwei weitere Pakete mit höherer Sequenznummer reinkommen, dann benachrichtigt er den Sender dass Pakete fehlen was der damit beantwortet, dass er die Senderate drosselt.) Fuer jedes Paket das versendet wird ensteht wieder Platz fuer ein neues Paket im Puffer. Solange der Puffer jetzt stark gefüllt ist wird jedes Paket zusätzlich fuer die Zeit verzögert die es braucht die Pakete zu versenden die vor ihm im FIFO liegen. Wenn der Puffer "gut" dimensioniert war, dann ist diese zusätzliche Latenz klein und "verschmerzbar", ist der Puffer aber überdimensioniert kann die zusätzliche lastabhängige Latenz so gross werden, dass interaktive/zeitkritische Anwendungen Probleme bekommen (beobachtet wurden Latenzen bis in den Sekundenbereich hoch). Weil mit der Zeit Speicher immer günstiger wurde (zumindest einfaches RAM fuer Puffer, Assoziativspeicher CAM/TCAM ist nach wie vor so teuer, dass er sparsam verwendet wird) haben die meisten Netzkomponenten auch immer größere Puffer spendiert bekommen (nach der Devise viel hilft viel) auch weil das hilft das bislang oft wichtigste Qualitätsmass den Durchsatz hoch zu halten. Die Puffer sind über die Zeit quasi angeschwollen, neudeutsch buffer-bloat...


Als Loesungen bieten sich an:
a) die Puffergroesse zu reduzieren
b) die existierenden Puffer besser zu verwalten (was darauf hinaus laeuft den Traffic-Quellen zu signalisieren, dass sie abbremsen sollen bevor der Puffer ueberfuellt ist, und/oder jedem Flow seinen eigenen Puffer zu Verfügung zu stellen und beim Pufferleeren die Egress-Kapazitaet fair zwischen den Flows zu verteilen)

In der Realität bietet sich eigentlich nur b) an, da a) das Problem hat, dass die optimale Puffergroesse letztlich von der RTT (aka "dem Ping") der einzelnen Flows abhängt, größere RTT erfordert größere Puffer, aber Puffer die fuer RTT Xms ideal dimensioniert sind fuehren bei RTT 2*Xms dazu, dass weniger Durchsatz erreicht wird.
Für b) existieren mehrere Ansätze, fuer interessierte Endnutzer mit Linux-basierten Routern bieten sich fq_codel und cake an, beide können unter OpenWrt einfach ueber sqm-scripts/luci-app-sqm ausprobiert werden (bzw. fuer OpenWrt Snapshots Anfang 2022 auch mit qosify stat sqm) hier die OpenWrt Konfigurationsempfehlungen: https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm und https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm-details.


Wie teste/messe ich Bufferbloat?

Ueber den Browser:

a) Der dslreports speedtest war lange Zeit die einzige oeffentiche Option, allerdings sind da im Laufe der Zeit immer mehr Probleme aufgetaucht/Messknoten verkustig gegangen, momentan kann man i.d.R. noch ganz passabel messen, wenn man HTTP statt HTTPS verwendet (die Zertifikate scheinen abgelaufen zu sein). Dafür den "use http"-Link in der rechten oberen Ecke des Speedtest-Widgets klicken. Hier eine englische Konfigurationsanweisung um mehr aus dem Test herauszuholen: https://forum.openwrt.org/t/sqm-qos...dslreports-speedtest-bufferbloat-testing/2803

b) Waveform's Bufferbloat-Test: https://www.waveform.com/tools/bufferbloat (nach abgeschlossenem Test kann man eine CSV Datei mit den Durchschnittsgeschwindigkeiten, so wie allen individuellen Latenzmessungen der drei Phasen runter-laden).

c) Netflix https://fast.com (den kann man so konfigurieren, dass der Test mindestns 30 Sekunden laueft und auch den Upload testet)

d) seit Mai 2022 enthaelt Oooklas speedtest.net App fuer Android und iOS eine "Detailed result" Ansicht bei der die Latenz auch unter Last fuer beide Richtungen getrennt gemessen und reportiert wird, bis jetzt jedoch noch nicht im Web-Client, in der CLI Anwendung oder in der Macos-App...
(der reportierte Latenzwert ist der Interquartil-Mittelwert, also berechnet aus dem mittleren 50% der Messwerte von 25-75%)


Von diesen haben a) und b) die besten/detailliertesten Informationen zur Latenz-unter-Last, die Entwickler von fast.com sind sich dessen jedoch bewusst und ziehen vielleicht irgendwann mal nach. Ein Problem ist bei Browsertests allerdings, dass die Resultate nicht nur das Netz sondern auch die Performance des Browsers und dessen "Responsiveness" testen, dafuer sind die schnell und einfach mit verschiedenen Endgeraeten durchzufuehren...



Von der Kommandozeile:

a) flents (https://flent.org) RRUL test, allerdings braucht man da die Adresse eines Netperf-Servers als Gegenstellen (kann man selber per VPS aufsetzen).

b) DIY: man kann die Latenz sehr gut entweder mit MTR oder mit gping betrachten, und muss nur waehrend der Messung eine saturierende Last erzeigen, z.B. durch Verwendung eines der Browser Speedtest (siehe oben, aber auch Ooklas Speedtest.net Nodes sind geeignet, oder breitbandmessung.de, und eigentlich jeder andere Speedtest auch) oder öffentlicher iperf3 Server.
Der Trick ist halt dass man die Latenzmessung startet und beobachtet bevor, waehrend und nach der Lasterzeugung dann kann man per Augenmass abschaetzen um wieviel sich die Latenz unter Volllast erhoeht.

Vom Mac:
Apple hat in aktuellem iOS und Macos Monterey einen neuen Netzwerktest integriert (networkQuality, siehe z.B. https://stadt-bremerhaven.de/speedy-grafische-oberflaeche-fuer-apples-networkquality/) der ein Bufferbloat korreliertes Mass, RPM genannt, liefert. Unter iOS ist das allerdings wohl nicht so einfach zu aktivieren, kann ich aus Ermangelung eines aktuellen iOS Gerätes leider nicht ausprobieren. Eine Go-Variante des Clienten befindet sich auf https://github.com/network-quality/goresponsiveness in Entwicklung, ist aber Stand 2022 04 13 wegen eines Go-Bugs nicht zuverlässig.




*) Das kann unterschiedliche Namen haben, CMTS bei Kabel/DOCIS, BRAS/PoP/BNG bei XDSL und FTTH, je nach ISP und Netzstruktur, die Gemeinsamkeit ist, dass an der Stelle die Vertragsrate durch einen Traffic-Shaper oder Traffic-Policer begrenzt wird.

Mmmh, das klingt interessant, wo kann ich weitere Informationen finden?
https://www.bufferbloat.net/projects/

 

[robert_s]

Gibt es eigentlich noch einen (Speed)Test, der den Buffer Bloat brauchbar misst? dslreports hat(te) ja einen guten, aber der findet bei mir keine Testserver mehr?!?

 

[B3CKS]

Ich nutze unter Windows: Waveform. DSL reports funktioniert bei mir meist mit dem Server aus Zürich.

LG

 

[pufferueberlauf]

dslreports hat(te) ja einen guten, aber der findet bei mir keine Testserver mehr?!?

Selbst wenn Du auf den "use http"-Link in der rechten oberen Ecke des Speedtest-Widgets klickst?

Ich nutze unter Windows: Waveform.

+1; das ist ein relativ guter Test, die Darstellung der Latenzen ist nicht schlecht, wenn auch fuer's debugging der exakte Zeitverlauf hilfreicher ist wie ihn der dslreports-Test anzeigt (man kann die Latenz-Daten beim Wavefront-Test allerdings als CSV runterladen und dann selber den Zeitverlauf darstellen).

 

[0-8-15 User]

+1; das ist ein relativ guter Test

Ja, wobei der Test an meinem Telekomanschluss nicht immer zuverlässig funktioniert.

 

[pufferueberlauf]

Der Waveform Test nutzt IIRC die Cloudflare Infrastruktur als Datenquelle (Download) und Datensenke (Upload) das funktioniert oft gut, aber halt nicht immer. Wobei ich jetzt nicht von regelmäßigen Problemen zwischen Cloudflare und Telekom wüsste (wuerde mir als O2-Kunde aber schwerlich auffallen).

 

[B3CKS]

Ja, wobei der Test an meinem Telekomanschluss nicht immer zuverlässig funktioniert.

Funktioniert an meinem Vodafon only DSL 100 Anschluss perfekt. Hab viel gelernt um mein Bufferbloat niedrig zu halten, da ich Street Fighter spiele. Da kommts halt wirklich auf einen stabilen Ping an. Ich hab mein Gbit Lan auf 100Mbit runtergedreht und nun ist selbst bei Vollauslastung der Leitung noch genug Luft, sodass mein Ping nicht über 50 spikt. (Minimum sind 15) Natürlich sind Downloads jetzt etwas langsamer, aber die 5 Minuten hab ich dann auch noch. (...). Mir haben diese Tests viel geholfen.


LG

 

[0-8-15 User]

Woran es krankt weiß ich nicht, aber weder dslreports.com noch waveform.com liefern bei mir derzeit repräsentative Ergebnisse (siehe Anhang).

---

Mit speedtest.net komme ich auf folgende Latenzen unter Last (im Down- bzw. Upload):

--- 8.8.8.8 ping statistics ---
rtt min/avg/max/mdev = 30.894/36.133/41.923/2.601 ms

--- 8.8.8.8 ping statistics ---
rtt min/avg/max/mdev = 70.464/80.473/85.815/3.790 ms

---

Und hier eine ausführliche Analyse mit Flent (und einem Hetzner CPX11 als Gegenstelle):

(fq_codel_xxx_30 bedeutet, dass der Traffic Shaper nur im Upload aktiv war)

(fq_codel_100_xx bedeutet, dass der Traffic Shaper nur im Download aktiv war)

 

[floh667]

der waveform test funktioniert bei mir gar nicht gut. Liefert miese DL Raten und misst hohen buffer bloat. DSLreport funktioniert besser und manuelle latenz tests während einem speedtest.net durchlauf (bei >800mbit) liefert noch die besten latenzwerte (zwischen 20 und 50ms)

 

[pufferueberlauf]

Und in Wirklichkeit liegt der Bufferbloat im Download bei ~ 40 ms und im Upload bei ~ 110 ms.

Bei Dslreports ist es hilfreicher den "Results + Share" Button zu klicken und einen der Links zu posten dann kann man auch die Details sehen, Und beim Waveformtest ist der Link auch besser als ein Screenshot...

der waveform test funktioniert bei mir gar nicht gut. Liefert miese DL Raten und misst hohen buffer bloat. DSLreport funktioniert besser und manuelle latenz tests während einem speedtest.net durchlauf (bei >800mbit) liefert noch die besten latenzwerte (zwischen 20 und 50ms)

Ja ist halt so, dass Browsertests schon auch immer ein Test des Bowsers selber sind, das liegt in der Natur der Sache.

 

[B3CKS]

Bufferbloat ist ja nichts anderes, als das es misst, wie hoch deine Latenz ist, wenn der Downloadkanal am Anschlag steht und was in dem Moment dein Ping und dein Upload sagt. Das ganze gilt dann auch für den Upload.

Nun ist es so, dass bei allen Anbietern es so eingestellt, dass man immer das Maximum an Download und Upload bekommt. Mit einer Fritz Box zum Beispiel, kann man die Werte so verändern, dass man NUN nicht mehr das Maximum an Download und Upload bekommt. Das macht die Leitung etwas langsamer, dafür aber stabiler und der Bufferbloat wird geringer. Im Großen und Ganzen eignet sich solch eine Einstellung, wenn viele Leute eine Leitung benutzen, oder für Low-Latency-Gaming.
Wenn man nur eine 100Mbit Leitung hat, so wie ich kommen da etwa 116Mbit durch. Wenn ich mein Netzwerk auf 100MBit begrenze, hab ich eigentlich immer noch 16Mbit Luft und das erzielt immer gute Bufferbloat Werte. Das ganze wird natürlich etwas schwieriger, wenn man eine Leitung hat mit Werten dazwischen.

Im Großen und Ganzen macht es nur Sinn sich über Bufferbloat Gedanken zu machen, wenn viele in deinem Netzwerk hängen und streamen, Zocken, TV, hier ein Massanger, da ... ... .. .

Wenn man die Leitung allein benutzt kann man sich halt Pingspikes mit dem OperaGX Browser z. B. wegen Streaming ersparen, indem man die Leitung begrenzt. Dafür hat der Browser eine integrierte Funktion, die ich sehr praktisch finde. (...)

LG

 

[pufferueberlauf]

Bufferbloat ist ja nichts anderes, als das es misst, wie hoch deine Latenz ist, wenn der Downloadkanal am Anschlag steht und was in dem Moment dein Ping und dein Upload sagt. Das ganze gilt dann auch für den Upload.

Jein, Bufferbloat bezeichnet den Zustand wenn die Pufferspeicher an einem Flaschenhals von schnell zu langsam groesser sind als notwendig um hohen Durchsatz aufrecht zu erhalten* und dann waehrend normaler Nutzung vollaufen, so dass alle Packet auf ihrem Weg auch noch zusaetzliche diese (uebergrosse) Warteschlange durchlaufen muessen.
Messen kann man das so wie Du beschreibst, und zwar in der relevantesten Dimension, Zeit, in dem man den Flaschenhalslink saettigt und schaut in wie weit dadurch die Transferzeit ueber diesen Link vergroessert wird, d.h. das beste Mass fuer Bufferbloat ist nicht die absolute Latenz unter Last, sondern:

(Latenz unter Last) - (Latenz ohne Last)

.

bzw. ein abgeleitetes Mass wie

(1/(Latenz unter Last)) - (1/(Latenz ohne Last))

.

Nun ist es so, dass bei allen Anbietern es so eingestellt, dass man immer das Maximum an Download und Upload bekommt. Mit einer Fritz Box zum Beispiel, kann man die Werte so verändern, dass man NUN nicht mehr das Maximum an Download und Upload bekommt.

Ja, der erste Schritt um Bufferbloat unter Kontrolle zu bekommen liegt darin den Flaschenhals in den eigenen Router zu verlagern, am einfachsten dadurch dass man einen Traffic-Shaper/Policer verwendet um dafuer zu sorgen, dass das langsamste Stueck des Pfades im eigenen Router liegt. Und dann kann man AQM (Active Queue Management) einsetzen um die notwendige Warteschlange intelligent zu verwalten, so dass es nicht mehr zu inakzeptabler Latenzerhoehung kommt.

Im großen und Ganzen eignet sich solch eine Einstellung, wenn viele Leute eine Leitung benutzen, oder für Low-Latency-Gaming.

Hmm, ich wuerde sagen dass immer wenn man nicht ausschliessen kann, dass der eigene Link gestaettigt wird und der eigene ISP nicht bereits kompetentes AQM einsetzt welches den Bufferbloat auf ein akzeptables Mass reduziert kann der Einsatz von kompetentem AQM Sinn machen, aber das ist eine Entscheidung die jedes Netzwerk fuer sich selber treffen muss.

Wenn man nur eine 100Mbit Leitung hat, so wie ich kommen da etwa 116Mbit durch. Wenn ich mein Netzwerk auf 100MBit begrenze, hab ich eigentlich immer noch 16Mbit Luft und das erzielt immer gute Bufferbloat Werte. Das ganze wird natürlich etwas schwieriger, wenn man eine Leitung hat mit Werten dazwischen.

Guter Punkt. In der Download Richtung muss man in der Tat den Shaper so einstellen, dass er spürbar unter der echten Flaschenhalsrate liegt, ansonsten füllen sich nämlich immer noch die zu grossen Puffer des echten Flaschenhalses und man leidet unter Bufferbloat... je weiter der künstliche Flaschenhals unter der echten Flaschenhalsrate desto besser funktioniert die Bufferbloat-Mitigation, aber halt auf Kosten des Durchsatzes, man muss da jeweils einen akzeptables Kompromiss finden. 85-90% der echten Flaschenhalsrate ist oft ein guter Richtwert, insofern passt 100 von 116 ganz gut zu den Erfahrungswerten.




*) Bei einzelnen TCP Flow gilt, wenn man den Durchsatz maximieren moechte, dass man im schlimmsten Fall das BandwidtDelayProduct (maximale Flaschenhalsrate * RTT * Proportionalitaetsfaktor: BDP) an Pufferspeicher braucht. Das Problem hier ist, dass im Internet der Faktor Delay von wenigen bis einigen 100 Millisekunden schwankt, was eine statische Pufferbemessung die fuer alle Flows optimal ist unmoeglich macht, zumindest wenn das Ziel ist den Puffer so klein wie moeglich aber si gross wie noetig zu machen.

 

[B3CKS]

Jein, (...)

bzw. ein abgeleitetes Mass wie

(1/(Latenz unter Last)) - (1/(Latenz ohne Last))

.


*) Bei einzelnen TCP Flow gilt, wenn man den Durchsatz maximieren moechte, (...)

Ich bin jetzt kein Poweruser in der Hinsicht. Ich habs mir halt so erklärt. Dank Dir für deine doch ausführlichere Variante.

LG

 

[floh667]

Insofern könnte ein buffetbloat Test doch zunehmend interessant sein bei Technologien wie gpon oder docsis, das bereits ab Kundenzuleitung sich die Bandbreite teilt.
Wobei zumindest bei docsis ich das Gefühl hab, dass sie da einen rigorosen QoS fahren der Recht früh die Bandbreiten für die Modems limitiert, wenn die Auslastung hoch geht. Vorallem im upstream wo bei mir im Segment regelmäßig dieser bei 35mbit festgenagelt wird, was dem normal zur Verfügung stehenden laut Vertrag entspricht.

 

[pufferueberlauf]

Insofern könnte ein buffetbloat Test doch zunehmend interessant sein bei Technologien wie gpon oder docsis, das bereits ab Kundenzuleitung sich die Bandbreite teilt.

Ja. Wobei DOCSIS 3.1 letztlich reglementiert, dass allle Modems in Uploadrichtung ein AQM implementieren muessen, welches den Bufferbloat ganz passabel limitieren hilft und das Informationen ueber den DOCSIS-Grant-Request Zustand des Modems hat und damit unabhaengig davon funktionieren sollte ob einem gerade die volle Vertragsrate zu Verfuegung steht oder ob das Segment gerade ueberlastet ist. Wie gut das funktioniert kann vielleicht @robert_s berichten, meine DOCSIS-Tage liegen mehr als 10 Jahre zurueck und waren unter DOCSIS3.0.
Low-Latency DOCSIS wird dann endlich auch ein AQM im CMTS vorschreiben um auch den Download etwas zu ent-bloaten.

IMHO ist das gewaehlte AQM in LL-DOCSIS minderwertiger Schrott (bzw. das AQM mag okayish sein, aber die Versprechen die zu dessen Leistung gemacht werden sind keine Ingenieurs- sondern PR-Aussagen)...

Vorallem im upstream wo bei mir im Segment regelmäßig dieser bei 35mbit festgenagelt wird, was dem normal zur Verfügung stehenden laut Vertrag entspricht.

Wuerde IMHO sogar Sinn machen... bei Ueberlast muss man halt die Bandbreite halbwegs fair verteilen da erscheint erst mal alle auf ihr vertragliches Minimum zu reduzieren ein logischer Schritt.

 

[floh667]

Ja. Wobei DOCSIS 3.1 letztlich reglementiert, dass allle Modems in Uploadrichtung ein AQM implementieren muessen, welches den Bufferbloat ganz passabel limitieren hilft und das Informationen ueber den DOCSIS-Grant-Request Zustand des Modems hat und damit unabhaengig davon funktionieren sollte ob einem gerade die volle Vertragsrate zu Verfuegung steht oder ob das Segment gerade ueberlastet ist. Wie gut das funktioniert kann vielleicht @robert_s berichten, meine DOCSIS-Tage liegen mehr als 10 Jahre zurueck und waren unter DOCSIS3.0.
Low-Latency DOCSIS wird dann endlich auch ein AQM im CMTS vorschreiben um auch den Download etwas zu ent-bloaten.

Es gibt noch einige Segmente, in denen docsis 3.1 im upstream noch nicht einzug erhalten hat. In dem Dorfsegment z.B, in dem sich mein Anschluss befindet. Wir haben weiterhin nur fünf D3.0 Kanäle.
Ich habe auch schon über längeren Zeitraum hinweg den jitter beobachtet auf der Leitung. Dieser hat die meisten Ausreißer, wenn das CMTS den upstream auf 35mbit oder weniger limitiert, sprich wenn der upstream ausgelastet ist. Da reden wir dann von Jitter im Bereich von 3ms oder mehr.
Ist das Segment frei und die 50mbit liegen vol lan, sinkt er auf ~2ms. Ist das Segment gänzlich leer und der upstream nicht gestört, hatte ich auch schon jitter-Werte von aal glatten 0,9-1ms.

Bezüglich QoS bei DOCSIS hab ich mal ein Dokument angehängt, bei dem man einen Einblick in die QoS Konfiguration solcher Systeme erhält. Das PDF ab Seite 259

 

[0-8-15 User]

Mit einer Fritz Box zum Beispiel, kann man die Werte so verändern, dass man NUN nicht mehr das Maximum an Download und Upload bekommt. Das macht die Leitung etwas langsamer, dafür aber stabiler und der Bufferbloat wird geringer.

Hat das mal jemand versucht sauber nachzuweisen?

 

[B3CKS]

Hat das mal jemand versucht sauber nachzuweisen?

Ich, vielleicht? Aber darum geht es mir nicht. Ich bin von Kabel zu DSL aus diesem Grund gewechselt. Ich habe aber einfach zu wenig Verständnis als auch das Fachwissen, geschweige die Lust. Zugeben ist auch eine Sache der Provider. Mit den Bufferbloat Tests und Ping Tests habe ich festgestellt, dass Kabel nichts für Power User, wie in meinem Fall ist. (Berlin) Normale Internetuser merken diese Schwankungen meist kaum.

Es ist mir auch nur aufgefallen, weil ich halt dieses Spiel spiele und mich gewundert habe, warum ich sogenannte Rollbacks habe, oder das Zattoo einfriert etc. .

Seit ich DSL habe, läufts wie geschmiert bei mir und durch die Bufferbloats Tests noch konstanter. Das war mir wichtig.

Edit. Hier läuft noch ein 4K twitch Stream im Hintergrund.

100Mbit

1Gbit

LG

 

[kingpin42]

Insofern könnte ein buffetbloat Test doch zunehmend interessant sein bei Technologien wie gpon oder docsis, das bereits ab Kundenzuleitung sich die Bandbreite teilt.
Wobei zumindest bei docsis ich das Gefühl hab, dass sie da einen rigorosen QoS fahren der Recht früh die Bandbreiten für die Modems limitiert, wenn die Auslastung hoch geht. Vorallem im upstream wo bei mir im Segment regelmäßig dieser bei 35mbit festgenagelt wird, was dem normal zur Verfügung stehenden laut Vertrag entspricht.

Ich kann dir versichern, das bei PK-PON Netzen der aktuell von vielen Providern verwendete Gleichzeitigkeitsfaktor zu 99 % ausreichend dimensioniert ist. Ausgenommen sind natürlich Provider die Tarife gleich der maximal möglichen Segmentkapazität anbieten. In DOCSIS-Netzen wird da afaik sehr viel stärker überprovisioniert, da kommt es dann, neben anderen Faktoren wie EMV-Störungen, häufiger zu sinkenden Bandbreiten in einzelnen Segmenten.

 

[Gelbsucht]

Wie teste/messe ich Bufferbloat?

Ueber den Browser:

a) Der dslreports speedtest war lange Zeit die einzige oeffentiche Option...

Nope, der Sourceforge Test bot das auch. Leider wurde das Ding wieder eingestampft