QOS / Traffic Shaping mit der Fritzbox

[olistudent]

bump! Anyone on the following? C'mon I'm sure someone knows the answer

As far as I know this filter matches all rtp-traffic.

Greets, Oliver

 

[TheRealHoudini]

Hi Leute,

sorry aber ich hab mir nun den ganzen Thread 2x durchgelesen... und werd trotzdem daraus nicht schlau.

Zu meinem Problem:

Ich bin im Netzwerk mit 2 PCs, der eine zieht wie blöd von allen möglichen Quellen und der andere will surfen etc., bekommt aber von der 2 MBit Leitung vll. gerade mal 30-40kb/s Downstream.

Wie schaffe ich es anhand der ar7.cfg seine IP zu drosseln, sodass wenn der Surf-PC online geht, die Bandbreite 50:50 aufgeteilt wird?

Ich hoffe es kann mir das jmd. verständlich erklären, denn der letzte versuch selber an der ar7.cfg rumzubasteln, führte dazu, dass ich ein Recover ausführen musste...

Allgemein währe ein zusammengefasstes Tutorial zu diesem Thema nicht schlecht... :meinemei:

...ich würde es ja gerne machen, aber dazu sollte ich es erst verstehen

Also besten Dank für eure Bemühungen!
Gruß Houdini

 

[Wheeljack]

Jetzt habe ich hier eine 6000er Leitung und beim ersten Versuch sie auszureizen gibt's schon Probleme.
Ich wollte den großen Test machen und hab eine Knoppix DVD per Torrent (Azureus) gestartet. Nach kurzer Zeit ging der Download auf 660-680 kb/s hoch. Die VoIP-Qualität sollte darunter natürlich nicht leiden, daher ist bei Azureus ToS auf 0x02 eingestellt und läuft auch im Traffic-Shaping der Box entsprechend auf Priorität 0.
Beim ersten Selbstversuch (ich ruf mich selber an = 2x VoIP) schmiert die FritzBox 7050 direkt unter dieser Last ab und startet neu.
Erst bei extremen Drosseln der Downloadgeschwindigkeit (Azureus läuft inzwischen nur noch mit maximal 60 Verbindungen) auf so ca. 300kb/s bleibt wenigstens die FritzBox stabil, obwohl die VoIP-Qualität extrem leidet.
Wird für mich alles besser, wenn die 7170 endlich eintrudelt? Oder ist die fast genauso schwach auf der Brust?

 

[_lizard_]

hab mal p4 mit in die ar7.cfg genommen. ergebnis: stürzt nicht ab, gibt aber folgende fehlermeldung:

2006-10-28 16:24:30 unknown: /var/flash/ar7.cfg:615: member limit_p4 not found in ST_struct _limit
2006-10-28 16:24:30 unknown: /var/flash/ar7.cfg:615: member limit_p4 not in _limit, try to recover
2006-10-28 16:24:30 unknown: /var/flash/ar7.cfg:623: member limit_p4 not found in ST_struct _limit
2006-10-28 16:24:30 unknown: /var/flash/ar7.cfg:623: member limit_p4 not in _limit, try to recover
2006-10-28 16:24:30 unknown: /var/flash/ar7.cfg:638: member limit_p4 not found in ST_struct _limit
2006-10-28 16:24:30 unknown: /var/flash/ar7.cfg:638: member limit_p4 not in _limit, try to recover
2006-10-28 16:24:30 unknown: /var/flash/ar7.cfg:646: member limit_p4 not found in ST_struct _limit
2006-10-28 16:24:30 unknown: /var/flash/ar7.cfg:646: member limit_p4 not in _limit, try to recover
2006-10-28 16:24:30 unknown: load_config(ar7): warning: converted

Was ist ST_struct ?
firmware ist 14.04.15ds-0.2.9

 

[carstenlanger]

Was ist ST_struct ?

