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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox