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

[riversource]

under der Annahme, dass FritzOS das Shaping nit Linux-Bordmitteln realisiert?

Ich fürchte, eher nicht. Das wäre das erste Mal, dass sie es nicht in einen eigenen daemon packen. Prädestiniert wäre der dsld (der sich nicht nur auf DSL Boxen ums gesamte Verbindungsmanagement und Routing kümmert). Der dsld hat u.a. folgende Kommandozeilenparameter:

 -q STRING          - specify tc fair queueing scheduler to use for egress shaping ("sfq"|"sfb"|"fq_codel"). ("sfq")
 -t STRING          - specify tc fair queueing scheduler to use for ingress shaping ("sfq"|"sfb"|"fq_codel"). ("fq_codel")

 

[0-8-15 User]

Also entspricht die Anzeige zumindest auch der eigenen Messung von Firefox.

Das kann ich durchaus bestätigen, aber das Ergebnis entspricht nun mal nicht dem tatsächlichen Bufferbloat.

 

[robert_s]

Das kann ich durchaus bestätigen, aber das Ergebnis entspricht nun mal nicht dem tatsächlichen Bufferbloat.

Ich halte es für einen Fehler, ICMP-Latenzen für die Ermittlung des "tatsächlichen" Bufferbloat heranzuziehen, denn dann wäre das ja lediglich eine "akademische" Messgröße ohne jeglichen Praxisbezug.

Denn für praktische Anwendungen ist völlig irrelevant, welche Latenzen ICMP-Pakete aufweisen, da die dafür schlichtweg nicht eingesetzt werden. In der Praxis zählen die Latenzen von UDP- und TCP-Paketen (letztere nicht bei Downloads, aber TCP wird ja z.B. auch bei SSH und VPN-Verbindungen eingesetzt).

Insofern würde ich sagen, das Ergebnis hat mehr mit dem "tatsächlichen" Bufferbloat zu tun als ein nebenher laufender ICMP-Ping.

 

[0-8-15 User]

Bei den RRUL Tests mit Flent aus Post #8 wurde die Latenz sowohl via ICMP als auch via UDP ermittelt:

Ich halte es für einen Fehler, ICMP-Latenzen für die Ermittlung des "tatsächlichen" Bufferbloat heranzuziehen

Ich auch und der NetworkQuality Test von Apple macht das ja beispielsweise auch nicht und kommt im Gegensatz zum Ookla Test (und den meisten anderen Browsertests) trotzdem zum richtigen Ergebnis, siehe #52.

In der Praxis zählen die Latenzen von UDP- und TCP-Paketen

Richtig, und wenn ich drill heise.de @1.1.1.1 mache, liegt die Query time locker bei 90 ms, wenn der Upload ohne Traffic Shaping voll ausgelastet ist, da der "tatsächliche" Bufferbloat eben in meinem Fall bei 80 ms und nicht bei 0 ms liegt, wie der Ookla Test suggeriert.

 

[pufferueberlauf]

-q STRING - specify tc fair queueing scheduler to use for egress shaping ("sfq"|"sfb"|"fq_codel"). ("sfq") -t STRING - specify tc fair queueing scheduler to use for ingress shaping ("sfq"|"sfb"|"fq_codel"). ("fq_codel")

Danke!
Sowohl 'tc' als auch die Liste der AQM/Scheduler deutet auf Linux Bordmittel hin, aber das ist ja orthogonal zum Traffic-Shaper.

 

[0-8-15 User]

@pufferueberlauf, ein paar Minuten weiter im Video sagt er Folgendes:

Denn - wichtiger Hinweis - damit wir dieses Ingress Shaping machen können, müssen wir die Hardwarebeschleunigung deaktivieren.
...
Deswegen aktiviert das auch wirklich nur, wenn ihr mehrere Geräte habt, die gleichzeitig aktiv sind. Wenn ihr da allein unterwegs seid, dann lasst es, wie es ist, nutzt die Hardwarebeschleunigung, ist in dem Fall vermutlich die bessere Wahl.

Und kommentiert den Test mit aktiviertem Ingress Shaping, schließlich so (Anmerkungen von mir in Klammer):