Der Teil "ST_struct _limit" sieht sehr nach einer klassischen C-Syntax aus.

Mein Vermutung:
Die Software der FB ist in C oder C++ oder so geschrieben. Der Teil, der das QoS handhabt, muss die ar7.cfg einlesen und interpretieren (= parsen). Dabei stopert er über "limit_p4" und versucht, eines solchen Eintrag in der internen Datenstruktur (ST_struct) mit Namen "_limit" zu finden. Einen solchen Eintrag gibt's dort aber anscheinend nicht.

Dass dann eine so hübsche Fehlermeldung kommt und statt eines Absturzes nur ein "waring: converted", ist wohl einem Programmierer zu verdanken, der die Fehlerbehandlung gnädigerweise so mit einprogrammiert hat.

Quintessenz: Es gibt wohl immer noch nicht mehr als 4 Prioritäten.

 

[carstenlanger]

Hallo,

der Beitrag von Mister2 ist zwar schon etws älter, aber noch hat - glaube ich - keiner ihm zugestimmt oder sonstwie seine Aufstellung kommentiert. Das möchte ich nachholen. Ich glaube nämlich, dass das eine ziemlich gute Zusammenfassung ist.

Ein Wort der Warnung vorab, meine Anmerkungen basieren auf dem Wissen von diesem Thread und meinem allgemeinen Wissen über andere QoS Implementierungen z. B. bei Cisco-Routers. Jedoch habe ich selbst noch keine QoS Einstellungen auf der FB vorgenommen, werde es aber bald tun.

Hallo,

ich habe noch ein paar Fragen zu den 4 Gruppen:

limit_total = 100;
limit_p0 = 40
limit_p1 = 60
limit_p2 = 80
limit_p3 = 0

Wenn ich alles was ich hier im Beitrag gelesen habe richtig verstanden habe, dann liest man das Ganze von p3 nach p0.

- Alles was unter out_rules die priority = 3 hat wird mit der höchsten Prio vom Rechner (bzw. Telefon) durch die Fritzbox ins I-Net durchgeschleust und zwar mit max dem %-Anteil vom max. möglichen Gesamtupload der hinter = eingetragen ist, bzw. bei 0 dann mit 100%.

- Alles was somit unter out_rules die priority = 2 hat muss somit warten bis das was priority = 3 hat durch ist, bzw. bekommt noch das was priority = 3 als "Restupload" übrig lässt.

- Alles was somit unter out_rules die priority = 1 hat muss warten bis das was priority = 3 und / oder priority = 2 hat durch ist, bzw. bekommt noch das was priority = 3 + priority = 2 als "Restupload" übrig lässt.

- Alles was somit unter out_rules die priority = 0 hat muss warten bis das was priority = 3 und / oder priority = 2 und / oder priority = 1 hat durch ist, bzw. bekommt noch das was priority = 3 + priority = 2 + priority = 1 als "Restupload" übrig lässt.

Erste Frage: Ist das so richtig ???

Ja, das sollte grundsätzlich so sein.

Falls das so ist, würde dies dann bedeuten, das wenn man z.B. DSL1000 hat und somit einen max. Upload von 160000 bps und dann ein Telefongespräch mit "G726-40" Codec = 63000 bps Brutto, welches in "priority = 3" mit "limit_p3 = 0" läuft führt, noch ein Rest von 97000 bps für die priority 2 bis 0 bleibt.

Genau.

Zweite Frage: Wenn man dann z.B. bei "limit_p2 = 80" eingetragen hat, bekommt dann alles was unter "priority = 2" läuft 80% von den restlichen 97000 bps = 77600 bps oder 80% von dem max Upload = 128000 bps ???

Im ersten Fall würde dann ja autom. noch ein Rest von 19400 bps für "priority = 1" und "priority = 0" übrigbleiben.
Im zweiten Fall würden für "priority = 2" ja schon keine vollen 128000 bps mehr vorhanden sein, da 160000 bps - 63000 bps = 97000 bps. Und "priority = 1" und "priority = 0" hätten dann komplett Pech gehabt.

