QoS: Best practice?

[mr44er]

Mal die Frage in die Runde, welche Daumenregel(n) ihr für QoS habt.

https://www.lullabot.com/articles/eliminating-robots-and-voip-glitches-with-active-queue-management

Anhand des Artikels ist CoDel aktuell die Empfehlung. Kann man den Artikel für den Anfang als 'okaye' Richtlinie nehmen?

Wie ist das mit Luft lassen wegen overhead? Laut Artikel nimmt man 3% dafür.

Anliegen habe ich Down Stream : 57600Kbps / Up Stream : 11512Kbps, was genau der Drosselung des Providers entspricht. Es sollte eigentlich schon Ende '18 auf Vectoring umgeschaltet werden, aber das ist eine andere Geschichte.
Also 3% Luft von der anliegenden Bandbreite nehmen oder sollte ich messen oder hat jemand bessere Lektüre für mich?

 

[mr44er]

Ich antworte mir mal selber für das Gröbste.

tldr: FQ_CoDel ist wirklich fein!

Echte, ankommende Bandbreite zuerst testen, mehrmals. Mehrere Tageszeiten ausprobieren, sich für einen Durchschnittswert entscheiden und dann großzügig abrunden. In meinem Fall habe ich 46MBit/10MBit eingestellt, es gehen bei mir immer mindestens ~47/11 durch. Wenn man die pipes vom shaper zu knapp dimensioniert, gibts Bufferbloat.
Test dazu: http://www.dslreports.com/de/speedtest
Ohne shaping: Rating 'D', mit 47/11 in den pipes 'C' und mit 46/10 gibts 'A'

Gute Info gibts hier: https://www.bufferbloat.net/projects/codel/wiki/Best_practices_for_benchmarking_Codel_and_FQ_Codel/

Die Stellschrauben für den Aha-Effekt waren noch 'packet limit' und 'quantum', FQ_CoDel defaulted nämlich für 10GigE.
Weiterhin bringt aktiviertes ECN noch eine Verbesserung, aber das muss man ausprobieren. Auch, ob man es nur für seinen downlink aktiviert oder für beide Richtungen.

 

[PMc]

Moin.
Ein paar mehr Details wären hilfreich - vielleicht ein paar dürre Sätze, worum es eigentlich geht.

fq_codel kenne ich aus der manpage von ipfw, es ist dort eines der Dinge, die ich noch nicht ausgetestet hab (und es scheint einer der anspruchsvolleren zu sein, wo mir noch nichtmal recht klar ist wie man sowas sinnvoll praktisch einsetzt).

Der eingangs gelinkte Artikel wiederum scheint sich um VoIP zu drehen. Das ist wieder so eine Sache, bzw., aeh, schwierig...
Als man noch klassische Leitungen hatte, zB eine 2MBit leased line oder auch (mit Einschränkungen) 2MBit DSL, da war das einfach - die haben eine Quarzuhr, d.h. da laufen wirklich 2097152 Bit pro Sekunde. Wenn man also im einfachen Fall ungestört Radiohören (128kBit) will (oder zwei Telefonate vorsehen), dann rechnet man einfach 2048-128=1920, schiebt also den ganzen übrigen Traffic durch eine Pipe mit 1920kBit/sec, und das funktioniert dann.

Wenn man jetzt aber einen neueren Anschluss hat, zB 16/2.4MBit, dann erzählt einem der Telco, dass man maximal 16, minimal 6, und wahrscheinlich so im Durchschnitt irgendwas um 10MBit kriegt. Damit kann man überhaupt nix anfangen (es sei denn, die Leitung auf 6MBit limitieren und den Rest verschenken).
Und die These, dass man die Bandbreite dann eben messen soll, finde ich ungefähr so hilfreich wie Börsenkurse zu messen und danach zu investieren, oder präziser: "Meßwerte der Vergangenheit bieten keine Garantie für die Zukunft".

Ne gute Lösung für das Problem suche ich noch.

Wenn fq_codel da weiterführt, dann würde mich da zB ein Vergleich des jitter in "ntpq -p" interessieren.

 

[mr44er]

Ein paar mehr Details wären hilfreich - vielleicht ein paar dürre Sätze, worum es eigentlich geht.

Ich versteh jetzt nicht, was du genau meinst, weil du ja anscheinend weißt was Bandbreitenreservierung ist? Also es geht um Bandbreitenreservierung aka welche Dienste zu bevorzugen sind. Eigentlich ist mir das egal, aber genervt hat mich dann doch das Gekratze bei einem Telefonat bis zu Aussetzern, während eine Winkiste sich gerade Updates reinschiebt und am andern PC noch ein Download rennt. Wie das immer so ist, feilt man noch ein bissl mehr und optimiert dann einfach alles. Ich habe z.B. noch die tcp-acks und dns-abfragen bevorzugt, was Seiten noch einen Tacken fixer aufbaut. Grenzen gibt es da außer Bandbreite keine.

