Leitung zu schnell ausgelastet - Priorisierung möglich?

[WhiteVelvet]

Hallo zusammen,

ich habe erst seit kurzem eine neue T-Online DSL16000 Leitung, die effektiv auf 12000 läuft. Ich habe aber früher (Unitymedia und auch kleinere T-Online-Leitungen) niemals das Problem gehabt, dass mir P2P Datenverkehr (Musik-Bootlegs über uTorrent) das komplette Netz lahmlegt. Damals musste ich den Upload auf 50% limitieren, damit HTTP Verkehr nicht darunter litt. Der Download war immer egal, frühere Router haben das immer korrekt priorisiert. Heute legt mir aber der Download alles lahm. Der Router ist eine Fritzbox 7490. Kann ich da irgendwas einstellen, dass bestimmte Ports niedrig priorisiert werden? Oder HTTP höher? Liegts vielleicht daran, dass ich heute UPnP nutze und damals fixe Ports?

[Argo Zero]

https://avm.de/service/fritzbox/fritzbox-7390/wissensdatenbank/publication/show/228_Internetzugang-fuer-wichtige-Netzwerkgeraete-und-anwendungen-priorisieren/

Das kann deine FritzBox auch. Kannst es mal ausprobieren und schauen, ob es etwas bringt.

[lumines]

AVM benutzt vier verschiedene SFQ-Queues[0], welche die vier Prioritätsstufen im Webinterface abbilden. Eigentlich sollte man meinen, dass innerhalb der jeweiligen Queues durch SFQ alles fair gehandhabt wird, aber aus irgendeinem Grund läuft da irgendetwas schief und die Latenz schießt trotzdem auf >600ms unter Last (bei meiner FB 6490), wenn ich nur einen einzigen Upload starte. Wenn ich aber den Dienst in eine der höher priorisierten Queues stecke, bleibt die Latenz wie zu erwarten auch unter Last unten und es fühlt sich auch ganz normal nach SFQ an. Warum das so ist, weiß ich leider nicht. Bei anderen QoS-Systemen mit SFQ-Queues habe ich so ein Verhalten noch nie gesehen und eigentlich ergibt das für mich auch keinen Sinn. Solange die höher priorisierten SFQ-Queues nicht ausgelastet sind, sollte die „normale“ SFQ-Queue nicht so ein Verhalten zeigen. Im Link wird noch gezeigt, dass die ACKs von TCP-Verbindungen in eine höher priorisierte Queue eingeordnet werden, was natürlich auch zu diesen Problemen führen könnte. Keine Ahnung, warum sie denken, dass das eine gute Idee ist, weil das ihr gesamtes System unterwandert.

Aus dem Link kann man nachvollziehen, dass mindestens auf der FB 7360 in der Konfiguration bei dem Typ auch kein Trafficshaping stattfindet. Die unterschiedlichen Erfahrungen (man findet viele Leute alleine hier im Forum, bei denen keine Problem auftreten, bei anderen allerdings doch) mit dem FB-QoS könnten daher damit zusammenhängen, dass sie selbst kein Trafficshaping macht und erwartet wird, dass der Provider das erledigt oder das Modem einfach keinen Bufferbloat hat (was keine besonders realistische Annahme ist).

Der ganze Priorisierungskram auf den Fritzboxen fühlt sich aber insgesamt ziemlich unberechenbar an und ist für mich eine Blackbox, die ich nicht so ganz durchschaue. Warum sie nicht einfach eine „simple“ Variante davon anbieten, in der einfach eine große SFQ- oder fq_codel-Queue benutzt und Trafficshaping erzwungen wird, kann ich nicht so ganz nachvollziehen. Das ist zwar streng genommen dann kein QoS mehr, aber es löst die meisten Probleme trotzdem und macht QoS für viele Leute überflüssig.

Es könnte damit zusammenhängen, dass sie vielleicht für bestimmte Sachen wie NAT und die Firewall auf Offloading-Funktionen des SoCs zurückgreifen und die deaktiviert werden, wenn sie Trafficshaping machen. Das kenne ich jedenfalls so von Ubiquitis EdgeRouter. Vermutlich wollen sie das vermeiden. Trotzdem sehr seltsam, dass sie in manchen (den meisten?) Konstellationen in Kauf nehmen, dass ihr QoS dann bricht. Wenigstens als Option wäre erzwungenes Trafficshaping auf der Fritzbox sehr hilfreich.

