Re: 2.6.14 - HTB/SFQ QoS broken?

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Also, when the problem is happening run this command:
tc -s class show dev ppp0
And email those results? With correct rates that don't add upto more than the parent, HTB should be working fine. Output of this command will show if the problem is with HTB, or instead how you're classifying packets.  Could very well be everything is going into the wrong subclasses.

- Jody

On 12/27/05, Andreas Klauer <Andreas.Klauer@xxxxxxxxxxxxxx> wrote:
On Tuesday 27 December 2005 21:51, Leo Bogert wrote:
> $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

So, the parent class offers $IFUP rate, but the children are trying to
use 8kbps+32kbps+$IFUP. It's hard to tell what HTB will do in this case.

> 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.

Yes, apache should be able to receive 32kbps, emule 8kbps, and everything
else the full bandwidth, all together at all times. But since there is not
that much bandwidth available (it's just $IFUP in total after all),
something has to give way.

> 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.

The way I understand HTB, your class structure is simply overallocated,
and the results you get from that are random at best. Before continuing,
you should make sure that the sum of children class rates is equal to
the parent class rate.

> 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.

Well, if even the author says so, you should heed his advice. :-)
Even if this is not the main problem in your case, keeping this
kind of HTB tree around won't make things better.

Could you post your reconfigured setup, possibly with proper class names
and rates instead of variables that could be anything?

Regards,
Andreas Klauer
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux