Re: [LARTC] How HTB treats priorities?

[Stef Coene <stef.coene@docum.org>]

On Monday 30 December 2002 23:35, ISC Robert Krycza³o wrote:
> Hello,
>
> Thank you for your replies. Let me summarize your opinions....
>
> Let's assume I have 512 kbit/s synchronous link to my upstream provider.
> I have two customers named "B" and "C". I want to be sure that they get at
> last 8kbit/s. I want to limit maximum traffic generated per each customer
> to 128 kbit/s.
>
> A tree that follows describes what I did.
>
>   A
>  / \
> B   C
>
>  Class A rate and ceiling is set to something like 490kbit/sek (or lower)
> to move queues to my linux traffic shaper. I set equal prios, rate for B
> and C equals 8 kbit/s, ceiling for B and C equals 128 kbit/s. This setup
> is supposed to fulfill my needs. It should work as expected, right?
No.  Why don't you take rate = ceil = 128kbit/s ??  If A uses all it can, 128, 
there is still 512-128 left for the other as his mimum bandwidth.  Or do you 
want so say 8kilobyte ?

> Now I try to improve my setup. What I require is to divide customer B and
> C traffic into 3 classes - interactive(D,G) , www (E,H) and other
> (F,I)respectively. I dont want to allow customer B or C traffic to go over
> 128kbit/s.I expanded last tree and created following tree.
>      A
>    /   \
>   B     C
>  /|\   /|\
> D E F G H I
>
> D,G rate=4/ceil=64
> E,H rate=3/ceil=128
> F,I rate=1/ceil=32
>
> Priorities for all classes are the same.
>
> Lets assume all classes try to send at their maximum speed trying to
> saturate the link. According to what you have written class D will get
> 64kbit/s, class E 128kbit/s and class F will get 32kbit/s. The sum is
> 224kbit/s if I am correct. Am I right?
Yes.  So the rate of the parent B must also be at least 224kbit/s.  And not 
8kbis/s like you wrote before.

> I dont want it to happen since customers have paid for 128kbit/s with
> guaranteed rato of 8kbit/s. Is there a way to acomplish my task???. Can it
> be done using HTB only?
Yes, make the sum of D,E and F = 128kbit/s.

> >> >Remaining bandwidth inside class B is distributed first to class D,
> >>
> >> then E and then F and is limited by ceiling parameter . Right???
> >>       yes, what you have said is right.
> >
> > Confirmed.  Lowest prio classes are allowed to send first.
>
> It is intuitive. Thanks for confirmation. Anyway, classes D,E,F are
> limited only by their ceil, not by ceil of class B. Hm?. Performance
> reasons, right?
I have some rules on the faq page on www.docum.org regarding the rate and ceil 
of parent and child classes.  If you follow these rules, it will be easier to 
understand how each class will behave.

> >>   I remember having read something about the "rate" parameter of a
> >> parent HTB class.  I think it was that the "rate" parameter isn't
> >> used, only the "ceil" parameter (of a parent HTB class) is important.
> >> Check the list archive and the HTB home page because I'm not sure.
> >
> > Nor the rate, nor the ceil are respected if the child class can send.
> > So if B  end C can send the remaining bandwidth, they will.  Even if the
> > parent ceil  is not permitting it.
>
> Well... I hoped for opposite. If the ceiling of parent class is not
> respected, then setting htb up the way I require is rather impossible.?
> Right:( ?
No.  You have to see the rate as a minimum bandwidth and also like a 
"proportion".  I mean if you have a class with child rate = 10 and an other 
child class with rate = 30, the first class will get 25% of the bandwidth.  
So the real value of rate doesn't mather.

> >>   If what I have written is true, there is a possibility that
> >> bandwidth
> >> is not distributed equally between classes B and C.
> >
> > Indeed.  This can be true IF class B and C have different rates.  But I
> > did  some tests and it seems to be that remaining bandwidth is splitted
> > 50-50 and  according to the rates.  Strange.  I will test it further
> > tomorrow.  But the  prio of the parent is respected.  So the parent with
> > the lowest prio get all  remaining bandwidth.
>
> I would like to see the results, if you were so kind...
I didn't had the time to write it down, but it seems to me that each parent 
class can use it's rate like it should be, but the remaining bandwidth is 
splitted 50-50 and according to the quantums.

> >> >What if C and B have different rates?
> >> >Is prio parameter taken into account when htb tries to meet
> >> guaranteed rate rules?
> >>
> >>    I think the "prio" parameter is only used after all classes have
> >> reached their guaranteed minimum rate, to allow the user to create
> >> classes that will borrow bandwidth over other classes.
> >
> > Yep.
>
> OK. You have cleared thing up:)
I think there is a page on the htb homepage that state that only prio of leaf 
classes are used.  In fact if you have a htb setup, and you asks the setup, 
the prio of non-leaf classes isn't even shown.  On the other hand, I did some 
small tests and the prio parameter seems to be important.  I really have to 
do some tests .....

> This FAQ is a nice piece of work Stef:) Well done:)
It's a nice of work that needs a rewrite :)
Its more a bunch of questions and answers :)

> It goes to B and then to its children, right? I mean, there are no
> classifiers (filters) pointing to class B directly, only to its children.
The filters doesn't mather.  As long as the packets end in a leaf class.

Stef

-- 

stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.oftc.net

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/