Sehr wahrscheinlich heißt es 80 % der Gesamtbandbreite, also 128000 bps. So ist's in größeren Routern auch implementiert und alles andere wäre komplizierter zu programmieren.

Ja, das bedeutet, dass prio 1 und 0 Pech hätten und gar keine Pakete schicken könnten.

Dritte Frage: Wenn nichts mit "priority = 3" läuft und "limit_p2 = 80" ist, bekommt dann alles was "priority = 2" hat nur max. 80% von den 160000 bps ???

Wenn dem so ist, würde das ja dann bedeuten, das wenn z.B. "limit_p0 = 40" ist und nur etwas läuft was "priority = 0" hat, dann nur max. 40% der 160000 bps ausgenutzt würden obwohl 100% zu der Zeit zur Verfügung stehen könnten.

An anderer Stelle in diesem Thread wurde schon öfter bestätigt, das der Shaper wirklich limitiert, auch wenn mehr Bandbreite verfügbar ist. Also ja, limit_p0 = 40 heißt max. 40 %, auch wenn 100 % zur Verfügung stehen.

Vierte Frage: Würde es dann nicht mehr Sinn machen das Ganze so einzurichten:

limit_total = 100;
limit_p0 = 0
limit_p1 = 0
limit_p2 = 0
limit_p3 = 0

"fon-rtp" in "priority = 3"
"download-tcp-ack" in "priority = 3"
"dns" in "priority = 2"
"email" in "priority = 2"
"http-requests" in "priority = 1"
"filesharing" in "priority = 0"

Sprich, wenn telefoniert wird bekommt das Telefon das max was es braucht und falls dann zeitgleich Mails laufen bekommen die den max. Rest und Surfen bekommt den Rest, der dann davon noch übrigbleibt und Filesharing dann noch das was ganz zum Schluss abfällt.
Und wenn z.B. nur Filesharing läuft, steht dafür dann auch der Upload zu 100% zur Verfügung (abzgl. das was dann dadurch autom. bei "download-tcp-ack" anfällt).

Oder ist da ein Denkfehler drin ???

Danke für die Hilfe.

Nein, das würde m. E. nur zum Teil Sinn ergeben. Ich sehe das Problem, dass du gnadenlos einem Protokoll erlauben würdest, alle verfügbare Bandbreite für UL (Upload) zu nehmen und andere Protokolle würen nicht einmal ein Minimum bekommen. Das ist nicht sehr betriebssicher.

Wenn du deinen UL mit VoIP zumachst (ok, mehrere Gespräche gleichzeitig, oder großer Codec), dann könntest du nicht einmal mehr Surfen, obwohl du noch genug Bandbreite im DL (Dowlink) hättest. Denn zum Surfen brauchst du die TCP-ACKs, die dann aber keine Bandbreite mehr hätten und nicht gesendet werden könnten. Aus Gründen der Betriebssicherheit ist es m. E. besser, allen Protokollen eine minimale Luft zum Leben zu lassen. Daher sind die 95 % für prio 3, die hier öfter auftauchten, besser als die 0 = 100 %. Und prio 0 (Best effort) sollte immer 0 = 100 % bekommen, denn wenn der Verkehr schon endlich dran ist, d. h. keine Pakete höhere Priorität mehr im Puffer sind, dann gibt es ja keinen Grund, die restliche verfügbare Bandbreite (die bis zu 100 % sein kann, wenn nur prio 0 Verkehr da ist) auszunutzen.

Viele Grüße
Carsten

 

[carstenlanger]

Auch schon ein wenig älter:

Gibt es hier eigentlich nur Nutzer die sich über diese Funktion gegenseitig ihre bestehenden Trafficshaping Modifikationen posten oder kann das auch noch jemand erklären, was und warum was welche Auswirkungen oder Beeinflussungen ergibt!?

