[LARTC] HTB: quantum vs. burst

[LARTC] HTB: quantum vs. burst

[Pavel Mores]

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?

TIA,

	pvl

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

Re: [LARTC] HTB: quantum vs. burst

[Stef Coene]

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


-- 

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/

Re: [LARTC] HTB: quantum vs. burst

[Pavel Mores]

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/

Re: [LARTC] HTB: quantum vs. burst

[Stef Coene]

> 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.
Indeed, it's 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?
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 :)  And burst is not made for big bursts like you did.  
It also helps if you disable HTB_HYSTERESIS in the htb qdisc.  See faq page 
for more info.

> - 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?
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 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.


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/

Re: [LARTC] HTB: quantum vs. burst

[Pavel Mores]

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.

> And burst is not made for big bursts like you did.

Yeah, I know.  I'm not saying this is a realistic scenario.  I set it
this big just to see it properly in the dumps and graphs.

> 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.

> > - 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?
> 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.

> 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*. :-)

	pvl

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

Re: [LARTC] HTB: quantum vs. burst

[Stef Coene]

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/

Re: [LARTC] HTB: quantum vs. burst

[Pavel Mores]

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/

Re: [LARTC] HTB: quantum vs. burst

[Stef Coene]

On Friday 17 January 2003 13:25, Pavel Mores wrote:
> 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.
As far as I understand is hysteries something that htb uses to speed up it's 
calculations.  Negative tokens and ctokens is something that's part of how 
htb works.  If a class has negative tokens, it can't burst anymore.  And it 
can "give" it's tokens to child classes.

> 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.  
Euh, I didn't know I already had a page online?

> I suppose that the burst
> bucket is filled up when the 200bps transmission starts, am I right?
You have 2 buckets.  One for the burst that contains tokens and one for the 
cburst that contatins ctokens.  These buckets are size according to the 
burst/cburst.  And they are filled when the class is created.  At the same 
time, new tokens are arriving at speed equal to rate/ceil.

> 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. :)

I have it online (http://www.docum.org/stef.coene/qos/htb.tar.bz2).  I run it 
like this :
./sethtb_burst ; ./ethloop < prog_burst > prog_burst.out ; ./plot_burst.sh 
prog_burst

> > 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?
yes and the ctoken will go negative.  Later on, when the child is asking less 
bandwidth, the ctokens will go up again.  During that time, the child classes 
can't borrow remaining bandwidth from the parent.

> > 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. ;-)

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/