From: Pavel Mores <pvl@uh.cz>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] HTB: quantum vs. burst
Date: Fri, 17 Jan 2003 12:25:02 +0000 [thread overview]
Message-ID: <marc-lartc-104280639011262@msgid-missing> (raw)
In-Reply-To: <marc-lartc-104272413214891@msgid-missing>
On Thu, Jan 16, 2003 at 09:28:17PM +0100, Stef Coene wrote:
> If you want to undestand what's going on, you also have to graph the tokens
> and ctokens.
Oh, I see. The negative values of tokens and ctokens that can be seen
frequently are because of the hysteresis setting?
Also, I have some trouble understanding the tokens/ctokens example on
www.docum.org. First, I would suggest that you add an additional bullet
specifying initial conditions more explicitly. I suppose that the burst
bucket is filled up when the 200bps transmission starts, am I right?
Second, it would be useful to state what ceil the example class has since
bursting is limited by ceil as we agreed before. Without knowing the
class' ceil it's hard to say at what speed the first <burst> bytes will
be released to the network - which is what the other calculations depend
on.
> I use the ethloop from Devik. It's a very nice think ones you
> understand how it works. I can send you my scripts and config files if you
> are intersed (and I think you are :)
You bet I am, thanks a lot. :)
> Indeed. I think I need some sleep :) Indeed, the ceil is respected if you
> use the burst parameter. It's the parent ceil that's broken.
That brings up a question: what happens if the parent, say 1:20, has its
own parent, say 1:10, and the 1:10 has already been overlimit. In other
words, class 1:10, already transmitting at its ceil speed, has a child
1:20 that breaks its ceil because one or more its own children are
bursting. Unevitably, 1:10 is forced above its ceil too, right? If
that is the case, the state of being "overceil" will spread all the way
up the class hierarchy to the root class?
> I had a hard time finding the directory where I stored my files :)
> But I found it. Now I have to figure out what I wanted to document :)
Oh, don't feel pressed, take your time, it's been a long time coming
anyway. ;-)
pvl
_______________________________________________
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-01-17 12:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-16 13:34 [LARTC] HTB: quantum vs. burst Pavel Mores
2003-01-16 17:56 ` Stef Coene
2003-01-16 18:50 ` Pavel Mores
2003-01-16 19:05 ` Stef Coene
2003-01-16 19:48 ` Pavel Mores
2003-01-16 20:28 ` Stef Coene
2003-01-17 12:25 ` Pavel Mores [this message]
2003-01-18 14:20 ` 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-104280639011262@msgid-missing \
--to=pvl@uh.cz \
--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