Diverses: 6490, 6590, Puma6-Probleme bei anderen Herstellern, Puma7-Design

[robert_s]

Mit dem Thema "bufferbloat mit tc bekämpfen" haben sich schon einige beschäftigt, wohl teilweise auch mit Modifikationen von tc:

https://www.bufferbloat.net/projects/codel/wiki/Cake/

Und dann habe ich noch dieses Konfigurationsscript für tc gefunden:

https://gist.github.com/bradoaks/940616

Würde das auch mit dem "AVM-tc" funktionieren...?

Da ist von "SFQ" die Rede... Das hat doch auch Arris in seinem Paper zum Thema Bufferbloat als beste Lösung empfohlen:

http://snapon.lab.bufferbloat.net/~d/trimfat/Cloonan_Paper.pdf

Kann der "AVM-tc" auch SFQ?

 

[PeterPawn]

Der SFQ-Scheduler ist bei AVM an Bord, wird auch von AVM selbst verwendet. Der sorgt aber nur dafür, daß wirklich jeder "IP flow" mal zum Zuge kommt und nicht ein einziger Client mit einer Verbindung eine Queue komplett blockiert, nur weil er die Daten am schnellsten und "am Stück" anliefern kann. Man kann sich den als eine Art Multiplexer vorstellen, der die Kapazität (gerecht) zwischen allen Clients (besser "Verbindungen", weil ein Client auch das Fünffache an Verbindungen eines anderen haben kann und dann bei SFQ auch das Fünffache "vom Kuchen" abkriegen würde) verteilt.

Aber auch der HFSC-Scheduler ist bei der 6490 vorhanden (06.63):

# [COLOR="#0000FF"][B]find /lib/modules/$(uname -r)/kernel/net/sched[/B][/COLOR]
/lib/modules/2.6.39.3/kernel/net/sched
/lib/modules/2.6.39.3/kernel/net/sched/cls_basic.ko
/lib/modules/2.6.39.3/kernel/net/sched/cls_tcindex.ko
/lib/modules/2.6.39.3/kernel/net/sched/sch_cbq.ko
[COLOR="#008000"]/lib/modules/2.6.39.3/kernel/net/sched/sch_hfsc.ko[/COLOR]
/lib/modules/2.6.39.3/kernel/net/sched/sch_htb.ko
/lib/modules/2.6.39.3/kernel/net/sched/sch_llq.ko
/lib/modules/2.6.39.3/kernel/net/sched/sch_prio.ko
/lib/modules/2.6.39.3/kernel/net/sched/sch_red.ko
/lib/modules/2.6.39.3/kernel/net/sched/sch_sfb.ko
/lib/modules/2.6.39.3/kernel/net/sched/sch_sfq.ko
/lib/modules/2.6.39.3/kernel/net/sched/sch_tbf.ko

und wohl sogar geladen:

# [COLOR="#0000FF"][B]lsmod | grep sch[/B][/COLOR]
[COLOR="#008000"]sch_hfsc               13497  0[/COLOR]
sch_sfq                 5132  4
sch_llq                 6791  1
sch_tbf                 3661  1

Theoretisch ließe sich also vermutlich auch eine andere Scheduler-Queue aufbauen (der HFSC könnte den TBF als Wurzel ersetzen) ... ob und wann aber der "dsld" auf der Basis der AVM-Konfiguration dann wieder seinen Kopf durchsetzen will und diese Einstellungen selbst wieder erneuert, weiß ich nicht.

 

[robert_s]

Theoretisch ließe sich also vermutlich auch eine andere Scheduler-Queue aufbauen (der HFSC könnte den TBF als Wurzel ersetzen) ... ob und wann aber der "dsld" auf der Basis der AVM-Konfiguration dann wieder seinen Kopf durchsetzen will und diese Einstellungen selbst wieder erneuert, weiß ich nicht.

Einen Reset der tc-Konfiguration würde ich erst bei einer Neusynchronisation oder einem Neustart erwarten, also das könnte schon eine Weile halten, wenn man die im laufenden Betrieb verändert. Zumindest habe ich früher mal bei einem "etwas schwachbrüstigen" Speedport/Fritz!Box-Modell den Befehl "tc qdisc del dev xxx root" verwendet, um die Einbrüche bei 50Mbps-Downloads zu verringern, welche sich sonst zeigten, und das "hielt" auch bis Neusync/-start.

Aber wenn der "Baukasten" komplett ist und es nur eine bessere Konfiguration braucht, kann man das ja auch an AVM weitergeben, damit die das gleich richtig machen und keine Nachbesserung mehr nötig ist...

 

[fesc]

