cancel
Showing results for
Did you mean:
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

## Conversion cell atm per min - to - kps

I have a link to 128 kbps, and the supplier tells me that has the following consumption:

7.22 cell p min ----- 46.208 kbps

11.88 cell p min ----- 76.032 kbps

Which is the formula for conversion, to validate that this conversion is correct?

1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

## Re: Conversion cell atm per min - to - kps

Pedro,

I am not an ATM Expert but let me try and explain this to you.

I think your provider is using bps conversion of 384, that is 48 Bytes per cell. Typically, the value of 384 is used when the reference date is the non ATM entering an ATM core.

48 * 8 = 384.

So,

(7.22 * 384)/60 = 46.208

Regards,

Arul

3 REPLIES
Cisco Employee

## Re: Conversion cell atm per min - to - kps

Pedro,

I am not an ATM Expert but let me try and explain this to you.

I think your provider is using bps conversion of 384, that is 48 Bytes per cell. Typically, the value of 384 is used when the reference date is the non ATM entering an ATM core.

48 * 8 = 384.

So,

(7.22 * 384)/60 = 46.208

Regards,

Arul

Hall of Fame Super Gold

## Re: Conversion cell atm per min - to - kps

Something appears wrong here. ATM calculation must always include a cell header of 5 bytes, so the multiplicative factor is 53, not 48.

Gold

## Re: Conversion cell atm per min - to - kps

Paolo, you are right, but the client is always more right :-) Accounting for the ATM cell header overhead in the alleged supplied data rate gives a false sense to the client about the amount of data that can be transferred when the estimated by the client required data rates have been calculated in some other media with less overhead (e.g. frame-relay, ethernet). A better approximation of what can be expected by the client occurs when excluding the cell header. Still, even in this case, there can be even more overhead not accounted for, such as cell padding (which can result in an entire cell being almost wasted for every small voice packet sent). I suppose AAL5 style of overheads can be considered somewhat equivalent to other L2 overheads. Of course, you are right in the sense that the provider has to actually support a higher data rate than the one it reports to the client for everything to work.

p.s. In case you are interested:

http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080093c9a.shtml#pervc_stats

"While ATM switches think in terms of cells, and do provide per-VC cell counts, routers with an ATM interface think in terms of packets (specifically, AAL5 PDUs)."... "Note that bytes, counted for each AAL5 PDU in IOS, include only layer 3 packet bytes plus 8-byte LLC/SNAP header. These bytes do not include variable length padding, AAL5 trailer and ATM cell header. "

The consequence of this was voice quality issues that we could not determine the cause. It looked like we had enough bandwidth, but we didn't. If client can see similar counters, instead of the cells typically reported in an ATM switch, client can get very puzzled. When cell counters are also reported, as is the case here by supplier, then we can assume the actual required data rate is supported.

263
Views
0