Das heißt, jetzt hat genau die (FRITZ!)Box für diese faire Bandbreitenverteilung gesorgt, hat gesagt, egal wie viele Verbindungen diese Anwendung hier aufmacht, wir verteilen die Bandbreite gerecht zwischen diesem Notebook (rechts im Bild) und diesem Notebook (links im Bild). Damit ist sichergestellt, dass die Anwendung, die hier (linkes Notebook) läuft, auf jeden Fall stabil weiterläuft, also zum Beispiel eine Videokonferenz, obwohl hier (rechtes Notebook) gerade irgendeiner wahnsinnig viel runterlädt oder einen BitTorrent laufen hat oder was auch immer.

 

[pufferueberlauf]

Oha, AVM spricht davon beim Ingress Shaping die Rate um weniger als ein Prozent zu reduzieren (~2:37 "wir reden da von weniger als ein Prozent"))...
Aus meiner Erfahrung ist das relativ "optimistisch" und es duerfte schon oefter mal dazu kommen, dass auch die Upstream Warteschlangen auf der ISP Seite volllaufen. Da sind i.d.R. 5-15% Abschlag zuverlaessiger (bei cake als Shaper ist das nicht ganz so wichtig da cake im ingress mode aggressiver shaped, aber auch mit cake wuerde ich immer >=5% Abschlag empfehlen).


Die demonstrierte Performance ist OK aber jetzt nicht perfekt:
1) Demo ohne Ingress-Shaping:
Sync ~97: -> 97 * 64/65 * ((1500-20-20)/(1500+26)) = 91.3769533219*
Speedtest: 85
FTP: 91-85 = 6

2) Demo mit Ingress Shaping:
Sync: ~100 * 64/65 * ((1500-20-20)/(1500+26)) = 94.2030446618*
Speedtest: ~60
FPT: 94-60 = 34

Laut Adam Riese sollten beide Anwendungen circa je 94/2 = 47 Mbps bekommen... ABER im Vergleich zu den geschaetzten 6 Mbps ist 34 ein massiver Zugewinn der deutlich spuerbarer sein duerfte als die theoretisch fehlenden 13 Mbps (umgerechnet aufs Mbps, weil dass 28 Mbps Zugewinn spuerbarer als 13 Mbps ist waere jetzt nicht sonderlich erstaunlich). Soll heissen, gut moeglich, dass AVMs Ingress-Shaping schlicht "gut genug" ist.
Wobei z.B. cake mit dem ingress keyword auch zu aehnlichen Effekten fuehren kann (weil ingress dafuer sorgt dass alle flows so geshapt werden dass ihr Ingress in cake equalisiert werden, waehrend wir i.d.R. cake's egress messen). Waere also interessant zu erfahren wie AVM die per-host-fairness implementiert.



*) Laut IPv4 Adresse ist das kein Telekom Anschluss weshalb ich den PPPoE-Overhead ignoriere.

 

[0-8-15 User]

Die demonstrierte Performance ist OK aber jetzt nicht perfekt

Wenn es halbwegs anständig funktioniert, wäre es trotz allem eine massive Aufwertung von FRITZ!OS.

 

[pufferueberlauf]

Wenn es halbwegs anständig funktioniert,

Ich vermute, dass es das bereits tut, nicht perfekt, aber "gut genug".

wäre es trotz allem eine massive Aufwertung von FRITZ!OS.

In der Tat.

Und Wege fuer die Zukunft sind dann auch schon absehbar, wechsel von fq_codel/sfq auf cake dann in weiteren 10 Jahren

Aber Spass beiseite, es gab eine Zeit da galt "Ingress-Shaping" als unmoeglich oder als so unpraezise* dass es mehr schadet als nutzt, schoen dass wir diese Phase ueberwunden haben.




*) Unpraezise ist ja nicht ganz falsch, bei nicht-responsivem Traffic fuellen sich alle Queues auf dem Weg deren Egress-Rate <= dem noch durchkommenden Traffic sind und dann sind auf einmal viele ueber-grosse und unter-verwaltete Warteschlangen uebervoll. Aber das ist halt fuer die meisten von uns nicht der normale Traffic

 

[Burnzi]

Also kann es sinnvoll sein auf der Fritzbox das zu aktiveren?
Wie hier auf der 5530:

 

[pufferueberlauf]

