#15951  (Permalink
Alt 06.10.2021, 11:39
Benutzerbild von gogosch
gogosch gogosch ist offline
Neues Mitglied
 
Registriert seit: 05.02.2020
Beiträge: 12
Standard AW: SuperVectoring (VDSL2 Annex Q) Sammelthread

So sieht es bei mir aus (Österreich) mit nur ~30Mbps UL
http://www.dslreports.com/speedtest/69707091
Mit Zitat antworten
  #15952  (Permalink
Alt 06.10.2021, 11:43
Benutzerbild von mr999
mr999 mr999 ist offline
Senior Mitglied
 
Registriert seit: 24.12.2001
Beiträge: 3.847
Provider: Telekom
Bandbreite: 274884/46584 kbit/s
Standard AW: SuperVectoring (VDSL2 Annex Q) Sammelthread

Und welchen Router nutzt du?
Mit Zitat antworten
  #15953  (Permalink
Alt 06.10.2021, 11:44
Benutzerbild von gogosch
gogosch gogosch ist offline
Neues Mitglied
 
Registriert seit: 05.02.2020
Beiträge: 12
Standard AW: SuperVectoring (VDSL2 Annex Q) Sammelthread

Fb7530
Mit Zitat antworten
  #15954  (Permalink
Alt 06.10.2021, 12:12
pufferueberlauf pufferueberlauf ist gerade online
Senior Mitglied
 
Registriert seit: 20.06.2013
Beiträge: 6.933
Standard AW: SuperVectoring (VDSL2 Annex Q) Sammelthread

Zitat:
Zitat von gogosch Beitrag anzeigen
Das hat mit der Fritz!box nur bedingt zu tun. Mit der FB7520 ist der UL wesentlich/etwas geringer als vorher mit der FB7590. Somit ist etwas "Luft" für ICMP.
Möglicherweise liegt es auch am Testserver und kann morgen schon wieder anders sein.
Bufferbloat beim UL zu messen ist IMHO Unsinn. Wenn der UL voll ausgelastet (Flaschenhals Bandbreite DSL UL) ist dann ist halt für zusätzliches ICMP kein Platz.
Viel interessanter ist der "Bufferbloat" beim DL.
Mmmh, ich halte solche Messungen in beiden Richtungen fuer relevant, der Punkt ist, man kann einen Link nahe an der Saettigung fahren, ohne dass die Situation "kein Platz fuer neue Packete" dauerhaft auftritt. Zum einen durch Verwendung eines AQMs welches die Warteschlange akzeptabel klein haelt und zum anderen durch die Verwendung eines Traffic Schedulers der Pakete der verschiedenen Flows interleaved, z.B. ein flow-queueing scheduler wie in fq_codel oder cake.

Und nur als Anmerkung, TCP braucht immer zeitnahe ACKs in Gegenrichtung, d.h. wenn der Upload bufferbloating ist, leiden auch parallele Downloads wenn der Upload ausgelastet wird. D.h. es macht durchaus Sinn den Bufferbloat in beiden Richtungen zu minimieren und deshalb auch Sinn den in beiden Richtungen zu messen.

Fritzboxen haben zumindest bisher nicht die besten Strategien gegen Bufferbloat implementiert, traurig aber wahr, da der Linux-Kernel seit Jahren robuste Implementierungen von fq_codel und cake enthalten...

Gruss
P.
Mit Zitat antworten
  #15955  (Permalink
Alt 06.10.2021, 12:19
pufferueberlauf pufferueberlauf ist gerade online
Senior Mitglied
 
Registriert seit: 20.06.2013
Beiträge: 6.933
Standard AW: SuperVectoring (VDSL2 Annex Q) Sammelthread

Zitat:
Zitat von mr999 Beitrag anzeigen
Ja der upload war in dem Beispiel hoch,
guck mal bei dem Ergebnis, da war er nicht so hoch und trotzdem sehr hoher Ping:
http://www.dslreports.com/speedtest/69690003
TCP, also das Protokoll das DSLReports verwendet ist so gebaut, dass es versucht einen Link voll auszulasten*, der geringe Unterschied in der Sync-Rate und im erreichten Goodput zwischen den beiden Messung faellt da nicht wirklich ins Gewicht; in beiden Faellen duerfte der Link gesaettigt gewesen sein.

Es ist ein verbreiteter Irrtum, dass Bufferbloat z.B. ab XXX Mbps nicht mehr auftritt (was schlicht nur dann stimmt, wenn man einen Link niemals sättigt)

Gruss
P.