Ich möchte hier gerne etwas allgemeiner Aspekte zu QoS erklären.

Nochmal ein Wort der Warnung vorab, meine Anmerkungen basieren auf dem Wissen von diesem Thread und meinem allgemeinen Wissen über andere QoS Implementierungen z. B. bei Cisco-Routers. Jedoch habe ich selbst noch keine QoS Einstellungen auf der FB vorgenommen, werde es aber bald tun.

Also:
Im ganzen Thread sind m. E. immer 2 Dinge vermischt. Die Priorität von 0 bis 3 und die Bandbreitenbegrenzung (shaping). Dabei sind das verschiedene Dinge.

Das Verschicken eines Pakets vom Router über eine Leitung teilt sich eigentlich in 2 Arbeitsschritte auf, die unabhängig voneinander stattfinden.

1. Einsortieren der Pakete in die richtige Warteschlage für diese Leitung.
2. Abarbeiten der Warteschlangen und Raussenden der Pakete über die Leitung.

Das muss man wissen: es gibt immer Warteschlangen, bevor die Daten in einzelnen Bits über die Leitung gehen.

Schritt 1, Einsortieren der Pakete in die Warteschlangen/Puffer/Queues:

• Jedes Paket das auf einem Interface (z. B. DSL-Leitung für UL) verschickt werden soll, muss erst qualifiziert werden, d. h. gemäß Filterregeln (out_rules) wird die Priorität festgelegt.
• Zu jedem Interface gibt es 4 Puffer, pro Priorität eine.
• Das Paket wird entsprechend seiner Prio dort entsprechend einsortiert (wenn noch Platz ist, s. u).
• Das wird mit allen Paketen gemacht, die auf diesem Interface übertragen werden sollen.

Schritt 2, Abarbeiten der Puffer, quasiparallel zu Schritt 1. Hierfür ignorieren wir mal kurz den Shapingaspekt, nehmen also an, die bps_limits stehen alle auf 0:
Es läuft die ganze Zeit ungefähr folgende Prozedur ab:

1. Wenn im Puffer prio3 ein Paket ist, schicke es über die Leitung raus. Nachdem das Paket raus ist, Rücksprung zu 1. Falls kein Paket in Puffer prio3 war, weiter mit 2.
2. Wenn im Puffer prio2 ein Paket ist, schicke es über die Leitung raus. Nachdem das Paket raus ist, Rücksprung zu 1. Falls kein Paket in Puffer prio2 war, weiter mit 3.
3. Wenn im Puffer prio1 ein Paket ist, schicke es über die Leitung raus. Nachdem das Paket raus ist, Rücksprung zu 1. Falls kein Paket in Puffer prio1 war, weiter mit 4.
4. Wenn im Puffer prio0 ein Paket ist, schicke es über die Leitung raus. Nachdem das Paket raus ist, Rücksprung zu 1. Falls kein Paket in Puffer prio0 war, gibt's nix zu senden, weiter mit 1.

Und das alles hat noch nix mit Shaping zu tun, sondern ist soweit ein strict-priority-scheduler.

Wenn also jemand mit prio 3 bis 1 die UL-Bandbreite komplett dicht macht, dann werden alle prio0 Pakete im Puffer verhungern. Solch ein Puffer hat aber eine maximale Länge, nur weiß ich die von der FB nicht. Vielleicht jemand anders? Wenn der Puffer voll ist, dann kann beim Schritt 1 (Einsortieren) nichts mehr in den Puffer geschrieben werden, das Paket muss verworfen werden, es geht verloren.

Nun kommt es auf das Ende-zu-Ende Protokoll an, ob solch ein Paketverlust schlimm ist oder nicht.

