I understand why you got confused.
Conversion of cells/sec into kbps is poorly documented,
regardless of the service type (vbr-rt or vbr-nrt).
I had the same problem when I was configuring vbr-nrt PVCs.
There are 2 issues here:
1) Some people only include the ATM cell payload (48 bytes) in the calculation,
while others use the entire cell size (53 bytes).
This has to do with the fact that user data are segmented into cells.
Do we define the rate of user data in kbps
before they are SARed or after they are SARed ?
In my opinion the most safe assumption is to calculate the rate with the entire cell size
(unless you can afford packet loss)
and keep in mind that the same traffic seen on an Ethernet has lower rate.
Depending on the mean network IP packet size, ATM overhead can reach ~30%.
Anyway, the SAR process introduces padding which
makes difficult to compute the correspondence between
ATM cells/sec and kbps on an Ethernet.
Finally, below is a quote from a vbr-nrt for routers document :
"note that the configured values in kbps
include the bandwidth consumed by user data
as well as by all ATM overhead,
including the 5-byte cell header, cell padding, and AAL5 overhead."
2) When converting bps to kbps
some people divide the bps with 1024 and not 1000,
which derives from the common misunderstanding
that the "k" used in networking is the same as
the "K" used when calculating memory size.
(I noticed that you and the router help (!) also wrote "Kbps" )
This is a highly controversial issue, so to convince you I will say that a case we had once opened concluded on the 1000 being correct.
Have a look at the following URL as well:
http://archvlsi.ics.forth.gr/~kateveni/534/04a/ex01_thruput.html
For vbr-nrt PVCs some ATM modules/port adapters officially support only particular values for the kbps parameter (for instance, multiples of a constant value).
This usually depends on the maximum rate the module supports (E3 or OC3, for example) and other implementation details.
You won't get a warning from the router for this, nor have I noticed problems when setting kbps to unsupported values (within the general supported range, of course).
However, official recommendations should be followed
before you can report any problems.
I haven't found anything relevant for vbr-rt PVCs,
so maybe this is not an issue for you.
In conclusion,
In 1 sec --> x kbits = x*1000 bits
In 1 sec --> y cells = y * 53 bytes = y*53 * 8 bits = y* 424bits
So, x= (y * 424)/ 1000 in kbps (with y being in cells/sec)
If you connect you router to an ATM switch you might notice that the router will be the first to drop packets when the PCR is approached.
You need to carefully monitor both sides and fine-tune parameters.
Note here that the ATM switch counters in cells/sec
are usually more reliable than the router's.
In my case, the router's counters didn't include all the ATM overhead. Only the AAL5 if I recall correctly.
M.