*) Haengt ein bisschen von der TCO Konfiguration von beiden Enden einer Verbindung und der RTT zwischen beiden ab, welche maximale Rate pro TCP-Flow erreicht werden kann, ein Grund warum fast alle Speedtests heitzutage mit mehreren parallelen TCP-Flows arbeiten, damit ist es meist moeglich einen Link zu sättigen selbst wenn die RTT seht gross oder die Konfiguration sub-optimal sind.
Mit Zitat antworten
  #15956  (Permalink
Alt 06.10.2021, 12:58
pusiofre pusiofre ist gerade online
Mitglied
 
Registriert seit: 25.04.2020
Beiträge: 465
Standard AW: SuperVectoring (VDSL2 Annex Q) Sammelthread

Zitat:
Zitat von pufferueberlauf Beitrag anzeigen
Zum einen durch Verwendung eines AQMs welches die Warteschlange akzeptabel klein haelt und zum anderen durch die Verwendung eines Traffic Schedulers der Pakete der verschiedenen Flows interleaved, z.B. ein flow-queueing scheduler wie in fq_codel oder cake.
Wir sind jetzt schon häufiger über die Terminologie 'traffic shaper', 'active queue management' und 'packet scheduler' gestolpert. Im verlinkten RFC steht:
Zitat:
The Flow Queue CoDel (FQ-CoDel) algorithm is a combined packet
scheduler and Active Queue Management (AQM) [RFC3168] algorithm
Es braucht zwei Dinge, um Bufferfloat auf Endkundenseite zu bekämpfen:
  1. Einen Begrenzer (Traffic Shaper), der den Flaschenhals überhaupt erst ins Heimnetz holt
  2. Etwas, das genau die Pakete verwirft, deren Verlust am wenigsten schmerzhaft ist (Scheduler / AQM)
Mit Zitat antworten
  #15957  (Permalink
Alt 06.10.2021, 13:14
pufferueberlauf pufferueberlauf ist gerade online
Senior Mitglied
 
Registriert seit: 20.06.2013
Beiträge: 6.933
Standard AW: SuperVectoring (VDSL2 Annex Q) Sammelthread

Zitat:
Zitat von pusiofre Beitrag anzeigen
Wir sind jetzt schon häufiger über die Terminologie 'traffic shaper', 'active queue management' und 'packet scheduler' gestolpert. Im verlinkten RFC steht:

Es braucht zwei Dinge, um Bufferfloat auf Endkundenseite zu bekämpfen:
  1. Einen Begrenzer (Traffic Shaper), der den Flaschenhals überhaupt erst ins Heimnetz holt
Jein, im egress/upload braucht es nicht zwingend einen expliziten Traffic Shaper, da reicht z.B. fuer Ethernet-Linerate BQL aus, bzw. bei Linux WiFi ueber Ath9K/Ath10K/mt76 AQL. Und fq_codel hat gar keinen Shaper (weshalb SQM fq_codel mit einem Shaper wie HTB oder TBF kombinieren muss, cake hat einen eigenen Shaper an Board). Ansonsten stimmt das schon, man muss den Puffer des Flaschenhals-Links unter Kontrolle eines kompetenten AQM bringen. Was sehr oft bedeutet, dass man einen Traffic Shaper braucht, was unguenstig ist, da es der Shaper ist der die hoechsten CPU-Kosten mit sich bringt, im Vergleich dazu sind sowohl FQ-Scheduler und per-Flow AQM unerheblich.
Zitat:
Zitat von pusiofre Beitrag anzeigen
  1. Etwas, das genau die Pakete verwirft, deren Verlust am wenigsten schmerzhaft ist (Scheduler / AQM)

AQMs haben per se (also ohne zusaetzliche Klassifikation) keine Ahnung von der relativen Wichtigkeit individueller Pakete. Insgesamt hilft es allen Flows wenn rechtzeitig Signale zum Abbremsen gesendet werden (drops oder CE-marks) am effektivsten/schnellsten ist dass wenn die "fettesten" Flows gebremst werden. Bei FQ Schedulern werden diese Brems-Signale in Abhängigkeit davon gesendet ob ein Flow seinen "fairen" Anteil der Gesamtkapazitaet ueberschreitet und daher (zu) viele Pakete in der Warteschlange hat oder nicht. Bei Single-Queue AQMs ist halt die Wahrscheinlichkeit dass ein Signal Pakete eines Flows der ueber seinem fairen Anteil liegt markiert erhoeht, so dass sich auch da eine grobe Fairness einstellen wird, nur weder so schnell noch so präzise wie bei FQ-AQMs.

Gruss
P.
Mit Zitat antworten
  #15958  (Permalink
Alt 06.10.2021, 13:35
pufferueberlauf pufferueberlauf ist gerade online
Senior Mitglied
 
Registriert seit: 20.06.2013
Beiträge: 6.933
Standard AW: SuperVectoring (VDSL2 Annex Q) Sammelthread

