Re: OT: Shaping and extended burst

Well, if Be is too small the app will suffer.
If it is too large, in the extreme, you don't shape at all.
But the "right" one is dependent on so many things that we have
some rules to do something that is not too bad.

-Carlos

Chris Proctor @ 05/03/2011 12:06 -0300 dixit:
> Nod. This is on topic for me.
>
> I believe Aaron's interpretation is correct. I can understand why the
> burst is needed, but I have never been able to figure out "correct"
> burst size and what really happens when the burst size is too large or
> small.
>
> Chris
>
> On 3/5/2011 8:29 AM, Aaron Riemer wrote:
>> Thanks Carlos,
>>
>> I just wanted to know if my understanding was correct more than anything.
>> When things don't add up I like to question rather than just accept an
>> answer without knowing why. This I think helps to solidify my
>> understanding.
>>
>> Thanks for your help again mate.
>>
>> Cheers,
>>
>> -Aaron
>>
>> -----Original Message-----
>> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
>> Carlos G Mendioroz
>> Sent: Saturday, 5 March 2011 7:57 PM
>> To: Aaron Riemer
>> Cc: ccielab_at_groupstudy.com
>> Subject: Re: OT: Shaping and extended burst
>>
>> Aaron,
>> > What I am confused about is the fact that more than the CIR rate can
>> > actually be sent over the initial lets say 1 second ...
>>
>> Now think about it, it's only the *first* second. When did it happen in
>> an actual implementation ? :)
>>
>> It's called *burst* for a reason. And doing the analysis from the math
>> is not going to help you understand it, IMHO.
>>
>> It's there to compensate the jitter in the packets, because your
>> line rate is/may be way faster than your CIR, and your "small window
>> perception" (aka Tc) of the rate may not be accurate.
>>
>> As far as I see it, this is not OT at all.
>>
>> -Carlos
>>
>> Aaron Riemer @ 05/03/2011 04:34 -0300 dixit:
>>> Hi Guys,
>>>
>>>
>>>
>>> I am just reading up on the token bucket principles with shaping in
>>> particular with the use of Bc and Be (extended burst capability).
>>>
>>>
>>>
>>> I have read that when Be is configured the token bucket maximum size
>>> will
>>> equal Bc + Be. Therefore initially (Let's say the first Time Period
>>> Tc) Bc
>> +
>>> Be packets will be taken from the bucket.
>>>
>>>
>>>
>>> Does this mean that when Be is configured you can initially send more
>>> than
>>> the actual shaped rate?
>>>
>>>
>>>
>>> Take this example:
>>>
>>>
>>>
>>> I enable traffic shaping and set the shaped rate to 64kbps over a
>>> 128kbps
>>> serial link. I stick with the default Tc and therefore calculate Bc
>>> to be
>>> 8000bits (64000 * .125). I enable Be to be 8000bits as well.
>>>
>>>
>>>
>>> Going by the token bucket logic the shaper will take (Bc+Be) from the
>> bucket
>>> (the bucket is full to start with). This means 16000 bits are taken
>>> effectively allowing the burst to 128kbps for the first Tc of .125ms.
>>>
>>>
>>>
>>> What I am confused about is the fact that more than the CIR rate can
>>> actually be sent over the initial lets say 1 second of transfer (8 *
>>> Tc).
>> I
>>> calculate this to be 72k bits for the first second of transfer and then
>> 64k
>>> bits for every subsequent second assuming full load over one second.
>>>
>>>
>>>
>>> Is this correct? I am just trying to get my head around it and
>>> understand
>>> this completely.
>>>
>>>
>>>
>>> Any comments welcome as always.
>>>
>>>
>>>
>>>
>>>
>>> Thanks guys,
>>>
>>>
>>>
>>> -Aaron
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>

-- 
Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
Blogs and organic groups at http://www.ccie.net