Das haengt davon ab was Du erreichen moechtest . Die Paketbeschleunigung kann dafuer sorgen, dass ein Router trotz eigentlich zu schwacher CPU noch passabel mit hoeheren Routing-Raten zurecht kommt (die meisten Beschleuniger sind (etwas) weniger flexibel als der volle Kernel-Netzwerk-Stack, aber wenn der Beschleuniger alle Feature bietet, die Du brauchst ist das kein Problem).
Kann man ja einfach austesten ob es fuer die eigene Anwendung besser mit oder ohne funktioniert. Ich wuerde allerdings immer sowohl auf den Durchsatz als auch auf die Latenz-unter-Last-Zunahme achten um die unterschiedlichen ALternativen zu bewerten.

 

[B3CKS]

Das haengt davon ab was Du erreichen moechtest .

Eines sollte bei diesem ganzen Bufferbloat geteste bewusst klar sein:

- man verschafft sich zwar A+ Werte bei den Benches, d. h. aber noch lange nicht, dass man dadurch eine stabilere Leitung hat. Alles hat seinen Preis.

Wie schon erwähnt, geht dann vieles über die CPU des Routers und das kostet anscheinend.

Ich als Street Fighter Spieler lege wert auf Durchsatz ohne Input Lag, oder das irgendwelche Pakete erst durch eine Software geschleift werden, wo entschieden wird was wichtiger ist.

Bufferbloat ist in meinen Augen viel interessanter für Leute, die sich ihr Netzwerk mit realen Personen teilen. Ich als alleiniger User entscheide, was im Hintergrund auf meinem Rechner mitläuft und kann danach meine Prios setzen.

Nur mal so am Rande

 

[Salamimander]

es gibt keine latenzzunahme abseits von Voodoo wenn man SQM einsetzt … Dir wird minimal Bandbreite geklaut. (Irgendwas zwischen 1-10%, muss man selber austesten bei wie viel man eingreifen muss)

 

[pufferueberlauf]

Also Stabilitaet ist orthogonal zu Bufferbloat

- man verschafft sich zwar A+ Werte bei den Benches, d. h. aber noch lange nicht, dass man dadurch eine stabilere Leitung hat. Alles hat seinen Preis.

Stabilitaet und Bufferbloat sind orthogonale Probleme. (Auch wenn extremer Bufferbloat von mehreren Sekunden Stabilitaets-Probleme bei Protokollen wie TCP bewirken kann).

Ich als Street Fighter Spieler lege wert auf Durchsatz ohne Input Lag, oder das irgendwelche Pakete erst durch eine Software geschleift werden, wo entschieden wird was wichtiger ist.

Ist nicht so, dass cake/fq_codel selber spuerbare Verzoegerungen bewirken wuerden....

 

[B3CKS]

Also Stabilitaet ist orthogonal zu Bufferbloat

Stabilitaet und Bufferbloat sind orthogonale Probleme. (Auch wenn extremer Bufferbloat von mehreren Sekunden Stabilitaets-Probleme bei Protokollen wie TCP bewirken kann).


Ist nicht so, dass cake/fq_codel selber spuerbare Verzoegerungen bewirken wuerden....

Schön, dass du das Forum verlassen hast. So können wir nicht arbeiten und ANtworten sind ab jetzt wohl sinnlos, oder whats up?

Du hast vlt. nicht deine Antworten bekommen, die du dir erhofft hast, aber es war eine interessante Diskussion.

Ich bin zufrieden und deinem Thread. Mein Bufferbloat ist weg, (...). Danke dafür. Bin trotzdem etwas verwundert über deine Reaktion... . Schade!

LG

 

[mr999]

Also mit meiner Fritzbox 7590 habe ich am 250er Telekom Anschluss hohen Bufferbloat.
Während eines Upload teilweise so hoch, dass online Spiele kaum noch möglich sind.
Mit der Fritzbox7520 merkwürdigerweise ist kaum Bufferbloat.

 

[LouisXIV]

Haben zwischenzeitlich andere FRITZ!Box Besitzer mit den von AVM zur Verfügung gestellten Mitteln gespielt? Für mein 50/10 O2 VDSL über eine 7530 mit Firmware 7.39-101046 BETA scheint das Ingress-Shaping weder über das Internet-Filter-Priorisierung- noch über das Support-Menü allein zu einer Verbesserung des Bufferbloat zu führen.
Reduziere ich im Support-Menü zusätzlich zu einer der Ingress-Shaping-Optionen - von denen mir nicht klar ist, ob sie identisch sind oder nicht - die mit einer Leistungskapazität von 116965/45765 kbit/s und einer aktuellen (synchronisierten?) Datenrate von 111424/42455 angegebene Verbindung jedoch per "DSL-Leitungsgeschwindigkeit" "Manuelle Anschlussrate" auf 9000 (Upstream)/50000 (Downstream) was vom System nach Übernahme der Einstellungen als 8860/47748 angenommen wird, kann ich die Latenzsteigerung deutlich reduzieren. Deaktiviere ich die Ingress-Option, zeigt die eingestellte Drosselung der DSL Leitungsgeschwindigkeit keine Wirkung mehr und die Leitung bewegt sich wieder auf dem Ausgangsniveau, es scheint also eine Abhängigkeit der "DSL-Leitungsgeschwindigkeit" von aktiviertem Ingress-Shaping zu geben.

