From: Chris Hugo (chrishugo@xxxxxxxxx)
Date: Thu Aug 29 2002 - 01:51:17 GMT-3
Hi All,
I have to say I made a error in my formula I have posted earlier in the day. I
was checking over the notes I made which was a little sloppy. You won't find th
is calculation on CCO. But the calculation I was meaning to post was :
(Access_Rate - Cir) / 8 = Be
Sorry if this confused anybody.
thanks,
chris hugo
Donny MATEO wrote:Now, i'm totally confused. Seems like we're mixing be for lo
sts of thing with be for frame-relay. I
suppose this value differs in definition and thus calculation.
For frame relay, I think this link clearly explain how FRTS works
http://www.cisco.com/warp/public/125/traffic_shaping_6151.html.
frame relay be
The amount of excess data allowed to be sent during first Tc interval in bits o
nce credit is built
up. Configure Be only if the Frame Relay CIR value is less than the AR. For PVC
s carrying voice
packets, the Be must be set to zero to ensure best possible voice quality. The
router only bursts
(Be) when there are tokens in the token bucket. The token bucket does not accru
e tokens unless the
amount of traffic being sent out is less than the CIR. The router can only burs
t for the first Tc,
after which the token bucket is empty. The value of Be by default is zero bits.
Now if AR is 192kbps and CIR is 64kbps. with 0.125 sec tc, would yields bc as 6
4000 * 0.125 = 8000
bits.
I suppose we want to configure up to AR so 192K is the target for the first Tc.
AR is in seconds and
tc is in 0.125 sec, so the first interval target rate should be 192/8 = 24000.
now we know in the
first interval we also sent 8000 bits (bc), so be would be 24000 - 8000 = 16000
bits. (that would
explain the token size as be + bc = 16000 + 8000 = 24000).
based on this
map-class frame test
frame cir 64000
frame bc 8000
frame be 16000
here is how it works based on my understanding.
init : 24000 token available in buckets
tc1 => send 240000 bits of data, so take 24000 token from the bucket
=> refresh token by byte increment (usually equal to bc) 1000 bytes per interva
l = 8000 bits
= 8000 token
tc2 => send 8000 bits, so take 8000 token from the bucket
=> refresh token by byte increment 8000 token
tc3 => send 8000 bits, so take 8000 token from the bucket
=> refresh token by byte increment 8000 token
tc4 => send 8000 bits, so take 8000 token from the bucket
=> refresh token by byte increment 8000 token
tc5 => send 8000 bits, so take 8000 token from the bucket
=> refresh token by byte increment 8000 token
tc6 => send 8000 bits, so take 8000 token from the bucket
=> refresh token by byte increment 8000 token
tc7 => send 8000 bits, so take 8000 token from the bucket
=> refresh token by byte increment 8000 token
tc8 => send 8000 bits, so take 8000 token from the bucket
=> refresh token by byte increment 8000 token
=> build credit to bucket for the next one sec => 24000 token.
Do correct me if I'm wrong
Donny
"Colin Barber"
,
west.co.uk> ccielab@groupstudy.com
Sent by: cc:
nobody@groupstudy. Subject: RE: I need FRTS help or review - TIME TO VOTE
com
29-08-2002 04:35
Please respond to
"Colin Barber"
Sorry about that, it's been a long day. At least I was consistent in my
error!
Correction:
CIR = 64000
Access rate = 96000
Tc = 1/8th sec
BC=8000
To burst up to the AR what is the value of BE?
option 1 BE=32000 (8*BC)+BE = 96000
option 2 BE=4000 at one Tc BC+BE=12000*Tc = 96000
-----Original Message-----
From: Volkov, Dmitry (Toronto - BCE) [mailto:dmitry_volkov@ca.ml.com]
Sent: 28 August 2002 20:59
To: 'Colin Barber'; Bauer, Rick
Cc: ccielab@groupstudy.com
Subject: RE: I need FRTS help or review - TIME TO VOTE
> -----Original Message-----
> From: Colin Barber [mailto:Colin.Barber@telewest.co.uk]
> Sent: Wednesday, August 28, 2002 3:30 PM
> To: Bauer, Rick; ccielab@groupstudy.com
> Subject: RE: I need FRTS help or review - TIME TO VOTE
>
>
> I think the confusion is:
>
> can (BC+BE)/Tc be greater than AR as Jim is saying because
> the interface
> will buffer the excess or
>
> (BC+BE)/Tc <= AR because the burst has to be transmitted within one Tc
>
> Your link states that the parameters control the rate of
> traffic onto the
> interface but not onto the line so is the interface buffering
> any excess and
> can you have a large excess?
>
>
> To put it another way: if your CIR is less than the access
> speed of the
> interface and you wish to burst to the full access speed, do
> you work out BE
> so that the access rate is achieved only in the first Tc or
> the access rate
> is achieved over a full second?
>
> I think we need a vote on the two options - I'm for option 2
>
> For example:
>
> CIR = 64000
> Access rate = 96000
> Tc = 1/8th sec
> BC=8000
>
> To burst up to the AR what is the value of BE?
>
> option 1 BC=32000 (8*BC)+BE = 96000
!!!!!!!!!! BE=32000 not BC !!!!
>
> option 2 BC=4000 at one Tc BC+BE=12000*Tc = 96000
!!!!!!!!!! BE=4000 not BC !!!!
>
> Colin
>
> -----Original Message-----
> From: Bauer, Rick [mailto:BAUERR@toysrus.com]
> Sent: 28 August 2002 19:55
> To: 'ccielab@groupstudy.com'
> Subject: RE: I need FRTS help or review
>
>
> This should help. The first couple of lines will answer your
> question in
> regard to CIR, BE, BC.
>
> http://www.cisco.com/warp/customer/125/21.shtml
>
> Rick, #9482
>
> -----Original Message-----
> From: Volkov, Dmitry (Toronto - BCE) [mailto:dmitry_volkov@ca.ml.com]
> Sent: Wednesday, August 28, 2002 2:07 PM
> To: 'Jim Brown'; 'Colin Barber'; 'Omer Ansari'
> Cc: 'ccielab@groupstudy.com'
> Subject: RE: I need FRTS help or review
>
>
> Jim,
>
> You are right traffic will be delayed and sent within 9th Tc interval
> (assuming Tc=1/8 sec).
> But Be is still Be - it is number of bits, and Be+Bc =< Port Speed
> (clocking) * Tc.
>
> We have to put actual number in config.
>
> 40000 bits will not be transmitted during 1st Tc - only 12000 bits.
> Other bits will be delayed until 9th Tc.
>
> Be - number of bits will be transmitted within 1st Tc ==> be = 12000
> -8000(Bc) = 4000 bits
>
> and this number 4000 we have to put in config as Be. The
> other bits will be
> delayed / dropped, whatever.
>
> I'm not 100% sure about it, but I got this logic from CCO.
>
> Colin right - the documentation on this subj is very unclear.
>
> This subj is like religion for me - believe or not believe :)
>
> Dmitry
>
> > -----Original Message-----
> > From: Jim Brown [mailto:Jim.Brown@caselogic.com]
> > Sent: Wednesday, August 28, 2002 11:35 AM
> > To: 'Colin Barber'; 'Omer Ansari'; 'ccielab@groupstudy.com'
> > Subject: RE: I need FRTS help or review
> >
> >
> > You do not necessarily need 320Kps available during the first
> > interval. The
> > packets are software queued before they are placed onto the
> > TxRing. This is
> > the whole idea behind shaping.
> >
> > They are not placed on the wire at exactly the same speed
> > designated per TC
> > interval.
> >
> > List, if I'm way off base please correct me and help me see
> the light.
> >
> > -----Original Message-----
> > From: Colin Barber [mailto:Colin.Barber@telewest.co.uk]
> > Sent: Wednesday, August 28, 2002 9:09 AM
> > To: 'Omer Ansari'; 'ccielab@groupstudy.com'
> > Subject: RE: I need FRTS help or review
> >
> >
> > What's the access speed of the interface? If it's 96k then this is
> > incorrect. In the first time slot BC+BE=40000. For that
> > amount of data to be
> > transferred in the first timeslot the access speed will need to be
> > 40000*8=320kbps.
> >
> > Colin
>
> --------------------------------------------------------------
> ----------------
> Live Life in Broadband
> www.telewest.co.uk
>
>
> The information transmitted is intended only for the person
> or entity to which it is addressed and may contain
> confidential and/or privileged material.
> Statements and opinions expressed in this e-mail may not
> represent those of the company. Any review, retransmission,
> dissemination or other use of, or taking of any action in
> reliance upon, this information by persons or entities other
> than the intended recipient is prohibited. If you received
> this in error, please contact the sender immediately and
> delete the material from any computer.
>
>
> ==============================================================
> ================
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:48:41 GMT-3