Anmerkung: AVM koennte einen BQL/AQL alalogen Mechanismus in die Egress Seite des DSL-Treibers einbauen und sich damit einen egress Shaper sparen, nur ist der Egress ja bei VDSL2 immer kleiner als der Ingress, so dass damit jetzt nicht soviel CPU-Zyklen gespart werden koennen....
ABER mit OpenWrt/SQM hast Du voellig Recht, es braucht einen zuverlaessigen Traffic-Shaper, AQM und Scheduler alleine reichen nicht aus, das habe ich falsch (zumindest missverständlich) beschrieben, Danke fuer Deine Klarstellung!

Gruss
P.
Mit Zitat antworten
  #15959  (Permalink
Alt 06.10.2021, 14:07
pusiofre pusiofre ist gerade online
Mitglied
 
Registriert seit: 25.04.2020
Beiträge: 465
Standard AW: SuperVectoring (VDSL2 Annex Q) Sammelthread

Zitat:
Zitat von pufferueberlauf Beitrag anzeigen
Jein, im egress/upload braucht es nicht zwingend einen expliziten Traffic Shaper, da reicht z.B. fuer Ethernet-Linerate BQL aus,
Ein Traffic Limiter ist für mich eine Unterkategorie eines Traffic Shapers. Also ist BQL nach meiner Logik ein Traffic Shaper.
Zitat:
Und fq_codel hat gar keinen Shaper (weshalb SQM fq_codel mit einem Shaper wie HTB oder TBF kombinieren muss
Deshalb schrieb ich ja, dass es zwei Dinge braucht.
Zitat:
Zitat von pufferueberlauf Beitrag anzeigen
AQMs haben per se (also ohne zusaetzliche Klassifikation) keine Ahnung von der relativen Wichtigkeit individueller Pakete.
Nein, aber die Logik ist trotzdem so beschaffen, dass - auch ohne explizite Kenntnis über die tatsächliche Wichtigkeit der Pakete - fast immer genau die richtigen Pakete verworfen werden.
Mit Zitat antworten
  #15960  (Permalink
Alt 06.10.2021, 14:13
pusiofre pusiofre ist gerade online
Mitglied
 
Registriert seit: 25.04.2020
Beiträge: 465
Standard AW: SuperVectoring (VDSL2 Annex Q) Sammelthread

Zitat:
Zitat von pufferueberlauf Beitrag anzeigen
AVM koennte einen BQL/AQL alalogen Mechanismus in die Egress Seite des DSL-Treibers einbauen und sich damit einen egress Shaper sparen, nur ist der Egress ja bei VDSL2 immer kleiner als der Ingress, so dass damit jetzt nicht soviel CPU-Zyklen gespart werden koennen....
Ich glaub nicht, dass es an mangelnder CPU-Leistung liegt, dass man so was nicht standardmäßig einbaut. Den Telcos wird eher daran gelegen sein, dass die Leute einen teureren Tarif buchen, anstatt mit ein bisschen Software den Bedarf danach zu ruinieren.

Vor allem dort, wo man am meisten davon profitieren würde, nämlich bei wirklich lahmen DSL-Anschlüssen, sollte der CPU-Overhead komplett vernachlässigbar sein.
Mit Zitat antworten
 
Anzeige
Antwort

Stichworte
annex q, supervectoring, vdsl35b


Aktive Benutzer in diesem Thema: 14 (Registrierte Benutzer: 1, Gäste: 13)
w.erik
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.

Gehe zu

Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
Annex J Sammelthread III (FAQ/Status 07/2017 in Posting #1) gerryst Internet via Telefonkabel (ADSL, ADSL2+, VDSL2, SVDSL, G.FAST und SDSL) 2874 21.10.2021 09:39
Telekom Annex B-ANCP-RAM 384-6000 Sammelthread II - Status 5/2014 in Posting #1 Ehemalige Benutzer Internet via Telefonkabel (ADSL, ADSL2+, VDSL2, SVDSL, G.FAST und SDSL) 3364 19.09.2018 12:07
Modem hat vollen VDSL2-50 Sync, aber Downloadraten sind die von VDSL2-25 Dani77 Telekom 9 22.09.2015 16:36
Annex J Sammelthread II (FAQ/Status 11/2013 in Posting #1) gerryst Internet via Telefonkabel (ADSL, ADSL2+, VDSL2, SVDSL, G.FAST und SDSL) 8507 29.07.2014 11:54
EWE VDSL2/NGN on TPLink 1043ND + Spaihron 1113 VDSL2 Modem Chris3000 Regionale Provider 35 31.08.2013 08:15


Alle Zeitangaben in WEZ +2. Es ist jetzt 20:43 Uhr.


Basiert auf vBulletin®
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.