Linux Advanced Routing and Traffic Control list
 help / color / mirror / Atom feed
From: Pavel Mores <pvl@uh.cz>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] HTB: quantum vs. burst
Date: Thu, 16 Jan 2003 18:50:24 +0000	[thread overview]
Message-ID: <marc-lartc-104274309113682@msgid-missing> (raw)
In-Reply-To: <marc-lartc-104272413214891@msgid-missing>

On Thu, Jan 16, 2003 at 06:56:41PM +0100, Stef Coene wrote:

> On Thursday 16 January 2003 14:34, Pavel Mores wrote:
> > Hello,
> >
> > a quick question: what exactly is the difference between quantum and
> > burst in HTB?
> >
> > Original HTB documentation states the following with respect to
> > quantums:
> >
> > "... when more classes want to borrow bandwidth they are each given some
> > number of bytes before serving other competing class. This number is
> > called quantum."
> >
> > Burst is defined like this:
> >
> > "The burst and cburst parameters control the amount of data that can be
> > sent at the maximum (hardware) speed without trying to serve another
> > class."
> >
> >
> > From the quotes, the purpose of quantums and both burst parameters seem
> > to be somewhat related, one might say overlapping.  Is it that quantums
> > apply in different situations than bursts?  If so, when is each of
> > quantum, burst and cburst applicable?
> Quantum and bursts have nothing common.  Quantum is used to share remaining 
> bandwidth between child classes.  So each class can send "quantum" bytes.  
> Each class is controlled with 2 buckets, one for the rate, one for the ceil.  
> These buckets have also a burst and this is burst for rate and cburst for 
> ceil.
> 
> Very simplified situation as example : So even if you have a big quantum of 
> let's say 60.000 bytes and you have a ceil of 6.000 bytes/s, you can only 
> send 6.000 packets / second so it takes 10 seconds to send.  But if you have 
> a burst of 30.000 byts/s and you have a very fast connection, you can send 
> 30.000 bytes very fast, but the remaining packets are send at ceil speed so 
> 6.000 bytes/s.  So it will take 5 seconds to send all the data.
> 
> Some more info abot quantum can be found on www.docum.org on the faq page.

Stef,

thanks for your answer.  I've read your FAQ and other sections of
www.docum.org. I've also been perusing Martin's original HTB
documentation now for a couple of days and doing graphing experiments
aimed at gaining better understanding of HTB's bursting behavior but
some questions remain. ;)

From what you write, I would still say that burst and quantum do have
something in common, namely that they both somewhat determine how much
data is a class permitted to send where it's its turn to send.  In your
example, it seems to me that setting burst kind of overrides for a
moment the behavior otherwise determined by quantum.  But I agree this
connection between quantum and burst may be seen as too weak or abstract
so I won't push this point any further.

Important notes to take:

- you use bytes *per second* to specify burst - do you mean it, or is
  that a typo?  From docs I understand that burst is specified in bytes.
- more importantly, it follows from my measurements that setting burst
  (not cburst, that's a different story) *won't* let a class go above
  its ceil - if you are interested, go to http://kostra.uh.cz/htb-bursting/ 
  (ignore the Czech text ;) and see the section under header "Experiment 1".
  Check out the complete config script and graphs of all three classes
  below.  1:78 has a bit fat burst set, still it cannot break its ceil.
  (However, it *does* make its parent class to break its ceil.)  Did I
  mess up the config?
- back to your example - I'd even dare to say that the class you
  described wouldn't profit from setting burst at all *unless* there's
  another class competing for the bandwidth.  (If there is a contention,
  the burst setting will matter.)  Can you confirm this?

Thanks again.

	pvl

_______________________________________________
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 18:50 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 [this message]
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
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-104274309113682@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