5

I'm currently studying the opportunity of using an Ubuntu server to provide QoS instead of my consumer-class router. I've read a lot of resources about tc and HTB queuing disciplines - which look to be the one I need for my QoS needs, and even if it mostly seems clear now, there is still something that bugs me with subclasses rate.

Let's take a look at this sample configuration found as an answer to this question :

tc class add dev eth0 parent 1: classid 1:1 htb rate 90kbps ceil 90kbps
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 30kbps ceil 60kbps
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 30kbps ceil 60kbps
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 30kbps ceil 60kbps

This is very straightforward when you know how tc works : the three subclasses are all guaranteed a bandwidth of 30kbps but are allowed to borrow 30 more kbps of available bandwidth from their parent class (30 + 30 = 60kbps ceil).

This example makes sense to me. The total bandwidth of the parent class is 90kbps, and each of the three subclasses are guaranteed 30kbps - 3 x 30kbps = 90kbps.

Now, let's take a look at this other example from this tutorial :

# tc class add dev eth0 parent 1: classid 1:1 htb rate 6mbit burst 15k
# tc class add dev eth0 parent 1:1 classid 1:10 htb rate 5mbit burst 15k
# tc class add dev eth0 parent 1:1 classid 1:20 htb rate 3mbit ceil 6mbit burst 15k
# tc class add dev eth0 parent 1:1 classid 1:30 htb rate 1kbit ceil 6mbit burst 15k

That's where things are getting confusing to me. The first subclass is guaranteed a bandwidth of 5mbit while the second one is guaranteed of bandwidth of 3mbit. But the parent class only have a bandwidth of 6mbit !

What is the purpose of such a rule ? None of the subclasses will ever be able to obtain its guaranteed bandwidth.

Even more confusing is the conclusion of the tutorial :

HTB certainly looks wonderful – if 10: and 20: both have their guaranteed bandwidth, and more is left to divide, they borrow in a 5:3 ratio, just as you would expect.

How could both classes have their guaranteed bandwidth and their parent still have bandwidth to borrow ?

Without a doubt, there is something that I'm missing here. It could be the tutorial that is flawed, but I found a lot of other samples with the same kind of confusing setup - here for instance :

/sbin/tc class add dev eth3 parent 1: classid 1:1 htb rate 2000kbit
/sbin/tc class add dev eth3 parent 1:1 classid 1:10 htb prio 1 rate 1500kbit ceil 1950kbit
/sbin/tc class add dev eth3 parent 1:1 classid 1:20 htb prio 2 rate 500kbit ceil 1600kbit

With this configuration, in which case could the 1:20 class be able to borrow bandwidth to the parent class (it is allowed to borrow up to 1600kbit) since the guaranteed bandwidth of its sibling is 1500kbit - and 1500kbit of its sibling plus 500kbit of its own guaranteed bandwidth already match the parent 2000kbit bandwidth.

Can anyone clarify the situation ?

Community
  • 1
Eric MORAND
  • 293
  • 2
  • 8

1 Answers1

1

You did understand how htb works.
Although, you need to look closer your examples: both parent class have no ceil option, and will then use more bandwidth if available. If in the last example, the parent class had rate 2000kbit ceil 2000kbit, the child class wouldn't be able to borrow that much bandwidth.

However, I do agree that in the 5+3Mbit example, both class won't have the guaranteed bandwidth if the bandwidth is greater than 6Mbit.
This one is probably a mistake.

setenforce 1
  • 928
  • 5
  • 7