Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Andere/ÜbergreifendBufferbloat, wer, wie, was, wieso, weshalb, warum
ISP ist Magenta in Oesterreich.
Keine Ahnung welche Docsis Version.
Shaper ist halt der von Opnsense, mit Scheduler Type FlowQueue-CoDel.
Mit ein paar Pipes. z.b. die IP des GamePC bekommt eine hohe Prio
DNS Pakete und Pakete mit weniger als 100 Bytes die hoechste Prio. Das sollte z.b. die Ack Pakete beschleunigen.
Mit FlowQueuing braucht es weitere Priorisierung oft gar nicht mehr, allerdings spricht gerade bei Spiele-Endgeraeten auch nichts dagegen sich abzusichern (quasi "Gürtel und Hosenträger"). Als Anmerkung Priorisierung funktioniert dadurch dass manche Packete bevorzugt (sprich schneller) weitergeleitet werden, damit das funktioniert muessen andere Pakete verzoegert werden, was nur funktioniert wenn es solche Pakete gibt; d.h. Priorisierung funktiniert am besten wenn man das sparsam einsetzt, z.B. nur fuer den GamingPC.
Speedy.at schrieb:
DNS Pakete und Pakete mit weniger als 100 Bytes die hoechste Prio. Das sollte z.b. die Ack Pakete beschleunigen.
Das war früher eine beliebte Empfehlung, sollte aber mit FlowQueueing nicht mehr notwendig sein. fq_codel gibt den Flows mit geringer Aktivität (bzw. die Ihr Quantum nicht ausschoepfen) einen kleinen Boost gegenüber Flows die tatsächlich eine Queue aufbauen, das in Kombination mit dem Flow Scheduler sorgt dafür dass kleine Pakete i.d.R. keine weitere Extrabehandlung brauchen.
Kannst Du ja mal ausprobieren, wenn das schlechter funktioniert als Deine bisherige Loesung ist das ja schnell rückgängig gemacht.
Ja das kann sein. Ich komme noch aus Zeiten, da hat man das mit einer transparenten Bridge auf OpenBSD Basis geshaped.
Kann ich ja mal probieren, obs schlechter wird wenn man das weglaesst.
Ergänzung ()
Ja macht absolut keinen Unterschied.
Nun hab ich 4 Rules weniger.
Man kann sich per Wireshark sehr schön die RTT der TCP-ACKs plotten lassen.
Hier als Beispiel 2 iperfs auf 2 unterschiedlichen Ports in rot und in blau, wobei der rote iperf etwas später startet. Während der Messung liefen auch noch andere Sachen, man sieht aber deutlich wie die RTT steigt wenn 2 TCP-Verbindungen gleichzeitig laufen. Hier eine Messung mit Full-Speed, man sieht wie die RTT steigt wenn 2 Verbindungen gleichzeitig laufen:
Zum Vergleich eine Messung mit weniger Bandbreite die die Leitung nicht auslastet:
Wer also auf der Suche nach Latenz-Peaks zu fast beliebigen Zielen ist, oder sein qos tunen möchte -> so gehts.
habe mal etwas getestet.
Mein Speedport 4 kommt zu Hause an einer 250/40 er VDSL Leitung auf eine Wertung von A+ beim Waveform Bufferbloat Test.
Gar nicht schlecht für einen Wald und Wiesen Router ohne Einstellmöglichkeiten, muss sagen das WLAN ist auch sehr gut.
In der Firma etwas mit den QoS Einstellungen des Asus AC87u gespielt und konnte dort von B auf eine A Wertung kommen.
Gemessen an einer 50/10 er VDSL Leitung, die der limitierende Faktor sein könnte.
Getestet wurde in beiden Fällen per LAN Kabel am Desktop PC.
ohne speedtest Last.
Ping wird ausgeführt für 8.8.8.8 mit 32 Bytes Daten:
Antwort von 8.8.8.8: Bytes=32 Zeit=4ms TTL=60
Antwort von 8.8.8.8: Bytes=32 Zeit=4ms TTL=60
Antwort von 8.8.8.8: Bytes=32 Zeit=4ms TTL=60
Antwort von 8.8.8.8: Bytes=32 Zeit=4ms TTL=60
Ping wird ausgeführt für 8.8.8.8 mit 32 Bytes Daten:
Antwort von 8.8.8.8: Bytes=32 Zeit=38ms TTL=60
Antwort von 8.8.8.8: Bytes=32 Zeit=44ms TTL=60
Antwort von 8.8.8.8: Bytes=32 Zeit=40ms TTL=60
Antwort von 8.8.8.8: Bytes=32 Zeit=40ms TTL=60
Ping wird ausgeführt für 8.8.8.8 mit 32 Bytes Daten:
Antwort von 8.8.8.8: Bytes=32 Zeit=40ms TTL=60
Antwort von 8.8.8.8: Bytes=32 Zeit=40ms TTL=60
Antwort von 8.8.8.8: Bytes=32 Zeit=36ms TTL=60
Antwort von 8.8.8.8: Bytes=32 Zeit=37ms TTL=60
Ergänzung ()
Ihre Internetgeschwindigkeit beträgt
260 Mbps
Upload Last Ping
Ping wird ausgeführt für 8.8.8.8 mit 32 Bytes Daten:
Antwort von 8.8.8.8: Bytes=32 Zeit=73ms TTL=60
Antwort von 8.8.8.8: Bytes=32 Zeit=69ms TTL=60
Antwort von 8.8.8.8: Bytes=32 Zeit=67ms TTL=60
Antwort von 8.8.8.8: Bytes=32 Zeit=65ms TTL=60
Danke.
Mich würde interessieren was mit welchem Router so zu erreichen ist.
Die Werte der Fritzboxen sahen meist auch nicht so berauschend aus.
Du präferierst openwrt wie mir schient.
Exact auf unsere obigen Tests bezogen, darf ich Fragen was du für als Verbesserung erwarten würdest bei nutzung von openwrt oder pfsense routern mit QoS ?
Ergänzung ()
0-8-15 User schrieb:
Im Alltag verwende ich FQ-CoDel und verzichte dabei auf ca. 3 % der Nettodatenrate: Anhang anzeigen 1200221
ungefähr so was?
Ich hätte noch ein paar ungenutze DGA4132 die mit openwrt laufen.
Die hätten auch einen SFP Schacht der ganz eventuell mit dem Telekom Zyxel Gpon SFP Modul zum laufen zu bekommen wäre.
Sprich ich hätte 2 Gründe zum basteln, dachte bis jetzt das ich wenig gewinnen kann.
Ich meine A+ gibt es wenn die Latenzzunahme unter Last (also die Differenz zwischen den Mittelwerten fuer Idle und der jeweiligen Richtung) <= 30 ms bleibt. Man kann gut argumentieren, dass man besser dir 95% oder 75% Werte dafuer verwenden sollte. Aber die Telekom, aehnlich wie O2 (wobei die als Reseller vielleicht nur von den Massnahmen der Telekom profitieren), ist in den letzten Jahren im Zugangsnetz deutlich besser geworden was Bufferbloat-Reduktion angeht.
Wobei ich ohne eigenen Traffic-Shaper
im Latenz-Profil fuer den DSLReports Downloadtest (ja, ist Download obwohl im Titel "Bufferbloat (lag) idle vs under load" steht) eigenartige zyklische "Rampen" sehe (Testdauer ist auf 30/30 Sekunden gestellt, falls sich jemand wundert). Und die Rampen sehe ich spaetestes seit des abgeschlossenen Nahbereichausbaus und der damit verbundenen Aktivierung von Vectoring und G.INP (der Sync wurde von ca. 50/10 auf 100/40 raufgesetzt, so dass die Ursache im Traffic-Shaper vom ISP liegen muss).
Das Problem ist, dass die erzeugte Last schlicht zu niedrig war, um den Bufferbloat sichtbar zu machen:
Code:
====== RESULTS SUMMARY ======
Mean Unloaded Latency (ms),12.4
Increase In Mean Latency During Download Test (ms),4.84
Increase In Mean During Upload Test (ms),0.69
Download speed (Mbps),250.64
Upload speed (Mbps),42.944
====== LATENCY TEST DETAIL ======
Unloaded - Median Latency (ms),11.65
Unloaded - 95th %ile Latency (ms),17.47
Unloaded - Mean Latency (ms),12.4
During Download - Median Latency (ms),17.05
During Download - 95th %ile Latency (ms),21.5
During Download - Mean Latency (ms),17.24
During Upload - Median Latency (ms),12.2
During Upload - 95th %ile Latency (ms),16.72
During Upload - Mean Latency (ms),13.09
Deshalb ist ein simpler Kontrolltest via ping + speedtest.net meiner Meinung nach immer anzuraten.
Jein, wenn der Speedtest nicht ordentlich saettigt dann sollten beide Latenzmessungen unauffaellig bleiben . Wobei man sich mit ping (bzw, ich nehme lieber mtr) des Problems entledigt, dass manche Browser selber Probleme machen... Apples networkQuality/RPM tool und Ooklas neue iOS/Android App messen die Latenz-unter-Last absichtlich ueber die selben TCP Flows ueber die die Daten fliessen, wenn ich das richtig verstehe, die zeigen dann nicht nur den generellen Bufferbloat sondern auch den des verwendeten TCP-Stacks.
überlege halt eine DGA4132 zu nehmen, da schon vorhanden.
Wie das Hauseigene QoS implementiert ist weiss ich nicht, da OpenWrt evtl. auch SQM?
Schon etwas älter, aber es gibt sogar alternative Ansätze. https://github.com/xMase/Traffic-Shaping-DGA4132
@pufferueberlauf, der obige Waveform Test hat die Leitung in Downloadrichtung nur zu knapp 95 % ausgelastet, was definitiv nicht ausreicht, um den tatsächlichen Bufferbloat zutage zu fördern.
faser schrieb:
überlege halt eine DGA4132 zu nehmen, da schon vorhanden.
DGA4132 ist Broadcom, da ist es unter OpenWrt Essig mit DSL und WiFi...
0-8-15 User schrieb:
@pufferueberlauf, der obige Waveform Test hat die Leitung in Downloadrichtung nur zu knapp 95 % ausgelastet, was definitiv nicht ausreicht, um den tatsächlichen Bufferbloat zutage zu fördern.
Das ist halt schwer festzustellen wieviel Kapazitaet tatsaechlich fuer den Test verfuegbar ist, aber wenn Du sagst nur 95% glaube ich Dir das, aber wenn die Cloudflare-Server z.B. BBR einsetzen sollten kann ich mir das schon vorstellen, dass der Link nicht 100% gesättigt wird.
@pufferueberlauf, ich mag falschliegen, aber wenn ich mir die verfügbaren Informationen (aus Beitrag #88) ansehe, komme ich zu dem eindeutigen Schluss, dass das Ergebnis des Waveformtests nicht aussagekräftig ist:
...