• UDP hat keine Mechanismen, um Paketverluste zu bemerken. Da ist die Applikation gefragt, die UDP verwendet, ob sie damit leben kann. Bei VoIP geht z. B. die Qualität runter.
• TCP kann eine gewisse Zeit Paketverluste kompensieren, aber wenn man einen TCP Stream zu lange anhält, dann bricht er auch ab.
• Wenn der Datenstrom abbricht, oder zu lange ausbleibt, kommt es auf die Anwendung an, ob sie das kompensieren kann (z. B. einfach wieder neu anfängt), oder richtige Fehlermeldungen produziert und andere hässliche Sachen.

Insgesamt ist es eigentlich kein guter Stil, wenn TCP Ströme ganz abbrechen. Man kann sie auf seeeehr langsam runterfahren, aber ganz abbrechen ist oft für die Anwendung (z. B. FTP, HTTP) gar nicht gut.

Und nun kommt Shaping.
Damit nämlich auch z. B. ein Hintergrund-UL-FTP noch ne Chance hat, ganz langsam, aber ohne abzubrechen, zu existieren, muss ich ihm eine minimale Luft zum Leben lassen. D. h. ich darf nicht 100 % der Bandbreite für wichtigere Sachen zuteilen, sondern nur z. B. 95 % und den Rest für Best Effort (prio 0) übriglassen.

Beim Shapen werden in Schritt 2 die Pakete nicht nur strikt nach Prioritäten aus den 4 Puffern genommen. Es wird auch geguckt, ob im Mittel über die letzte Zeit (weiß jemand, welchen Algorithmus die FB wirklich als gleitenden Mittelwert nutzt?) die Pakete einer bestimmten Priorität auch die Limits für die Bandbreite (bps_limit) und Paketanzahl (pps_limit) eingehalten haben. Wenn die Limits überschritten sind, dann wird der entsprechende Puffer solange übersprungen, bis durch die Aktualisierung des gleitenden Mittelwert der Mittelwert wieder unter das Limit fällt.

Also hier Schritt 2, Abarbeiten der Puffer, quasiparallel zu Schritt 1, jetzt mit Shaping.:
Es läuft die ganze Zeit folgende Prozedur ab:

1. Wenn im Puffer prio3 ein Paket ist, prüfe, ob ein Limit (bps/pps) überschritten wurde. Wenn nein schicke es über die Leitung raus. Berechne einen neuen Mittelwert für bps/pps. Nachdem das Paket raus ist, Rücksprung zu 1. Falls kein Paket in Puffer prio3 war, oder ein Limit überschritten wurde, weiter mit 2.
2. Wenn im Puffer prio2 ein Paket ist, prüfe, ob ein Limit (bps/pps) überschritten wurde. Wenn nein schicke es über die Leitung raus. Berechne einen neuen Mittelwert für bps/pps. Nachdem das Paket raus ist, Rücksprung zu 1. Falls kein Paket in Puffer prio2 war, oder ein Limit überschritten wurde, weiter mit 3.
3. Wenn im Puffer prio1 ein Paket ist, prüfe, ob ein Limit (bps/pps) überschritten wurde. Wenn nein schicke es über die Leitung raus. Berechne einen neuen Mittelwert für bps/pps. Nachdem das Paket raus ist, Rücksprung zu 1. Falls kein Paket in Puffer prio1 war, oder ein Limit überschritten wurde, weiter mit 4.
4. Wenn im Puffer prio0 ein Paket ist, prüfe, ob ein Limit (bps/pps) überschritten wurde. Wenn nein schicke es über die Leitung raus. Berechne einen neuen Mittelwert für bps/pps. Nachdem das Paket raus ist, Rücksprung zu 1. Falls kein Paket in Puffer prio2 war, oder ein Limit überschritten wurde, weiter mit 1.

