From: Andreas Klauer <Andreas.Klauer@metamorpher.de>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] HTB: far unequal behaivor at a slight conf rate change
Date: Fri, 24 Feb 2006 09:36:13 +0000 [thread overview]
Message-ID: <20060224093613.GA10794@EIS> (raw)
In-Reply-To: <200602231908.27900.luciano@lugmen.org.ar>
On Thu, Feb 23, 2006 at 11:42:16PM -0300, Luciano Ruete wrote:
> That's becouse the _real_ scenario will look like this:
>
> root->parent_all_hosts->client_host_1->prio
> ->dfl
[...]
> ->client_host_N->prio
> ->dfl
Oh, okay, so you simplified it that way. All right.
> As you see, after 3 minutes the lower rate class has sent 3000 packets vs 1000
> packets from the high rate one. Don't know what to think...
There may be a misunderstanding between us, the way you modified your class
tree now, it seems to have errors. I'll explain below.
> My test bed at this moment is a gentoo
Right. No complaints here. ;-)
> with vde_switch daemon listening in a tuntap device.
> I suppose that htb is device independet, i hope it does not matter.
I don't have any experience with vde_switch and tuntap's (I don't even know
what those are, so much for ignorance). The only device-dependent factor I
came across with HTB so far is the overhead problem - not all devices have
the same overhead (PPP over Ethernet or whatever). So HTB calculating the
rate incorrectly is a possibility. It can be tuned using overhead/mpu
parameters, however in order to do that, you'd need to know correct values
first, and they can be a little hard to come by. I also doubt it's the
cause of your problem in this case.
> class htb 1:7005 parent 1:7000 leaf 7005: prio 3 quantum 1500 rate 23000bit ceil 230000bit burst 12Kb/8 mpu 0b overhead 0b cburst 1714b/8 mpu 0b overhead 0b level 0
> class htb 1:7004 parent 1:7000 leaf 7004: prio 1 quantum 1500 rate 207000bit ceil 230000bit burst 12Kb/8 mpu 0b overhead 0b cburst 1714b/8 mpu 0b overhead 0b level 0
> class htb 1:7000 root rate 256000bit ceil 256000bit burst 12Kb/8 mpu 0b overhead 0b cburst 1728b/8 mpu 0b overhead 0b level 7
The problem with this tree is that you took out the client class (the one
with rate and ceil 230000bit). When I said that child classes without
siblings don't make sense, I didn't mean to actually take out the child
class, but rather take out the parent of this child class; in your example
that would mean making the 230000bit class the root class.
In your setup now, by just looking at the class tree, not the statistics,
my guess would be that while each leaf class has a ceil of 230000bit,
they won't share the same 230000kbit, but rather utilize the full 256kbit
of their parent. That does not seem to be what you want. It still does
not explain the rates in this setup, too.
Especially the rate of the parent class seems low - if this is a testing
environment where you are filling out the classes to their maximum, it's
really odd that the parent class does not use it's full bandwidth. On the
other hand, I don't know how accurate the rate statistics of HTB are.
I don't have access to a properly working shaping setup right now to
verify wether it's the same on my setup.
If it isn't, I'd probably check first how much rate HTB can actually
use, because it's a very bad situation for HTB when it thinks it can
use more bandwidth than the link actually can guarantee.
Regards
Andreas Klauer
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
next prev parent reply other threads:[~2006-02-24 9:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-23 22:08 [LARTC] HTB: far unequal behaivor at a slight conf rate change Luciano Ruete
2006-02-23 22:38 ` Andreas Klauer
2006-02-24 2:42 ` Luciano Ruete
2006-02-24 9:36 ` Andreas Klauer [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-02-25 11:06 Luciano Ruete
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=20060224093613.GA10794@EIS \
--to=andreas.klauer@metamorpher.de \
--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.