From: Stef Coene <stef.coene@docum.org>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] How HTB treats priorities?
Date: Sun, 29 Dec 2002 23:23:13 +0000 [thread overview]
Message-ID: <marc-lartc-104120428116624@msgid-missing> (raw)
In-Reply-To: <marc-lartc-104110872106366@msgid-missing>
> >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.
> >Class A has available bandwidth. Rules for guaranteed rates for classes
> >D,E,F,G,H,I are fulfilled. So available bandwidth has to
> >be distributed between class B and C equaly (assuming B and C has the same
> >rate and prio). Is remaining bandwidth distributed to classes D and G, and
> >then to classes E and H and at the end to classes F and I???
Yes.
> 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.
> 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.
> >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.
> >What happens when sum of guaranteed rates of children class is bigger than
> >guaranteed rate of parent (rate parameter is overbooked) and all of
> >classes are requesting maximum bandwidth? Are classes with lower prio
> >given bandwidth first?
>
> There are rules that you should respect when creating classes.
> Check the FAQ on the HTB home site.
And I have some more on the faq page on www.docum.org
> >Are packets classfied to class D and G sent first?
>
> No, unless classes D and G haven't reached their guaranteed minimum
> rate.
>
> >What will happen if prio of class B is 0 and class C is 3? I assume
> >remaining bandwidth is first distributed to class B and to its children.
> >Right???
>
> Same answer regarding parent HTB classes. I'm not sure.
All remaining bandwidth goes to B.
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/
next prev parent reply other threads:[~2002-12-29 23:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-28 20:53 [LARTC] How HTB treats priorities? ISC Robert Kryczało
2002-12-29 5:01 ` Stephane Ouellette
2002-12-29 23:23 ` Stef Coene [this message]
2002-12-30 22:35 ` ISC Robert Kryczało
2002-12-30 23:37 ` Stef Coene
2003-01-02 16:26 ` Homer Parker
2003-01-02 17:56 ` ISC Robert Kryczało
2003-01-02 18:03 ` ISC Robert Kryczało
2003-01-02 21:57 ` Stef Coene
2003-01-04 20:21 ` ISC Robert Kryczało
2003-01-05 17:42 ` Stef Coene
2003-01-06 18:54 ` ISC Robert Kryczało
2003-01-06 19:32 ` Stef Coene
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-lartc-104120428116624@msgid-missing \
--to=stef.coene@docum.org \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.