dann rechnet man einfach 2048-128=1920

Jup, das zwackt aber dauerhaft bei den anderen Diensten ab. Ich wollte dass die Reservierung dynamisch ist, dh. wenn ich downloade, dann soll die Leitung frei sein. Wenn ein Anruf kommt, soll der pipe soviel abgezwackt werden wie nötig (+eben ein wenig Luft, ist unvermeidbar) und das eben möglichst ohne Blut im Stuhl. Also nicht erst nach 20 Sekunden nach Hörer abheben einpendeln bzw. timeout beim Download, weil der Ping durch die Decke geht.

Jap, der telco schwätzt viel und hängt lieber noch einen zahlenden Kunden mehr dran, weil 'facebook geht damit ja noch', mehr will die Kundschaft heute auch nicht mehr.

Leitung auf 6MBit limitieren und den Rest verschenken

Genau das habe ich gemacht, da kommt man nicht herum. Hält sich aber in Grenzen bei mir, denn von den bezahlten '50' down kommen immer mind. 46,xx an. Tageszeit egal.

fq_codel ist schnell und 'seamless', wenn man so sagen will.

Habe null bis gar keine Erfahrung bisher (außer Theorie) mit shaping, aber was ich gelesen habe, ist fq_codel bisher so ziemlich das nonplusultra.

 

[PMc]

Ich versteh jetzt nicht, was du genau meinst, weil du ja anscheinend weißt was Bandbreitenreservierung ist?

Naja, ich weiss manches, aber manches auch nicht. Und bei Deinem Text blieben in meinem Kopf eine menge Fragen, zB der use-case (Endanwender mit DSL, SOHO oder irgendwas industrielles, und welche payload) oder die eingesetzte Technik.
Ich könnte mir zB vorstellen (ich weiss aber nix konkretes), dass die Leute, die da bei billiger-telefonieren ihre 010xx Vorwahlen anbieten, auch nur irgendwo nen Asterisk haben und ungenutzte interconti-Bandbreiten bartern. (Die Qualität deutet zuweilen auf sowas hin.)

Jup, das zwackt aber dauerhaft bei den anderen Diensten ab.

Das hatte auch ne andere Vorgeschichte. Ganz einfach (ist ein paar Jahre her), die nachbarn haben sich mangels DSL per modem ins Internet eingewählt, und da hab ich gesagt, nehmt doch einfach mein WLAN. Das Ergebnis war, dass ich von aussen nicht mehr auf meinen Server gekommen bin, und die Ursache war auch schnell klar: die hatten ein uraltes Windows, das nie einen patch gesehen hat (geschweige denn einen Virenwarner oder sowas), und dank der neuen Bandbreite haben sie sich wohl erstmal auf unkoscheren Seiten umgetan - und dann war die Kiste damit beschäftigt, E-Mails zu versenden was die Leitung hergibt. Nicht dass mich das gestört hätte, aber ich hab dann Vorkehrungen getroffen, dass immer ein bischen Bandbreite für meine remote shell frei bleibt.

Ich wollte dass die Reservierung dynamisch ist, dh. wenn ich downloade, dann solldie Leitung frei sein. Wenn ein Anruf kommt, soll der pipe soviel abgezwackt werden wie nötig (+eben ein wenig Luft, ist unvermeidbar)

Man könnte - das kommt mir jetzt grad so in den Sinn - wenn man Telefonie selber routet (aka Telefonanlage in Software), dann sollte der Asterisk ja wissen, wieviele Gespräche er grad aktiv hat, und kann die pipe entsprechend dynamisch umkonfigurieren. (Das mit dem Telefonie routen ist eine der Herausforderungen, die ich grad noch vor mir herschiebe - sieht aber verlockend aus.)

fq_codel ist schnell und 'seamless', wenn man so sagen will.

Da wäre interessant zu erfahren, wie Du es praktisch konfigurierst.
Die Konfiguration scheint nämlich einigermaßen verwickelt - der Kollege hier nutzt zB eine Syntax, die nicht in der manpage steht, und die zwar akzeptiert wird, aber scheinbar wirkungslos ist.

Und ich hab zwischenzeitlich ein bischen rumgebastelt, und eine vage Ahnung gekriegt, worum es gehen könnte (bisher hab ich nur entweder fixe Bandbreitengrenzen für bestimmte Dienste gemacht oder Gewichtugen mit "queue weight".)

Was bei der Testseite rauskommt, sieht dann so aus:

• unlimited: qualität = A buffering = C
• mit pipe-limit: qualität = C buffering = F
• mit pipe + fq_codel + queue: qualität = C buffering = A
• mit pipe + wf2q+ + queue mit 'mask all': qualität = A buffering = A
• mit pipe + qfq + queue mit 'mask all': qualität = A+ buffering = A

Ich will nicht behaupten dass ich verstehe was das alles bedeutet, und was dieser Test misst oder was dabei systemische Fehler sein könnten, oder gar was das dann in der realen Praxis bewirken mag...