From: Catalin Bucur <cata@geniusnet.ro>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] HTB and theory
Date: Mon, 09 Dec 2002 20:27:40 +0000 [thread overview]
Message-ID: <marc-lartc-103946593306659@msgid-missing> (raw)
In-Reply-To: <marc-lartc-103945416224487@msgid-missing>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Stef Coene wrote:
| On Monday 09 December 2002 18:14, Catalin Bucur wrote:
|
|>Let's say that my ISP gives me 5000Kbit guaranteed bandwidth. I'm
|>starting a HTB traffic shape like this:
|>
|>tc qdisc add dev eth1 root handle 11: htb default 99
|>tc class add dev eth1 parent 11:0 classid 11:1 htb rate 10000Kbit burst
|>ceil 10000Kbit prio 0
|>tc class add dev eth1 parent 11:1 classid 11:2 htb rate 5000Kbit ceil
|>5000Kbit prio 5
|>[here I have a lot of sub-classes that borrow from parent 11:2]
|>
|>I'll let HTB to automatically compute the values for 'burst' and
|>'cburst'. The problem is elsewhere. What are the correct values for
|>'rate' and 'ceil' of 11:2 class in this case? In fact, total value of
|>'ceil's from all sub-classes exceeds 5000Kbit, so there are moments when
|>the bandwidth that comes from my ISP is bigger than guaranteed bandwidth.
|>Is there some kind a theory that says how to establish the values of
|>'rate's and 'ceil's from the parent and its sub-classes?
|
| There are some rules : ceil of child <= ceil of parent, sum (child
rates) <| rate of parent .... You don't have to follow this rules, but the final
| shaping result can be strange.
| See the faq page on www.docum.org.
|
I've already seen it :-) But it doesn't say anything like:
sum (child ceils) <= ceil of parent
Is there such a rule?
Am I forced somehow to limit 'rate' of class 11:2 under the guaranteed
value (5000Kbit), but let the 'ceil' equal to this value? It's better to
give the clients let's say 95% of guaranteed bandwidth instead of 100%?
- --
Catalin Bucur mailto:cata@geniusnet.ro
NOC @ Genius Network SRL - Galati - Romania
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE99Py7pDe20wwI9oIRAp09AJ9eaj7A/GoKOUmKTGp2j+MqZxAR3ACeIyiV
KxnF8AQ13K1fyM8eOaf5wfw=YVIk
-----END PGP SIGNATURE-----
_______________________________________________
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-09 20:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-09 17:14 [LARTC] HTB and theory Catalin Bucur
2002-12-09 18:22 ` Stef Coene
2002-12-09 20:27 ` Catalin Bucur [this message]
2002-12-09 21:22 ` Stef Coene
2002-12-09 21:45 ` Catalin Bucur
2002-12-09 22:18 ` Abraham van der Merwe
2002-12-10 12:33 ` Stef Coene
2002-12-10 12:40 ` Stef Coene
2002-12-10 13:28 ` Abraham van der Merwe
2002-12-10 21:23 ` Stef Coene
2002-12-12 8:36 ` Abraham van der Merwe
2002-12-12 10:49 ` Stef Coene
2002-12-12 11:19 ` Abraham van der Merwe
2002-12-12 18: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-103946593306659@msgid-missing \
--to=cata@geniusnet.ro \
--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.