From: Larson, Chris (CLarson@usaid.gov)
Date: Thu Jan 09 2003 - 17:23:02 GMT-3
This is from the document
http://www.cisco.com/en/US/tech/tk39/tk51/technologies_tech_note09186a008010
2a42.shtml
on CCO. It explain the concept so you may want to refer to it. The formula
for figuring amount of time you can burst is in here also toward the bottom.
It also states that traffic shaping in ATM should be used as a mean of
controlling or decreasing latency not increasing bandwisdth. Anyway here is
a short Abstract from the document of those thing described in the previous
post.
It is useful to understand the concept of ATM cell time. The amount of time
that it takes for one ATM cell to pass a given point in an interface is
called the cell time. We can calculate this value as follows:
ATM cell time = 1 cell / ATM cell rate (in cells per second)
Here is a sample calculation for a DS-1 link:
1 cell / 3622 cells per second = 276.04 microseconds per ATM cell
Shaping Parameter Definition
SCR Defines the sustained rate at which you expect to transmit data,
voice and video. Consider SCR to be the true bandwidth of a VC and not the
long-term average traffic rate.
PCR Defines the maximum rate at which you expect to transmit data, voice
and video. Consider PCR and MBS as a means of reducing latency, not
increasing bandwidth.
MBS Defines the amount of time or the duration at which the router sends
at PCR. Calculate this time in seconds using the following formula: T =
(burst cells x 424 bits per cell) / (PCR - SCR) MBS will accommodate
temporary bursts or short spikes in the traffic pattern. For example, an MBS
of 100 cells allows a burst of three MTU-size Ethernet frames or one
MTU-size FDDI frame. It is important that you factor longer duration bursts
into the SCR.
VBR-nrt implementations follow a leaky bucket or token bucket algorithm. An
ATM VC needs to have a token in the bucket to transmit a cell. The algorithm
replenishes tokens in the bucket at the rate of SCR. If a source is idle and
does not transmit for a period of time, tokens accumulate in the bucket. An
ATM VC can use the accumulated tokens to burst at the rate of PCR until the
bucket is empty, at which point tokens are again replenished at the rate of
SCR.
It is important to understand that PCR is a temporary burst. The duration at
which you send at PCR is derived from the MBS translated into a "time on the
wire." For example, recall the above formula for calculating the cell time
with a DS-1 link:
1 cell / 3622 cells per second = 276.04 microseconds per ATM cell
On a DS-1 link, an MBS value of 100 equates to a PCR duration of 2.8
seconds. We recommend that you take the time to understand how the MBS value
translates to a PCR duration when provisioning VBR-nrt VCs.
> -----Original Message-----
> From: Brennan_Murphy@NAI.com [SMTP:Brennan_Murphy@NAI.com]
> Sent: Thursday, January 09, 2003 2:38 PM
> To: clarson52@comcast.net; ccielab@groupstudy.com
> Subject: RE: Burst with Frame vs ATM
>
> It'd be nice to have this in a spreadsheet with
> the ability to convert to frame relay.
> Anyone out there going to bite on this query
> or should I take it to NANOG? :)
>
> Thanks,
> BM
>
> -----Original Message-----
> From: Chris Home [mailto:clarson52@comcast.net]
> Sent: Wednesday, January 08, 2003 8:40 PM
> To: Brennan_Murphy@NAI.com; ccielab@groupstudy.com
> Subject: Re: Burst with Frame vs ATM
>
>
> I believe with ATM it is actually a formula that describes the amount of
> time that you can burst to PCR. So even if all bandwidth is available you
> can only burst to PCR for a certain number of seconds. This sounds like
> the
> leaky bucket you are referring to.
>
> I can try to dig out the formula.
>
> My understanding of it is basically this:
> If you have a SCR of say 20 mbs and a burst of 50mbs you have to transmit
> under 20 for enough time to fill the bucket with 50 megs worth of burst
> tokens. When you have bursts of traffic it can be accomodated for only as
> long as there are tokens iin the bucket. After that you will only get
> your
> SCR and traffic above 20 will get dropped.
>
> I forget the formula to figure out just how long you can operate a burst
> speed. It is a simple formula but I cannot seem to pull it out of my head
> at
> the momemet. It is usually not that long though if I remember right. When
> we
> had a 10 meg (maybe it was 20) scr and peak of 50 the total time we could
> use the 50 burst rate was under 3 seconds IIRC.
>
> Maybe someone else will comment and provide more info and the formula.
>
>
> ----- Original Message -----
> From: <Brennan_Murphy@NAI.com>
> To: <ccielab@groupstudy.com>
> Sent: Wednesday, January 08, 2003 2:23 PM
> Subject: OT: Burst with Frame vs ATM
>
>
> > Hi,
> >
> > I'm trying to understand the difference between Frame Relay and
> > ATM when it comes to maximum throughput. Suppose I
> > currently have a Frame circuit at 256K CIR with burst to 512K.
> > The Frame vendor claims that you can almost always achieve
> > the burst throughput....or at least consistently around 450K.
> > This seems to bear out under ttcp testing.
> >
> > But if you migrate from Frame to ATM, you aren't necessarily
> > getting the same throughput, right? I seem to recall ATM follows
> > a leaky bucket algorithm so that a scr/pcr of 256/512 would
> > actually give you less total bandwidth. Is this correct and
> > is there an easy way to determine how to translate from
> > frame to ATM so that bandwidth is roughly the same.
> > I do understand that bursting in Frame is not guaranteed
> > but most vendors do give you an idea of what to expect.
> >
> > I think I've got a decent understanding of converting Frame
> > protocol overhead into ATM protocol overhead. It's the burst
> > piece that is confusing me.
> >
> > I've looked around for a document on this subject but can't find
> > one. I'm more used to Frame than ATM... It would be pretty
> > cool if there were a simple Frame to ATM conversion calculator
> > out there somewhere.
> >
> > Anyone have any recommendations?
> >
> > Thanks!
> >
> > -BM
> > .
> .
.
This archive was generated by hypermail 2.1.4 : Sat Feb 01 2003 - 07:33:46 GMT-3