From: "Martin A. Brown" <mabrown-lartc@securepipe.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Problem while using HTB bandwidth limitation
Date: Tue, 02 Sep 2003 04:46:26 +0000 [thread overview]
Message-ID: <marc-lartc-106247814314243@msgid-missing> (raw)
In-Reply-To: <marc-lartc-106242135331948@msgid-missing>
Hi there Nimit,
: >>Can there be any problem if I set 10 classes each restricted to 24kbit
: >>under a class which has been restricted to 128Kbit.
: >>
: >>My point is what happens if total of child classes, is more than the
: >>parent class itself. Does it distribute fairly ie equally to all 10
: >>classes or will there be a problem.
: >
: > Each class should be able to het 1/10 of 128kbit. But it can be bursty.
:
: It can burst to some extent but I could see the rate going more than
: double in some cases why is it so?
In HTB, all shaping happens in the leaf classes. For ease on the CPU (and
apparently, the difficulty of the algorithm), HTB is designed to believe
you when you say that each of your 10 leaf classes should get 24kbit, and
it does not check the parent class to make sure the parent class is
throttling all of the children.
You had used a 24kbit rate and no specified ceiling on each of these 10
classes. This means that you have the equivalent of 24kbit rate and
24kbit ceil. You are guaranteeing 24kbit at all times to every class!
You might end up sending up to 240kbit (not accounting for your burst
setting either).
In order to approach better your 192kbit line with 10 classes, I would
recommend trying a configuration more like this. Use a rate 16kbit and
ceil 24kbit for each of your classes. This means that a leaf class will
consult the parent class for leftover bandwidth above 16kbit. And above
24kbit, it will cease asking the parent to borrow bandwidth.
This means that all of your classes would send a maximum of 160kbit of
guaranteed traffic before consulting the parent class which has a
bandwidth to divide amongst the children.
: Yes, now I have removed the burst parameter but can you explain me why
: to limit all bandwidth to 188 when I have 192, I am having DSL
: connection.
It is immaterial what sort of connection (speed) you have. The key (and
secret) is that you must be the bottleneck. In order for you to control
latency and bandwidth use, you must ensure that you are the slowest point.
Annoyingly, the only successful way to identify exactly what speed to use
as a bandwidth cap is experimentation. A good general suggestion is to
lop off a couple of kbit and try capping your bandwidth exactly as Stef
suggests. Try using 188kbit, and see if your apparent control increases.
Best of luck,
-Martin
--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
next prev parent reply other threads:[~2003-09-02 4:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-01 13:14 [LARTC] Problem while using HTB bandwidth limitation Nimit Gupta
2003-09-01 17:41 ` Stef Coene
2003-09-02 4:46 ` Martin A. Brown [this message]
2003-09-02 4:47 ` Nimit Gupta
2003-09-02 5:51 ` Nimit Gupta
2003-09-02 16:52 ` Stef Coene
2003-09-03 4:56 ` Nimit Gupta
2003-09-08 16:48 ` 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-106247814314243@msgid-missing \
--to=mabrown-lartc@securepipe.com \
--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.