Re: [LARTC] How HTB treats priorities?

["ISC Robert Kryczało" <robert.kryczalo@iscnet.pl>]

Hello,
>>   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 ?
No, 8 kilobits or 1kilobyte per second. The reason for this is that I
want to have around 40-50 customer classes inside A. With guaranteed rate
of 8kbit/s and ceiling of 128kbit/sek. The statistics data I have gathered
leads me to a conclusion that one of every three users utilizes 33% of his
bandwidth (33% of 128kbit/s), two others are idle. In pratice we
can have 80-100 customers per 1Mbit and it works well if no p2p software
(like Kazaa is involved). This is why I want to switch to htb and its
ceiling feature.

Customers pay relatively low rates and thanks to current cbq  setup
receive relatively good service. Anyway, we have customers using
128/128(rate/ceiling) which pay 8 times more.

>>      A
>>    /   \
>>   B     C
>>  /|\   /|\
>> D E F G H I
>>
>> D,G rate=4/ceild
>> E,H rate=3/ceil\x128
>> F,I rate=1/ceil2
>>
>> 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 understand but... I still want to limit customer B to 128 kbit/s. And
guarantee them 8kbit/s.

>
>> 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.
Let's say I give D bandwidth of 32 kbit/s, E bandwidth od 64 kbit/s and F
bandwidth 32 kbit/s. When every classes are idle ond only E attempte to
transmit at maximum speed, it will be given 64kbit/sek not 128kbit/s:(.
Customers will not be happy, because in current setup they can reach
128kbit/s (and thanks to cbq inaccuracies even more - around 155kbit/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 have read it. In simple cases I totaly agree. But there must be
something missing (or I am totally wrong:) ). Or the setup I require is
not possible to create.

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

I think exactly the way you described. I see rate the same way you do.
Unfotunetaly this leads me to a conclusion that htb has serious drawbacks.
If the ceiling of the parent is not respected then it is impossible to
create setup I require. In this case it is also not necesary to create
parent classes.

I hardly belive that. I must omit something important. There follows
interesting quote from
http://luxik.cdi.cz/~devik/qos/htb/old/develnotes.htm

"Lower levels are completely dequeueued before borrowing from higher
levels.". So is it possible that prio and rate and ceiling of parent class
matters?

And teator of htb qdisc often uses term of borrowing bandwidth from
parent......

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

Yes, I will try to do some research on my own, too. Anyway, I would like
to read your opinions Stef about my doubts. I think this thread can be
useful to many people.

Robert Krycza³o



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