All of lore.kernel.org
 help / color / mirror / Atom feed
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/

  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.