Das sind jetzt vielleicht ein bisschen zu viele Informationen, aber das sind jedenfalls meine Erfahrungen bisher.

Der Download ist natürlich noch einmal so eine Sache. Da macht die Fritzbox genau gar nichts. Vermutlich nehmen sie an, dass sie den Download nicht priorisieren können. Das stimmt zum Teil, aber dennoch kann man Pakete nach bestimmten Mustern droppen und darüber priorisieren, weil TCP sich bei fehlenden ACKs selbst reguliert. Ich hatte nie Probleme mit einer SFQ-Queue im Download. Moderne Linux-Kernel machen das auch problemlos für UDP. Wenn man ECN benutzt, kann man sogar komplett ohne Packet Loss bei TCP auskommen.

[0] https://plus.google.com/+HenkPoley/posts/3WYTBAYV2yx

TL; DR: Ausprobieren, ob man mit den höheren Priorisierungsstufen bei der Fritzbox Erfolg hat. Ansonsten wird man wohl nicht viel machen können.

So oder so müssten AVM ihr QoS-System einmal vollständig überdenken. Sie haben leider die Entwicklungen der letzten fünf Jahre vollständig verschlafen. Ich habe zusammen mit dem 3.10er Kernel in FritzOS 6.50 viele Neuerungen in dem Bereich erwartet, die trivial umzusetzen gewesen wären, aber offenbar haben sie sich dagegen entschieden die neuen Queuing-Strategien zu nutzen. Vielleicht kommt das irgendwann noch, aber ich würde nicht darauf wetten, dass das in nächster Zeit passiert.

fq_codel kommt mit BitTorrent noch vergleichsweise gut klar. Nicht perfekt, aber man muss auf jeden Fall keine Verrenkungen machen oder gar 50% im Upload limitieren, damit man die Leitung noch halbwegs nutzen kann.

[burninghey]

Hab vor Jahren, als Torrent noch aktuell war, cFoS Speed gekauft, und seither nie Probleme. Wenn doch, dann fix am Rechner eine niedrigere Priorität zugewiesen.

Gibt es auch unter anderem Namen zu manchen Boards dazu (Asrock, Asus, Gigabyte, MSI)

[WhiteVelvet]

Danke für die sehr ausführliche Antwort lumines. Also stimmt da doch etwas nicht mit der Fritzboxen im generellen. Früher musste ich ja auch nichts irgendwo einstellen am Router. Das hatte immer gut geklappt... und dann kostet so eine Fritzbox auch gleich so ein heiden Geld...

[Ati75]

Ich hatte mit meiner FB 7490 auch teilweise massive Probleme. Sogar beim Telefonieren und gleichzeitigem Steam Download. Telefonate waren alle abgehackt, da wurde nichts bevorzugt behandelt. Alle Einstellungen in der Fritzbox durchprobiert, nichts hat was gebracht. Die Lösung kam dann vom Provider. Er musste ein paar Settings nochmals setzen. Passierte bei mir, nachdem ich auf einen neuen Port gesetzt wurde. Wahrscheinlich wurden ein paar Einstellungen nicht angepasst. Würde jedoch bedeuten, dass zumindest in meinem Fall die Fritzbox mal gar nichts Richtung Traffic Shaping getan hat.

Im ip-phone Forum gabs auch schon mal den einen oder anderen Thread diesbezüglich. Ich überlege mir einen "gescheiten" Router hinter die FB zu setzen. Die Fritzbox muss ich wegen der Telefonie nutzen.

Auch von mir ein Dankeschön an lumines. Immer wieder sehr aufschlussreich deine Posts bzgl. QOS und Netzwerkangelegenheiten!

[lumines]

Die betroffene Fritzbox 6490 läuft übrigens an einem Kabelanschluss bei Unitymedia. Ich kann auch mit einer Fritzbox 7360 an einem VDSL-Anschluss von Netcologne gegentesten und da sieht es vollkommen anders aus. Wenn ich mit iperf mehrere Uploads mache, landen die wie zu erwarten in der „normalen“ Prioritätsstufe, die Latenz erhöht sich auch etwas, aber schießt nicht so seltsam durch die Decke. Mit drei laufenden iperf-Istanzen habe ich in etwa ~80ms Latenz, ohne ~35ms. Vollkommen unwissenschaftlich getestet in Quake 3. Interessanterweise ändert sich am Ping mit ICMP genau nichts, daher vermute ich, dass ICMP automatisch in eine höhere Prioritätsklasse eingeordnet wird.

Bei der FB 6490 dagegen kann ich schon anhand eines ICMP Pings mit nur einem Upload per iperf eine Latenz von >600ms messen. Wohlgemerkt beide mit der gleichen, standardmäßigen QoS-Konfiguration in der Fritzbox und auf der gleichen Firmware-Version (6.50).

So richtig erklären kann ich mir das nicht. Die FB 7360 ist übrigens ungebrandet, die FB 6490 läuft mit der veränderten Firmware von Unitymedia. Da das Problem allerdings auch hier bei einigen mit der FB 7490 auftritt, kann ich da auch kein Muster erkennen. Alles jedenfalls sehr seltsam.

[d2kx]

Kurzes Update:

Der Firmware der Fritz!Box 7580, die im August auf den Markt kommt, ist zu entnehmen, dass AVM wohl *endlich* an der Problematik gearbeitet hat, die @lumines schon angesprochen hat. Siehe hier. (http://www.ip-phone-forum.de/showthread.php?t=286556&p=2169351&viewfull=1#post2169351)

hier ist es ein 3.10.12-Kernel. Für die Fans des "codel"-Schedulers beim QoS ist es vielleicht eine gute Nachricht, daß der als LKM in der AVM-Firmware enthalten ist ... keine Ahnung, ob er auch benutzt wird (das sieht ohnehin anders aus als bei bisher bekannten Modellen). [...]

Wie es aussieht, gibt es ein Kommando "ppacmd", mit dem man das Verhalten des Packet-Accelerators in vielen Aspekten beeinflussen kann ... das könnte ja mal richtig interessant werden. Auch für den Packet-Classifier beim QoS scheint es ein Programm zur Steuerung zu geben (das nennt sich "cli") - vielleicht ist es mit weiteren zusätzlichen Programmen ja wirklich mal möglich, da ein flexibleres QoS-Management aufzubauen, zumindest gibt es dafür jetzt einen Daemon (qosd) in der Firmware, während es vorher und nachher (beim VR9 mit 3.10.73) wohl alles im dsld/kdsld enthalten ist. [...]


Ob das in der Praxis so funktioniert, wie man es etwa von OpenWRT oder anderen Routern kennt, wird sich zeigen müssen, aber man darf optimistisch sein. Die Frage ist jetzt nur, ob die Verbesserungen noch in neue Firmware für die bisherigen Fritz!Boxen zurückportiert werden.

[anddill]

http://www.heise.de/newsticker/meldung/AVM-veroeffentlicht-Fritz-OS-6-60-3258193.html

Schnelleres Surfen, bessere Internettelefonie
Laut AVM bringt das Update zudem Verbesserungen im Bereich der Internettelefonie. Diese soll in deutlich höherer Qualität möglich sein. Auch bei gleichzeitiger Datenübertragung soll sich die Sprachqualität verbessern und die Verbindung schneller hergestellt werden. Darüber hinaus verspricht AVM dank DNS-Optimierung schnelleres Surfen, Streaming und Gaming.

ups, zu spät. Na egal.

[d2kx]

http://www.heise.de/newsticker/meldung/AVM-veroeffentlicht-Fritz-OS-6-60-3258193.html

ups, zu spät. Na egal.

Nope. Die Verbesserungen in Fritz!OS 6.60 haben nichts mit der Bufferbloat-Problematik gemein und sind bis auf die Telefon-Änderungen leider eher lächerlich.

[anddill]

Ach so, anderes Thema.