So, jetzt mal ein paar Tests und Beobachtungen, basierend auf verschiedenen tc Einstellungen.

tc syntax (z.B. 2kbit):
/sbin/tc qdisc change dev erouter0 handle 2:0 root tbf burst 12800/8 latency 10ms mtu 1600 mpu 64 rate 2000kbit

1. Generell, entgegen meiner fruehreren Vermutung: das "balancing" des traffics verschiedener hosts im netz scheint halbwegs zu funktionieren, pings von rechner A waehrend rechner B einen upload/bufferbloat test macht werden nicht im gleichen Masse verzoegert wie die von B. Das passiert "nur" wenn Rechner A der ARM core ist, dann ist dort die RTT genauso gross wie die von B.

2. Traffic der NICHT vom arm core kommt scheint durch das was ich mit tc aendere nicht beeinflusst zu werden (auch wenn ich extrem schlechte Werte nehme):
- Der Test bei dslreports spuckt die gleichen Messungen aus, egal was ich einstelle.
- Auch der Atom core kann genauso schnell hochladen.
- nur der ARM core wird entsprechend limitiert.

Ich habe das mit einem public ftp server getestet indem ich ein file via ftpput von arm bzw. atom hochlade. ARM wurde entsprechend limitiert, Atom nicht.
Das bestaetigt meine Vermutung dass tc sich nur auf den IP stack im arm core auswirkt. Die entsprechenden "sch_XXX" kernel-Module sind ja die original Linux sourcen.

Es wird wohl was proprietaeres sein was das queue scheduling (im eRouter?) konfiguriert. Dass da ein scheduling stattfindet sieht man ja daran dass sich hier nicht alle rechener die gleiche queue teilen. Werde da mal weitersuchen.
Nichtsdestotrotz ist irgendeine queue (im eCM?) viel zu gross dimensioniert, wie der riesen bufferbloat und der Test mit vorgeschaltenem OpenWRT routers zeigt.
Phasenweise zeigt dslreports eine uploadrate von 7Mbps an, obwohl ich nur 4 habe. Da laeuft die queue dann voll, im Schnitt ist es am Ende dann die erwartete 4. Dass das bei anderen speed-tests nicht passiert liegt wohl daran das dslreports mit mehreren testpartnern kommuniziert.

 

[robert_s]

So, jetzt mal ein paar Tests und Beobachtungen, basierend auf verschiedenen tc Einstellungen.

tc syntax (z.B. 2kbit):
/sbin/tc qdisc change dev erouter0 handle 2:0 root tbf burst 12800/8 latency 10ms mtu 1600 mpu 64 rate 2000kbit
[...]
Ich habe das mit einem public ftp server getestet indem ich ein file via ftpput von arm bzw. atom hochlade. ARM wurde entsprechend limitiert, Atom nicht.
Das bestaetigt meine Vermutung dass tc sich nur auf den IP stack im arm core auswirkt.

Auf welchem Core hast Du denn den tc-Befehl eingegeben? Auf beiden, oder nur auf dem ARM? Wie sieht denn die tc-Konfiguration auf dem Atom aus, wenn es da eine gibt? Vielleicht muss man an der drehen?

 

[fesc]

Auf welchem Core hast Du denn den tc-Befehl eingegeben? Auf beiden, oder nur auf dem ARM? Wie sieht denn die tc-Konfiguration auf dem Atom aus, wenn es da eine gibt? Vielleicht muss man an der drehen?

Hatte ich in einem frueheren posting schon mal geschickt (34). Da ist nix besonderes eingestellt. Fuer die Kontrolle der ganzen datenpfade ist aber der arm zustaendig.

 

[robert_s]

Hatte ich in einem frueheren posting schon mal geschickt (34). Da ist nix besonderes eingestellt. Fuer die Kontrolle der ganzen datenpfade ist aber der arm zustaendig.

Ah, ich hab auch das Blockdiagramm wiedergefunden.

Da der ARM auch das VoIP macht - könnte es also sein, dass die einzige voreingestellte "Priorisierung", nämlich "Internettelefonie", auch die einzige ist, die tatsächlich funktioniert...?

 

[Sharky444]

Da der ARM auch das VoIP macht - könnte es also sein, dass die einzige voreingestellte "Priorisierung", nämlich "Internettelefonie", auch die einzige ist, die tatsächlich funktioniert...?

Bingo! Versuch mal den Uplink auf PC1 auszulasten und dann einen Download über einen PC2 der prioritisiert wurde zu starten. Es wird nicht viel gehen. Von QOS keine Spur. Die VoIP Telefonie macht aber keinerlei Aussetzer!

 

[robert_s]

