All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stef Coene <stef.coene@docum.org>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] HTB: quantum vs. burst
Date: Thu, 16 Jan 2003 20:28:17 +0000	[thread overview]
Message-ID: <marc-lartc-104274909423256@msgid-missing> (raw)
In-Reply-To: <marc-lartc-104272413214891@msgid-missing>

On Thursday 16 January 2003 20:48, Pavel Mores wrote:
> On Thu, Jan 16, 2003 at 08:05:24PM +0100, Stef Coene wrote:
> > No.  I did some tests my self witb burst and cburst.  The problem is that
> > it's very difficult to measuer and explain it.  You have to believe Devik
> > that it works :)
>
> I'm not saying that I don't believe him. ;)  However, bursting within
> complex multilevel hierarchies can bring about a number of rather opaque
> interactions.  If you need to be able to understand this (in other
> words, to know what you are doing), the basic info from the docs is just
> not enough.

> > It also helps if you disable HTB_HYSTERESIS in the htb qdisc.  See faq
> > page for more info.
>
> Take a look at the 1:76's graph if you care - see that depression
> between 140.  and 170. second?  It's not there because of lack of demand
> - 1:77 is still asking for bandwidth.  It's probably 1:76 retaliating
> for being pushed above its ceil between 10. and 40. second.  If I
> understand the docs correctly, the depression should not be there since
> I *did* set 1:76's burst, too.  I was thinking about disabling
> HTB_HYSTERESIS in hope that doing so would remove this problem but I
> haven't tried it yet.
If you want to undestand what's going on, you also have to graph the tokens 
and ctokens.  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 :)

> > No.  If you have a 10kbyte/s link and you have a class with ceil = rate > > 5kbyte/s and a big burst/cburst (100.000byte or so), you can measure the
> > burst.  The first 100.000 byte will be sended by the burst so it will be
> > sended in 10 second.
>
> I just repeated the experiment with the exception that only 1:78 (the
> one with burst set) was asking for bandwidth (the competing 1:77 was
> silent) and I'm afraid that I'm not able to see any burst anyway.  In my
> view, burst won't let me break my ceil. However, cburst will.
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.

> > I have some very detailed information about how the burst and cburst from
> > parent and child classes are interacting, but I still have to create a
> > page for it.  It also explains how burst and cburst can exists and how
> > the tokens and ctokens are changing when you are using the burst.  Maybe
> > something I can do tonight.  I will keep you informed.
>
> That would be *great*. :-)
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 :)

Stef

-- 

stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.oftc.net

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

  parent reply	other threads:[~2003-01-16 20:28 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 [this message]
2003-01-17 12:25 ` Pavel Mores
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-104274909423256@msgid-missing \
    --to=stef.coene@docum.org \
    --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.