All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephane Ouellette <ouellettes@videotron.ca>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] How HTB treats priorities?
Date: Sun, 29 Dec 2002 05:01:39 +0000	[thread overview]
Message-ID: <marc-lartc-104113819318653@msgid-missing> (raw)
In-Reply-To: <marc-lartc-104110872106366@msgid-missing>

ISC Robert Krycza³o wrote:

>Hello,
>I have a question regarding htb and priorities.
>
>I want to limit my customers to some rate (let's say 512kbit/sek) and to
>guarantee them for example 64kbit/sek on my links to the internet. I want
>to divide it further in order to decrease latency, speed up interactive
>activities, but allow them to do bulk downloads. I created htb tree
>looking like that. B and C are customers. Customer classes are divided
>into low latency class(DNS, small SSH and telnet packets, fast FPP games),
>http traffic class and other traffic class.
>
>Situation looks like this: (in reality we have several uplinks and also
>customer sites are connected by backbone, which also have limited
>bandwidth capacity - tree is simplified)
>
>       A
>     /   \
>    B     C
>   /|\   /|\
>  D E F G H I
>
>Class B and C have prio=3,
>D and G have prio=1 (rate and ceiling are the same)
>E and H have prio=2 (rate and ceiling are the same)
>F and I have prio=3 (rate and ceiling are the same)
>
>I have following questions:
>
>Remaining bandwidth inside class B is distributed first to class D, then E
>and then F and is limited by ceiling parameter . Right???
>
Hi Robert,

      yes, what you have said is right.

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

  If what I have written is true, there is a possibility that bandwidth 
is not distributed equally between classes B and C.

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

> And when packets are send?
>  
>

   It has nothing to do with the prio parameter.

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

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

>Thx in advance for your answers
>
>Robert Kryczalo
>
>
>
>_______________________________________________
>LARTC mailing list / LARTC@mailman.ds9a.nl
>http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>
>  
>



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

  reply	other threads:[~2002-12-29  5:01 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 [this message]
2002-12-29 23:23 ` Stef Coene
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-104113819318653@msgid-missing \
    --to=ouellettes@videotron.ca \
    --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.