Von QOS keine Spur. Die VoIP Telefonie macht aber keinerlei Aussetzer!

Was aber möglicherweise auch nicht das Verdienst von AVM's Priorisierung ist. Lösch doch mal probeweise die Echtzeitanwendung "Internettelefonie". Geht VoIP dann immer noch ohne Aussetzer auch in Lastsituationen?

Dann käme das dadurch, dass über DOCSIS Priorisierungsregeln für bestimmte Adressen/Protokolle/Ports gesetzt werden können, und ich glaube, das wird für SIP auch gemacht.

 

[johnripper]

Ich hatte mal den fall dass ich extrem schlechte qualitaet beim telefonieren hatte, bis ich gemerkt habe dass ich gleichzeitig ein grosses file via scp auf den arm core geschoben habe ....

Ich hatte das mal getestet:

Konfig:
- Anbieter UM/KabelBW),
- automatische Provisionierung der Telefonie durch Anbieter (Providerbox),
- LAN2LAN zwischen 6490 und 7490.

Der Durchsatz (Upstream) liegt bei ca. 5-7 Mbit, wobei der Durchsatz unregelmäßig schwankt.
DECT Telefonie ist quasi nicht mehr möglich, da die Verbindung abgehackt ist.
Drosselt man das Ganze auf ca. 4-4,5 Mbit, dann funktioniert die DECT Telefonie wieder. Hängt aber tw. vom DECT-Endgeräte ab.
DECT Telefonie reduziert den Durchsatz grds. um ca. 1,5-2 Mbit.

Gesendet von meinem SM-G935F mit Tapatalk

 

[fesc]

Ich habe die Information dass in einer der naechsten Versionen (nach 6.63) das Latenzproblem angegangen wird.
Vielleicht hat ja jemand schon 6.8x und kann mal einen test bei dslreports machen ..

 

[robert_s]

Ich habe die Information dass in einer der naechsten Versionen (nach 6.63) das Latenzproblem angegangen wird.
Vielleicht hat ja jemand schon 6.8x und kann mal einen test bei dslreports machen ..

Hat jemand im Primacom-Forum, der die 6490er Firmware 6.83-44269 zum testen bekommen hat, schon gemacht, und beim BufferBloat ein "B" bekommen. Auf nähere Nachfrage stellte sich aber heraus, dass das wohl seinem Cisco-CMTS geschuldet ist. Dass die Arris-CMTS ein BufferBloat-Problem haben, ist, wie ich erfahren habe, schon länger bekannt, und soll mit einer neuen CMTS-Firmware behoben sein. Also wenn man an einem Arris-CMTS hängt, löst sich das "BufferBloat"-Problem vielleicht irgendwann ohne Zutun von AVM.

Unabhängig davon bleibt natürlich die Frage, ob die "Priorisierung"sfunktion bei den Cable Fritz!Boxen irgendeine Wirkung hat...

 

[fesc]

Was VPN betrifft, ich habe mal OpenVPN auf dem Atom aktiviert. Mangels schneller client-anbindung konnte ich den Durchsatz noch nicht messen, aber immerhin kann ich darueber Fernsehen ohne dass die GUI merklich langsamer ist.
Das ganze auf dem ARM zu machen, und noch dazu im kernel, scheint eine ziemlich schlechte Idee zu sein.

Was ich seltsam finde ist dass der pcd Prozess so hoch ausgelastet ist, obwohl er eigentlich nix mit VPN zu tun haben sollte (und laut strace auch nichts tut ..).

- - - Aktualisiert - - -

Hmm, ich haenge auch an einem Cisco CMTS und bekomme F.
Ein vergleich mit 6.63 waere hilfreich.

 

[robert_s]

Hmm, ich haenge auch an einem Cisco CMTS und bekomme F.

Hast Du mal den Link zu einem Ergebnis gepostet?

Bei mir (mit 6590 FW 6.83) sieht das so aus:

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

Und wie man sieht, ist der Bufferbloat in Upload-Richtung in Ordnung, und in Download-Richtung ist es eben das fehlende Buffermanagement des Arris-CMTS, das für diese enormen Latenzen unter Volllast sorgt.

Daher wäre mal interessant, in welcher Richtung bei Dir der schlechte BufferBloat-Wert zustande kommt...

 

[fesc]

Immer upload:

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

Wobei der noch gut war, habe oft bis 3000ms

 

[robert_s]

Immer upload:
http://www.dslreports.com/speedtest/14832670

Das ist interessant, denn im Primacom-Forum gibt es jemanden, der auch mit der 6.83-44269 FW und am Cisco-CMTS ähnliche Ergebnisse wie Du bekommt - während jemand anderes einwandfreie Ergebnisse erhält.