"Bandbreite für das Heimnetz reservieren" aktiviert; "Für das Heimnetz reservierte Bandbreite"=automatisch; "Ingress-Shaping" aktiviert mit "Ingress-Shaping Rate"=0 (automatisch)
https://www.waveform.com/tools/bufferbloat?test-id=dd9ddc01-259f-429f-91cf-4cdde0b896ab

"Bandbreite für das Heimnetz reservieren" aktiviert; "Für das Heimnetz reservierte Bandbreite"=automatisch; "Ingress-Shaping" deaktiviert
https://www.waveform.com/tools/bufferbloat?test-id=c1b2cbe0-1281-4761-8e29-cbd9413486ec

"Bandbreite für das Heimnetz reservieren" deaktiviert; "Ingress-Shaping" aktiviert mit "Ingress-Shaping Rate"=0 (automatisch)
https://www.waveform.com/tools/bufferbloat?test-id=d2c7385f-e001-4f66-b54d-2bf8efdf9f34

"Bandbreite für das Heimnetz reservieren" deaktiviert; "Ingress-Shaping" deaktiviert
https://www.waveform.com/tools/bufferbloat?test-id=44245afd-4bb1-420b-a2a8-01c038aa17c9

"Bandbreite für das Heimnetz reservieren" deaktiviert; "Ingress-Shaping" aktiviert mit "Ingress-Shaping Rate"=0 (automatisch); "DSL-Leitungsgeschwindigkeit" mit "Manuelle Anschlussrate aktivieren"=9000 (Upstream)/50000 (Downstream), effektiv 8860/47748 kbit/s [vergleichbares Ergebnis mit Umkehr der gewählten Ingress-Shaping-Option]
https://www.waveform.com/tools/bufferbloat?test-id=97b42910-3a85-4454-9458-d0a00b6dacd3

"Bandbreite für das Heimnetz reservieren" deaktiviert; "Ingress-Shaping" deaktiviert; "DSL-Leitungsgeschwindigkeit" mit "Manuelle Anschlussrate aktivieren"=9000 (Upstream)/50000 (Downstream), effektiv 8860/47748 kbit/s
https://www.waveform.com/tools/bufferbloat?test-id=54db9587-f6fb-4d66-ac68-0df5a5a62957

 

[mr999]

Und hier bei dem Test?
Da gibts den höchsten Bufferbloat bei mir. Immer nur C
http://www.dslreports.com/speedtest

http://www.dslreports.com/speedtest/71420518

 

[LouisXIV]

Aus welchem Grund auch immer bekomme ich den Test bei mir im Firefox nicht zum laufen, selbst mit uBO, I still don't care about cookies, LocalCDN und co deaktiviert. Ich probiere es später mal in Chrome.

In Chrome gehts.
Ingress-Shaping aus:
http://www.dslreports.com/speedtest/71420578
Ingress-Shaping aktiv:
http://www.dslreports.com/speedtest/71420551
Ingress-Shaping & Leistungsgeschwindigkeitsdrosselung aktiv:
http://www.dslreports.com/speedtest/71420589

 

[chrisulin]

In so einem Fall könnte die Option „DSL Syncrate begrenzen auf verfügbare Bitrate“ helfen!
Ich meine aber das bei O2 Abschlüssen nicht die notwendigen Werte übermittelt werden um diesen Punkt zu nutzen.
Ansonsten würde ich nur manuell Werte eintragen!
Eventuell ein wenig mit anderen DL Werten testen.
Oder schau mal in deinen Support-Daten nach welche Werte deine Box bei allen deaktivierten Optionen unter „Networking“ überhaupt nutzt!
Bei meinem VDSL 100 Telekom Anschluss sieht das so aus.