On Monday 30 December 2002 23:35, ISC Robert Krycza=B3o 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=
=2E
> 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 custom=
er
> 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 lowe=
r)
> 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 setu=
p
> is supposed to fulfill my needs. It should work as expected, right?
No. Why don't you take rate =3D ceil =3D 128kbit/s ?? If A uses all it =
can, 128,=20
there is still 512-128 left for the other as his mimum bandwidth. Or do =
you=20
want so say 8kilobyte ?
> Now I try to improve my setup. What I require is to divide customer B a=
nd
> 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 o=
ver
> 128kbit/s.I expanded last tree and created following tree.
> A
> / \
> B C
> /|\ /|\
> D E F G H I
>
> D,G rate=3D4/ceil=3D64
> E,H rate=3D3/ceil=3D128
> F,I rate=3D1/ceil=3D32
>
> 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 n=
ot=20
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 =3D 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=20
of parent and child classes. If you follow these rules, it will be easie=
r to=20
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=
=2E
> >> 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=20
"proportion". I mean if you have a class with child rate =3D 10 and an o=
ther=20
child class with rate =3D 30, the first class will get 25% of the bandwid=
th. =20
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 splitt=
ed
> > 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 w=
ith
> > 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 pare=
nt=20
class can use it's rate like it should be, but the remaining bandwidth is=
=20
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=20
classes are used. In fact if you have a htb setup, and you asks the setu=
p,=20
the prio of non-leaf classes isn't even shown. On the other hand, I did =
some=20
small tests and the prio parameter seems to be important. I really have =
to=20
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 childre=
n.
The filters doesn't mather. As long as the packets end in a leaf class.
Stef
--=20
stef.coene@docum.org
"Using Linux as bandwidth manager"
http://www.docum.org/
#lartc @ irc.oftc.net