Daran kann man erkennen, dass, wenn ich Prio0 auf 40 % begrenze, wirklich max. 40 % der Bandbreite genutzt werden, selbst wenn 100 % frei sind. Während das bei für Prio 3 gut vertretbar ist, die Bandbreite zu begrenzen (z. B. 95 %, das tut nämlich nicht weh, wenn einem 5 % fehlen), ist es natürlich für Prio 0 unnötig, die Bandbreite zu begrenzen, denn die sind in Schritt 2 ja sowieso immer als letzte dran.

So, nach so viel Technikgeschwafel kommt noch meine persönliche Einschätzungen. Man sollte die verschiedenen Auswirkungen der Priorisierung und des Shapings verstehen um optimale Einstellungen zu finden. Man sollte den höheren Prioritäten keine 100 % geben, sondern weniger. TCP ACKs sind wichtig im UL, damit der DL fluppt. Gegebenenfalls allgemein kleine Pakete egal welcher Coleur vor großen Paketen bevorzugen, um die Latenz zu verringern.

Ich hoffe das hilft mehr als das es verwirrt.

Viele Grüße
Carsten

 

[Mister2]

Hallo,

danke für die Antwort und die Bestätigung meiner Annahmen.

Ich werde dann meine Box mal wie folgt einrichten und es damit testen:

limit_total = 100;
limit_p0 = 0
limit_p1 = 95
limit_p2 = 95
limit_p3 = 95

"fon-rtp" in "priority = 3"
"download-tcp-ack" in "priority = 3"
"dns" in "priority = 3"
"email" in "priority = 2"
"http-requests" in "priority = 2"
"default" in "priority = 1"
"filesharing" in "priority = 0"

 

[carstenlanger]

Shaping mit IP Source Filtern geht nicht so einfach!

Hallo,

jetzt habe ich auch auf meine FB das Shaping und Priorisieren ausprobiert. Ich stelle fest, dass man nicht bei den "out_rules" so einfach auf die IP Source Adresse, d. h. die von dem lokalen Netz für Uplink-Verkehr, filtern kann.

Mein Test:
Lokaler Rechner 10.0.0.2. Ziel: Verkehr von 10.0.0.2 mit TCP-Port 20 (FTP-DATA) auf Prio 0, Rest auf Prio 1. Dabei Begrenzung des Prio 1 Verkehrs auf 95 % der Bandbreite. Dann müsste ein FTP die volle Bandbreite bekommen, wenn kein weiterer Verkehr da ist, aber nur 5 % der Bandbreite, wenn weiterer Verkehr da ist.
ar7.cfg:

bps_limit {
                                        limit_total = 100;
                                        limit_p0 = 0;
                                        limit_p1 = 95;
                                        limit_p2 = 95;
                                        limit_p3 = 95;
                                }
out_rules 
...
                           {
                                name = "FTP test";
                                filter = "(ip host 10.0.0.2) and (tcp port 20)";
                                priority = 0;
                                limiters = "default-out";
                        } {
                                name = "default";
                                filter = "";
                                priority = 1;
                                limiters = "default-out";
                        }

Ergebnis:

Nix is, sobald die 2. Verbindung (rot) startet, teilen sich FTP (schwarz) und 2. Verbindung die UL-Bandbreite von 25.000 Byte/s mehr oder weniger gleichmäßig. Das heißt, dass beide in der gleichen Prio-Klasse gelandet sind.

Also 2. Test, diesmal ohne dem "ip host 10.0.0.2":
ar7.cfg:

bps_limit {
                                        limit_total = 100;
                                        limit_p0 = 0;
                                        limit_p1 = 95;
                                        limit_p2 = 95;
                                        limit_p3 = 95;
                                }
out_rules 
...
                           {
                                name = "FTP test";
                                filter = "(tcp port 20)";
                                priority = 0;
                                limiters = "default-out";
                        } {
                                name = "default";
                                filter = "";
                                priority = 1;
                                limiters = "default-out";
                        }

Ergebnis:

Ja hallo, so sollte es aussehen. Wenn nur der FTP läuft (schwarz), bekommt er alle Bandbreite. Wenn sonstiger Verkehr läuft (rot), hat der höhere Priorität und bekommt dann 95 % der Bandbreite. FTP bekommt den Rest.

Das kann aber nur heißen, dass der zu dem Zeitpunkt, wo der Filter "ip host 10.0.0.2" mit dem IP-Paket verglichen wird, das Paket schon gar nicht mehr die lokale 10.0.0.2 Adresse hat, sondern schon die externe IP Adresse der FB, d. h. schon durch die Network Address Translation (NAT) durch ist. Denn nur so lässt sich erklären, warum im 1. Test der FTP-Verkehr nicht in die Prio 0 Klasse einsortiert wurde.

Also ist filtern mit "ip host xxx" oder "ip host src xxx" oder so wohl nicht möglich. Es gibt aber den Eintrag

 demasquerade = no;

Vielleicht probiert mal jemand aus, ob das das macht, was ich vermute, nämlich das NATten für den Filter auszuschalten oder umzukehren oder so, jedenfalls mit "yes" könnte es vielleicht möglich sein, doch auf IP Adressen zu filtern.

Eure Kommentare?

Viele Grüße
Carsten

 

[Funktopus]

One question: what does udp[8] = 0x80 do? As far as I can tell, the filters seem to follow tcpdump (search for man tcpdump) syntax. So udp[8] is the 8th byte right after the start of the UDP header. So it is actually the very first byte of the UDP payload. But why is it matched to 0x80? Is it some kind of RTP indicator? Links?

Take a look at the RTP RFC, section 5.1 RTP Fixed Header Fields: The first 8 Bit (=1 Byte = 2 Hex values like 0x80) of an RTP-over-UDP packet comprise the version, padding, extension, and CSRC field. The value 0x80 equals RTP version 2 (the latest) with the other three fields being zero.

One may assume that no other protocol must be using such a "magic number" in its header. IMHO, even if this is true for the moment, the way of detecting RTP packets is still a bit hackerish since for example the padding field might be set in the future when encrypted RTP traffic becomes more popular or some mixer is used to aggregrate streams and thus a CSRC will be added (see the RFC and RTP-related RFCs for details).

For now, however, you may safely assume that (udp[8] = 0x80) works fine when trying to filter RTP traffic.

 

[Funktopus]

Ich hätte mal eine prinzipielle Frage in Bezug auf die Anpassung des Shapers, wie es hier diskutiert wird, und der gleichzeitigen Nutzung von VoIP und P2P: Wenn man schon mit der Default-Einstellung von AVM Aussetzer bei gleichzeitiger Nutzung von Internettelefonie und Fielsharing hat (wie ich auch), kann es denn mit irgendwelchen Anpassungen an der ar7.cfg überhaupt funktionieren?

Begründung: In den Standardeinstellungen erhält jeglicher VoIP-Verkehr bekanntlich 100% der Bandbreite und wird in die höchstpriore Klasse 3 einsortiert. Da kein anderer Verkehrstyp ebenfalls diese Klasse erhält, darf es eigentlich keine Konkurrenz geben und somit sind (heftige) Aussetzer kein Problem des Shaping, sondern der CPU-/Speicherlast der FBF.

Ich habe den Thread durchgelesen und war engagiert, selber bei meiner 7050 Hand anzulegen, aber sehe aus genanten Gründen schon prinzipiell keine Möglichkeit der Besserung. Vielleicht gibt es aber Leute, die (allein durch) Shaping von einem unbrauchbaren und einen brauchbaren Zustand übergehen konnten, und mir den (technischen) Grund dafür erklären können.

Würde mich daher freuen, wenn sich jemand hierzu äußern könnte.

 

[carstenlanger]

Hallo Funktopus,

was du da schreibst, hört sich logisch an. Es stimmt schon, dass in der Standardeinstellung VoIP absolute Priorität hat. Wenn es dann immer noch hakt, sollte es eigentlich durch andere QoS Einstellungen nicht besser werden können.

