Conversion cell atm per min - to - kps

Answered Question
Feb 25th, 2009

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?

I have this problem too.
0 votes
Correct Answer by ajagadee about 7 years 9 months ago

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

*Pls rate all helpful posts*

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Correct Answer
ajagadee Wed, 02/25/2009 - 20:25

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

*Pls rate all helpful posts*

Paolo Bevilacqua Thu, 02/26/2009 - 01:28

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

marikakis Thu, 02/26/2009 - 04:24

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.

Actions

This Discussion