[LARTC] 2.6.14 - HTB/SFQ QoS broken?

Jody Shumaker jody.shumaker at gmail.com
Wed Dec 28 02:05:32 CET 2005


> When configuring this, I thought the priorities would make that work.
> They even DID that because it was working once.
> The whole point why I configured it like that:
> I (and everyone else probably) want the scheduler to be like:
> "Give all bandwidth to eMule if nothing else is running.
> If miranda filetransfer is running give all bandwidth to it
> UNLESS Apache is running, then Apache should receive all bandwidth."
> This is not possible if the bandwidth reservations dont overlap, is it?
> Or can anyone tell me a different qdisc / solution which allows this?


It's undefined what happens when you overallocate, and is certainly not
required to do what you want. 'rate' is guarenteed rate, 'ceil' is maximum
bandwidth useable through borrowing, and 'prio' is priority this class gets
when borrowing bandwidth.  You should give emule next to nothing for
guarenteed, but with a ceil either the max bandwidth or very close.  It is
then guarenteed little, but will borrow up to its ceil. Then guarentee
apache most, with some left for default.  the prio will mean apache has
first access to any borrowable bandwidth, then default, then emule. I would
use something like this:

IFUP=48

$addc $cMAIN classid $cEMULE    htb rate 4kbps  ceil ${IFUP}kbps $q1 prio 5
$addc $cMAIN classid $cMIRANDA  htb rate 30kbps ceil ${IFUP}kbps $q2 prio 2
$addc $cMAIN classid $cDEFAULT  htb rate $[$IFUP - 30 - 4]kbps burst 6k $q2
prio 1


I'm using something fairly similar:

#root
tc qdisc add dev $DEV root handle 1: htb default 122

#main rate limiter
tc class add dev $DEV parent 1:0 classid 1:1 htb burst 30k rate
${UPLINK}kbit ceil ${UPLINK}kbit

#high priority low bandwidth traffic (75% bandwidth guarentee)
tc class add dev $DEV parent 1:1 classid 1:11 htb burst 30k prio 0 rate
$[($UPLINK - 4) * 3 / 4]kbit ceil ${UPLINK}kbit cburst 4k
#most traffic (25% bandwidth guarentee)
tc class add dev $DEV parent 1:1 classid 1:12 htb burst 30k prio 1 rate
$[($UPLINK - 4)  / 4]kbit ceil $[$UPLINK - 16]kbit
#no priority traffic (4kbit guarentee, ceil torrentpercent)
tc class add dev $DEV parent 1:1 classid 1:13 htb prio 7 rate 4kbit ceil
$[($UPLINK - 4) * $torrentpercent / 100]kbit

#further split most traffic into game, and non-game
#games
tc class add dev $DEV parent 1:12 classid 1:121 htb burst 30k prio 1 rate
$[(($UPLINK - 4) / 4) - 4]kbit ceil $[$UPLINK - 4]kbit
#non-games
tc class add dev $DEV parent 1:12 classid 1:122 htb burst 15k prio 6 rate
4kbit ceil $[$UPLINK - 4]kbit

#
tc qdisc add dev $DEV parent 1:11 handle 11: sfq perturb 10
tc qdisc add dev $DEV parent 1:121 handle 121: sfq perturb 10
tc qdisc add dev $DEV parent 1:122 handle 122: sfq perturb 10
tc qdisc add dev $DEV parent 1:13 handle 13: sfq perturb 10

Few things i remember tweaking is increasing the burst for the higher
priority classes.  I found they were quicker to take over bandwidh and hold
it that way.

Could you possibly check emule off, and file transfer going? With my setup
often even if I kill bittorrent downloads,  other file transfers don't go
any faster.  They're not using up the full pipe because of the full route to
the other person, nothing to do with p2p getting in the way.
http://webpages.charter.net/falconx/ppp0-8-tc-cumulative.png
My irc sends varied very little when a bittorrent download started, and then
when an ftp transfer started with someone who can use most of my bandwidth
you can see around 17:30 the blue spiked to using nearly all the bandwidth.

- Jody
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ds9a.nl/pipermail/lartc/attachments/20051227/54e5b8eb/attachment.htm


More information about the LARTC mailing list