Ich selber habe keine Erfahrungen mit VoIP. Die von mir in diesem Forum beschriebenen QoS Einstellungen nutze ich, um tor Verkehr runterzuregeln. Und das klappt vorzüglich.

Aber nicht aufgeben: alleine schon das rumspielen macht doch Spaß!

Grüße
Carsten

 

[cream]

mit diesen einstellungen konnte ich während ftp upload und azureus aktivität zügig surfen und voip gespräche ohne großartige störungen führen:

 bps_limit {
                                        limit_total = 100;
                                        limit_p0 = 95;
                                        limit_p1 = 95;
                                        limit_p2 = 95;
                                        limit_p3 = 0;
                                }
[...]
 out_rules {
                                name = "fon-rtp";
                                filter = "ip[1] = 8 or udp[8] = 0x80 or udp port 5060";
                                priority = 3;
                                limiters = "default-out";
                        } {
                                name = "download-tcp-ack";
                                filter = "tcp and len <= 64";
                                priority = 3;
                                limiters = "default-out";
                        } {
                                name = "dns";
                                filter = "udp port 53";
                                priority = 3;
                                limiters = "default-out";
                        } {
                                name = "http-requests";
                                filter = "tcp[32:4] = 0x47455420 or tcp[32:4] = 0x50555420";
                                priority = 2;
                                limiters = "default-out";
                        } {
                                name = "email";
                                filter = "tcp and (port 110 or port 143 or port 993 or port 995)";
                                priority = 2;
                                limiters = "default-out";
                        } {
                                name = "pri-out";
                                filter = "icmp";
                                priority = 1;
                                limiters = "default-out";
                        } 
[...]

werde noch testen ob das setzen von p0 auf 80% zu einer noch besseren voip sprachqualität führt, da diese wärend der starken upload aktivität schon etwas eingeschränkter war als sonst.

 

[SophîaPêtríllo]

Hallo

Ich habe folgendes Problem:
Wenn bei uns ein Filesharing Programm läuft, dann funktioniert zwar das normale surfen noch relativ gut, aber sobald ich eine https Adresse aufrufe, also eine ssl verschlüsselte seite, dann baut sich diese sehr langsam bis garnicht auf.

Was müsste ich denn bei meiner FBF 7170 einstellen, damit diese Seiten vernünftig funktionieren?

mfg

 

[thorsee]

Hallo SophîaPêtríllo,

ergänze doch mal in den out_rules der ar7.cfg im Berich "http-requests" den Port 443

Gruß

thorsee

 

[Suppenman]

Hallo kann mir jemand helfen. Ich habe eine Fritz Box Fon.

Wenn ich einen Torrent mit 620 KB lade dann höre ich meinen Gesprächspartner über VoIP total abgehackt. Habe mir den Fritz Box editor runtergeladen.

Ich bin aber Neuling in der Materie und weiß nicht so recht wo ich was ändern muss damit es vernünftig läuft.

Habe die neuste Firmware drauf fritz.box_fon.06.04.15.image.

Bitte bitte hilft mir.

 

[shadow000]

Für Azureus gibt es hier irgendwo ein Plugin, das den Up- und Download runterfährt, während ein VoIP-Gespräch läuft.
Probier das mal!

 

[Suppenman]

Ja das habe ich schon gefunden Danke.

 

[Suppenman]

Also bei meiner 7050 und der alten FW die in Gelb gehalten war, hatte ich nie dieses Problem. Da lief Azureus immer im Hintergrund mit fast full Power. Nur nach dem Update ist das jetzt so bescheuert geworden.

Weißt du warum?

 

[Sp@ddel]

Hat schon jemand Rausgefunden wie man einen Port-Range dort einträgt?

mit

udp range 27000 27015 or tcp range 27015 27040

hat es bei mir nicht funktioniert.