On Sun, 2006-03-05 at 10:16 +0100, Andreas Klauer wrote:
> >
> > htb class parent 1: classid 1:10 rate 80% ceil 100%
>
> To my understanding, a root class that has a higher ceil than rate
> can always use bandwidth up to it's ceil. Thus it would be more
> correct to set the rate to 100% here (whatever that is) as well.
I can verify it doesn't. I have implemented this in real
life, and the class is limited to the "rate".
> > htb class parent 1:10 classid 1:11 rate 30% ceil 100%
> > htb class parent 1:11 classid 1:19 rate 30% ceil 100% prio 0 [VOIP leaf]
>
> If class 1:19 is the only child of class 1:11, it can always use
> whatever bandwidth the parent class can get. So the parent class
> does not have any limiting factor here and you can just skip it
> and attach 1:19 to 1:10 directly.
It looks like you are right, although perhaps not for the
reasons you think. The structure was intended to prevent
a priority inversion that occurs in HTB when you use deep
trees. Lets say we have this example:
root 1:10
--------- 1:30 prio 0
/ \ 1:31 prio 1
1:30 1:21 1:32 prio 2
/ \
1:31 1:32
Lets assume 1:30 and 1:32 are over limit. 1:31 is not
sending anything, and thus 1:21 is under limit. What
I wanted to happen is 1:30 and 1:32 are serviced based
on their priority - ie 1:30 sees a lower latency as it
has the lowest priority. But that won't happen in this
case.
Looking at:
http://luxik.cdi.cz/~devik/qos/htb/manual/theory.htm
You see that since 1:30 is over limit, its request for
bandwidth will get forwarded to 1:10. 1:32 request
for bandwidth will get forwarded to 1:21. Regardless
of priority, HTB always services the lowest node in
the tree (as measured as the distance to the furtherest
leaf) first. Priority is only considered when that
distance is the same for the competing nodes. Since
1:21 is lower in the tree than 1:10, it will get
serviced first, regardless of the fact that 1:30's
packets have a high priority. Thus the "priority
inversion".
By restructuring the tree like this:
root 1:10
--------- 1:30 prio 0
/ \ 1:31 prio 1
1:20 1:21 1:32 prio 2
/ / \
1:30 1:31 1:32
I had hoped to fix the problem by ensuring that 1:30
and 1:32 ancestors are at the same height in the tree.
It didn't work because I made the rate for 1:20 wrong.
It should of been 100%. With that fix the priority
inversion should go away.
The revised class structure is now:
htb class parent 1: classid 1:10 rate 80% ceil 100%
htb class parent 1:10 classid 1:11 rate 100% ceil 100%
htb class parent 1:11 classid 1:19 rate 30% ceil 100% prio 0 [VOIP leaf]
htb class parent 1:10 classid 1:20 rate 70% ceil 100%
htb class parent 1:20 classid 1:21 rate 20% ceil 100% prio 1 [interactive leaf]
htb class parent 1:20 classid 1:22 rate 50% ceil 100% prio 2 [other leaf]
> > htb class parent 1:10 classid 1:20 rate 70% ceil 80%
> > htb class parent 1:20 classid 1:21 rate 20% ceil 80% prio 1 [interactive leaf]
> > htb class parent 1:20 classid 1:22 rate 50% ceil 80% prio 2 [other leaf]
> >
> > This is the small class tree I can think of that does it.
>
> The only difference to the tree before is that you grouped all non-voip
> traffic under a separate parent class which is capped at 80%, so voip
> always has 20% of available bandwidth which can not be taken away from
> it, right? If that was your intention, then it's fine.
Yes, that was my intention. As an example, if 1:22 (other)
in the above hierarchy was wanting to use say 120%, and
1:19 (VOIP) was wanting to use 10%, then HTB would allocate
the available bandwidth as follows:
1:19 (VOIP) - 10%
1:22 (other) - 70%
It may be the "only difference", but it is subtle, and it
surprised me to see that HTB could reserve bandwidth like
this. It is a very flexible qdisc.
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
