QoS ervaringen

[TomVH]

Hallo,

Zijn er mensen die met succes (download) QoS gebruiken in hun router?

Het laatste jaar ben ik mij, dankzij dit forum, beginnen interesseren in netwerken en VoIP. VoIP gebruiken zonder QoS is geen goed idee. Tenzij je natuurlijk VoIP over Vlan (zoals bij belgacom) gebruikt.

Daarom heb ik mij een klein beetje verdiept in Traffic Control in Linux omdat standaard QoS in OpenWrt, dd-wrt niet deed wat ik wou. DD-wrt is niet configureerbaar genoeg. OpenWrt heeft wel een goed configureerbare QoS maar volgens mij zit er een grote fout in de berekening van de service curves. Bovendien is "overhead" calculation nergens standaard ingebakken. Niet in openwrt, niet in DD-wrt, niet in PFsense.

Mijn bedoeling is om http traffic (van de PC’s in huis) en VoIP (ATA en skype) voorang te geven op torrent en http download (vanaf de home server). Ik wil daarbij ook een goede latency/delay behouden voor VoIP. Hierbij wil ik ook rekening houden met de ATM , PPP, Ethernet,... overhead.

Mijn huidige lijnsnelheden zijn:
6140kbit download
640kbit upload

Geen VDLS of ADSL2+ ter beschikking en ik ben niet zo voor telenet. QoS met deze lijnsnelheden is dus een must.

1 QoS upload
QoS voor upload is geen probleem. Ik mag de lijn volledig verzadigen met een upload (vb dropbox), http en VoIP traffic krijgen voorrang. Download is echter iets moeilijker. PS: ECN mag niet geactiveerd zijn in de leaf qdiscs omdat ECN standaard niet geactiveerd is in windows of Linux.

De overhead van de pakketten wordt ingecalculeerd dankzij de TC stab option die mogelijk is vanaf de nieuwere iproute2 package die gebruikt wordt in de trunk image van OpenWrt


2 QoS download
2.1 Shapen van P2P
Ik heb ergens gelezen dat de nieuwe algoritmes gebruikt in de P2P applicaties de latency van de link proberen te beperken zodat andere applicaties (VoIP) geen hinder ondervinden. Het shapen van P2P met behoud van latency is dus eenvoudig door een leaf RED Qdisc te gebruiken met een “buffer” van 500 ms. Als je de maximale downloadsnelheid dan 20% lager insteld dan de lijnsnelheid, zal de queue van je router relatief snel "vullen". Zo zal de buffer aan ISP zijde nooit verzadigd geraken.

Na een test blijkt dit relatief goed te werken. De "round-trip time" (RTT) van de prioritaire pakketten (ICMP, VoIP) blijft beperkt en de P2P download zakt in snelheid als ik vb een youtube/vimeo video bekijk.

2.2 Shapen van http
http maakt gebruik van TCP. De hoeveelheid data verzonden van een internetserver (youtube, vimeo,…) naar mijn router (via de ISP) zal dus bepaald worden door het “congestion control” algoritme. Dit algoritme zal verschillen van server OS tot server OS. Een leaf qdisc met een grote buffer lijkt niet 100% te werken. Dit was ook wel te denken omdat TCP in mindere mate rekening houd met de RTT. Een maximale downloadsnelheid van 80% van de sync-speed van de lijn met een leaf Qdisc met een "buffer" van 100ms lijkt in mijn situatie een goede oplossing.
Hieronder de RTT van ICMP pakketten (naar 8.8.8.8 ) tijdens het verzadingen van de down en uplink met een torrent en vimeo http traffic.

• RTT van prioritaire ICMP pakketten =gemiddeld 50 à 75 ms met af en toe eens pieken van 150 à 200 ms.
• RTT van niet prioritaire ICMP pakketten = gemiddeld 150 ms met af en toe pieken tot 250 ms
• RTT van ICMP pakketten zonder QoS = 300 à 350 ms met af en toe time outs.

De RTT van ICMP pakketten zonder ander internet traffiek = 26 ms.

3 Besluit
Ik kan dus concluderen dat QoS zorgt voor een grote verbetering maar de RTT van prioritaire ICMP pakketten zou toch nog iets beter kunnen. Dit zou misschien mogelijk zijn door de parameters van de RED Qdisc te optimaliseren.

Zijn er mensen die betere waarden bereiken? Zoja, welke leaf qdic gebruikt hun router voor P2P en http download?

Je kan de configuratie van de qdiscs zien door het commande “tc qdisc show” in te typen