Im Vergleich aller Ergebnisse fällt auf, dass offenbar Tests über IPv4 einwandfrei im Upload sind, Tests über IPv6 dagegen nicht. Also scheint das Buffer Management der Fritz!Box nur für IPv4 zu funktionieren, nicht für IPv6...?!?

 

[PeterPawn]

Ich denke immer noch, daß es auch in nicht unerheblichem Maße von der Auslastung des Segments beim Provider abhängig ist.

Ich hänge mit einer 6490 (06.63) an einem Arris-CMTS (100er-Vertrag bei VF/KDG, 20/4 Kanäle provisioniert) und erziele dieses Ergebnis: http://www.dslreports.com/speedtest/14834874 (06.05.2017, 01:04 Uhr)

Ich will jetzt nicht einschätzen, ob hier bei mir Bufferbloat ein echtes Problem ist - 500 ms bei "heavy load" im Upstream sind jetzt nicht so "extrem" in meinen Augen, zumal die Daten ja auch nur recht langsam "abfließen" können und beim Download macht sich ja praktisch gar kein Bufferbloat bemerkbar bei mir. Wenn überhaupt, dann hat die 6490 bei mir auch eher ein Bufferbloat-Problem im Upload und das auch mit IPv4.

IPv6 kann ich gerade nicht testen ... aber ich finde schon, daß bereits die IPv4-Ergebnisse ja sehr stark unterschiedlich sind - nun war aber mein KDG-Test auch mit der 6490 und der älteren Firmware, damit ist das (selbst wenn man die beiden KDG-Tests vergleicht) schon etwas mit Äpfeln und Birnen. Sofern aber da die 6590 mit der 06.83 dann der Maßstab sein oder werden sollte, wenn es um Bufferbloat im Download geht (der ja auch davon verursacht werden kann, daß nunmehr das eCM die Daten nicht mehr schnell genug an den eRouter weiterreichen kann), dann darf AVM da gerne noch eine Weile dran feilen.

 

[enno25]

Arris CMTS <-> 6590 :: Vodafone Kabel

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

 

[fesc]

Bzgl upload ist auch immer die Kurve interessant: Bei mir und bei @PeterPawn sieht man dass anfangs die Rate hoeher ist als die eigentliche Bandbreite. Da laeuft ein zu grosser buffer voll und sorgt fuer die schlechte Latenz (und TCP kann die window-groessen nicht schnell genug nachregulieren da erst mal keine Pakete gedroppt werden).
Das scheint bei 6.83 nicht der fall zu sein, die kurve ist glatt und die Latenz gut. Gleiches sehe ich bei mir wenn ich einen OpenWRT router davorschalte.

Bei letzterem sehe ich auch kleine, regelmaessige Schwankungen, etwa wie bei @robert_s. Das scheint ein Effekt des queueing algorithmus zu sein.

Beim Download kann ich mir auch nur vorstellen dass beim Uebergang im CMTS auf die "langsame" (200 haette ich auch gerne ) Geschwindigkeit im Kabelsegement das buffering nicht gut ist (d.h. Buffer zu gross). Dieser Effekt wird natuerlich um so staerker je hoeher das Kabelsegment ausgelastet ist, wobei man das ja an der gemessenen Downloadrate sehen sollte.

Ich sehe den gleichen Effekt wieder wenn ich bei meinem OpenWRT die download-bandbreite reduziere, d.h. Kabel-Bandbreite >> OpenWRT-Bandbreite. Dann sehe ich dort auch eine hohe download-latenz.
Wobei hier natuerlich die 6490 nur bedingt was dafuer kann da sie ja nicht wissen kann wie schnell der nachgeschaltete router ist. Ich denke man ging davon aus dass LAN immer schneller als Kabel ist und deshalb in dieser Richtung nur einen einfachen queuing machanismus hat (head of line blocking). Ob das bei zunehmender download-rate noch zeitgemaess ist wage ich zu bezweifeln, gerade wenn man im wlan haengt. Man sieht das ja dass beim Atom (der die WLAN bridge per software macht) keinerlei queue algorithmen eingestellt sind (anders als beim ARM).
D.h. ich denke dass man auch dort auf bessere Algorithmen gehen muesste.

- - - Aktualisiert - - -

@robert_s : Wobei deine "idle ping" latenz natuerlich schon extrem schlecht ist, was ist denn da los?

 

[enno25]

@Robert_S

Habe den Test auch mal mit IPv6 gemacht, da konnte ich aber keinen Unterschied feststellen zu einem reinen IPv4 Anschluss.