[LARTC] 2.6.14 - HTB/SFQ QoS broken?

[Leo Bogert]

Hello,

First of all, I already contacted Martin Devera, the developer of HTB, and
he told me to search for help on this mailinglist, thus I am describing
my problems here now...

I am kind of seriously annoyed by QoS as I have been trying for over 3 years
to get it working properly - first I did not understand how it works, then 
it seemed not to work, then it was working perfectly for half a year,
or at least it seemed to do so, and now it seems to be broken.

I have read so many QoS HOWTOs and I'm quite sure that I have understood the

default approach for upstream bandwidth limiting/prioritizing - it is always

the same in these HOWTOs:

A root HTB qdisc is added to the network interface.
This HTB receives a child class HTB to allow bandwidth sharing between the 
different classes (for example peer2peer, ftp, etc.).
The actual HTB leaf classes are then attached to this class.
These leaf classes finally each receive a SFQ which serves the purpose
of fair queueing AND giving a package queue to HTB so that it does not 
have to drop packets.

Here is my implementation of it:

IFUP=48kbps
tc qdisc add ppp0 root handle 1:0 htb default 20 r2q 4
$addclass 1:0 classid $cMAIN htb rate $IFUP mtu 1492

$addclass parent $cMAIN classid $cEMULE    htb rate 8kbps  ceil $IFUP prio 4
$addclass parent $cMAIN classid $cAPACHE   htb rate 32kbps ceil $IFUP prio 2
$addclass parent $cMAIN classid $cDEFAULT  htb rate $IFUP  burst 6k prio 1

$addqdisc parent $cEMULE   handle 10: sfq perturb 10
$addqdisc parent $cAPACHE  handle 20: sfq perturb 10
$addqdisc parent $cDEFAULT handle 30: sfq perturb 10

As you can see, eMule can use all bandwidth as long as nobody is requesting 
something from the webserver. If somebody is downloading from the server, he

should receive 32kbps and eMule should be slowed down.
Normal traffic (browser requests, multiplayer gaming, etc.) should receive 
all bandwidth if necessary, and have the highest priority, thus allowing 
good ping times.

Well, I have written that script about half a year ago, and back then it
was working well, and I even installed a linux router for someone and there
it is still working.

BUT now I have checked the speed of my webserver, and when eMule is running 
it is only at 4 kb/s instead of 32 kb/s.

AND I have found the reason for this: If I remove the SFQs, scheduling 
seems to work - at least at the "bad precision" of HTB: Apache receives over

20 kb/s and eMule is limited to 12 kb/s instead of 8.

Now what exactly is the reason for this? I thought it was absolutely normal 
to have these SFQ queues? Removing them is no solution because HTB 
starts dropping packets then.

Martin Devera told me that it is wrong that the sum of the child-HTB's
rates is larger than my interface speed. Well, I reconfigured to have 
the sum equal the available bandwidth and even then QoS did not work.

And finally the most weird fact: On the other box where I have installed
my QoS script it is still working properly. When Apache is uploading,
eMule is slowed down to 4kb/s. So I copied the script back to my box
and there it does not work!?
I did not change the configuration of my linux router very much,
I only usually update all packages with aptitude and install the
latest kernel myself.

Feel free to ask many questions, and thanks for your help,
Leo Bogert