Hieronder een afbeelding van de qdisc hiërarchie die ik gebruik. Iptables gebruik ik om de pakketten een mark te geven en zo te "koppelen" aan een qdisc. Act_connmark wordt gebruikt om download traffic shaping mogelijk te maken waar vroeger IMQ gebruikt werd.
rt= real time service curve
ls= linkshare service curve
sc = service curve (rt en ls in 1 service curve)
ul = upperlimit service curve

PS: Je moet waarschijnlijk de afbeelding openen in een nieuw venster om ook de download hiërarchie te zien.

[remus]

Misschien ben je hier iets mee; een hele thread over QOS ivm met tomato firmware:
http://www.linksysinfo.org/index.php?th ... ion.28349/

Ik gebruik de toastman build, die komt met een default QOS config die ik lichtjes aangepast heb (ik heb geen VOIP)

# tc qdisc show
qdisc pfifo_fast 0: dev eth0 root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1
1
qdisc pfifo_fast 0: dev eth1 root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1
1
qdisc htb 1: dev ppp0 root r2q 10 default 90 direct_packets_stat 0
qdisc sfq 10: dev ppp0 parent 1:10 limit 127p quantum 1492b perturb 10sec
qdisc sfq 20: dev ppp0 parent 1:20 limit 127p quantum 1492b perturb 10sec
qdisc sfq 30: dev ppp0 parent 1:30 limit 127p quantum 1492b perturb 10sec
qdisc sfq 40: dev ppp0 parent 1:40 limit 127p quantum 1492b perturb 10sec
qdisc sfq 50: dev ppp0 parent 1:50 limit 127p quantum 1492b perturb 10sec
qdisc sfq 60: dev ppp0 parent 1:60 limit 127p quantum 1492b perturb 10sec
qdisc sfq 70: dev ppp0 parent 1:70 limit 127p quantum 1492b perturb 10sec
qdisc sfq 80: dev ppp0 parent 1:80 limit 127p quantum 1492b perturb 10sec
qdisc sfq 90: dev ppp0 parent 1:90 limit 127p quantum 1492b perturb 10sec
qdisc ingress ffff: dev ppp0 parent ffff:fff1 ----------------

[TomVH]

Misschien ben je hier iets mee; een hele thread over QOS ivm met tomato firmware:
http://www.linksysinfo.org/index.php?th ... ion.28349/

Ik had het QoS topic van Tomato een jaar geleden al eens grondig doorgelezen. Nu heb ik de eerste pagina nog eens grondig doorgelezen. Toch enkele opmerkingen i.v.m. Tomato QoS.

• Geen HFSC
• Geen ATM, PPP,... overhead calculation
• Geen RED
• ik heb ook mijn twijfels over de manier waar tomato downloads wil beperken.
• Er wordt gesproken voor TCP vegas als congestion control algorithm. TCP vegas is end to end congestion control. Heeft dus niets te maken met de router. Enkel applicaties die op de router draaien (vb een torrent client) zullen gebruik kunnen maken van TCP vegas.

Uit jouw output van "tc qdisc show" blijkt ook dat ze downloads niet beperken door gebruik te maken van HTB of HFSC. Dit doen ze wel voor upload QOS door middel van HTB.

Kan iemand de output van "tc qdisc show" van een fritzbox eens posten aub? Deze zijn ook linux zeker? Ben eens benieuwd wat in de fritzboxen gebruikt wordt om QoS mogelijk te maken.

[Kenw00t]

Alstublieft

Code: Selecteer alles

# tc qdisc show
qdisc pfifo_fast 0: dev cpmac0 root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth0 root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc tbf 2: dev vdsl root rate 2035Kbit burst 6578b lat 10.3ms
qdisc llq 10: dev vdsl parent 2: minq 1 maxq 255 default 6
qdisc sfq 104: dev vdsl parent 10:4 limit 32p quantum 100b perturb 10sec
qdisc sfq 105: dev vdsl parent 10:5 limit 32p quantum 100b perturb 10sec
qdisc sfq 106: dev vdsl parent 10:6 limit 32p quantum 100b perturb 10sec
qdisc sfq 107: dev vdsl parent 10:7 limit 32p quantum 100b perturb 10sec
qdisc pfifo_fast 0: dev dsl root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev wifi1 root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev ath0 root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

[TomVH]

bedankt!!

Ook geen download QoS in de fritz. Zelf de upload QoS is maar magertjes vind ik.

Ik zal de ontwikkelaar van het QoS script in OpenWrt eens proberen contacteren (eventueel via een ticket) en vragen om volgende zaken aan te passen:

• Overhead calculation met TC stab option
• configureerbare leaf qdiscs
• juiste(re) berekening van de service curves.

Veel werk kan het niet zijn voor iemand die het script volledig begrijpt. Ikzelf heb daar de capaciteiten niet voor.

andere ervaringen met QoS zijn welkom!