quietyakr3, That seems more authorative than the other sources I've tried. Can you recommend a good source - other than yourself :-), that would help me learn more about ATM, etc.?)
Main Topics
Browse All TopicsI need help getting my virtual circuit to burst to full port-speed. We have configured a 20Mb/s sustained information rate (SIR) virtual circuit between two Cisco 7206 routers connected to a single telco ATM switch via two 40Mb/s DS3 local loops. The telco says we are permitted to burst to port speed for a short time, (the burst-window), after which we should revert back to the SIR. Once the router(?) determines no other user needs the bandwidth, it should again try to transmit at port speed. The best I have done so far is to burst to 24 or 25 Mb/s.
The local loops terminate on the same telco ATM switch, so there is no "cloud" to transit, and this is the only PVC on the link, so there should be no self-induced congestion. We average 3-5Mb/s on the link, but several times an hour, we have to synchronize some databases and pass a huge block of data in a short time.
Following one telco tech's suggestion, I set the VBR-nrt burst window to 33 cells. A different tech said we should set it to 4400 cells (!) A third telco tech said we should calculate how many cells we can pass in 125ms. (11700), and set the window-size accordingly.
What IS the right answer to enable me to send data at the full 40Mb/s rate? Is there a "rule-of-thumb" for setting the ATM VBR-nrt burst-window size
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.

Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
quietyakr3: I come from a frame-relay background, where there is a "guaranteed minimum" info rate and a "burst-to" maximum rate. It seems VBR-nrt is similar, but not quite the same. I am thinking it would be unwise switch to UBR, since that has no "guaranteed" bandwidth, and other, higher-priority, traffic would/could shut me down completely. Would you recommend ABR, which seems like it allows a guaranteed "minimum cell rate" with bursting to port capacity to allow me to maintain a 40Mb/s data stream? Can you "oversubscribe the link" by creating two ABR pvcs, each with a 20Mb minimum, and expect that either pvc might sustain a non-concurent, full-pipe data stream.
Not sure about a good source. The information I provided above was learned from Marconi and Cisco Engineers over the past few years.
Yes, Frame-Relay and ATM are similar in some respects but when it comes to committed rates, they are very different. Actually Frame-Relay has no guarantee, it has a committment, but not guarantee. What does this mean, it means that because the data is not scheduled fully through the network, it is possible (not likely, but possible) that data below CIR could get thrown away. In a properly run ATM network, there should never (outside of circuit failures) be a CBR cell or a VBR within SCR and MBS dropped.
Your right about the UBR portion. UBR gives no guarantee. If you have to have a guarantee than maybe ABR is better for you. Most IP applications have no need for a guarantee and if the network is not heavily oversubscribed UBR is more than enough. Now on the idea of buying two ABR PVCs and then running one at the full rate, that will work if your provider allows ABR. But, it can't be done with VBR-NRT unless the provider runs non-policing.
Hope this helps you. I think what your looking for is either ABR with minimum rate of 20Mbs. An alternative that might work for you is if the 40Mbs transfer is only needed for large transfers and they are always between the same two machines, you might look at a 20Mbs VBR and a UBR. You could then setup routing such that the two devices use the UBR but everything else uses the VBR. The big transfers would open up and use the full bandwidth if there was no other traffic to send and the network was not congested. You lose the "guarantee" on the big transfer traffic, but the cost may be lower than ABR.
I'll tell you that was very well said. If you want a second opinion.
You want more technical details about it probably won't find
any for that topic. You could go thorugh 100 pages of crap and
pull that out if you want to, but not much more concerning speed.
Thanks a lot for that description, that filled in a few 'holes' for me,
unimportant ones albeit, but it got on my nerves from time to time.
Business Accounts
Answer for Membership
by: quietyakr3Posted on 2002-12-12 at 11:54:38ID: 7574173
First off, the correct way in ATM is to match the SCR, PCR, and MBS on both ends. A mismatch should get thrown away with the policing.
Is your telco running vbr-nrt or vbr-nrt with tagging instead of policing? Most people don't understand ATM vbr correctly. VBR has three major parameters, SCR (sustained Cell Rate), PCR (Peak Cell Rate), and MBS (Maximum Burst Size).
The part people don't understand is that PCR is not Burst Rate in the sense of what people think of as bursting. The best way to think of vbr-nrt is to imagine that you are going to get SCR all the time. However, every once in a while, your allowed to increase your data rate (making sure you don't exceed PCR) for up to the MBS. Many people understand that; however, they don't usually understand the implications.
Here's an example much like yours. Let's assume the MBS is 256 cells. You have a SCR or 20Mb/s and a PCR or 40Mb/s. To make things nice, we'll assume that a DS3 is actually 40Mb/s even after the overhead. You can think of a cell as a time unit since every cell is exactly the same length of time. If you look at the possible cells that could fit on a DS3, you have a SCR that will allow every other cell to be used by this PVC. Because of your PCR and MBS, your allowed to use all the cells in a row for up to 256 extra cells. That means the amount of time you can burst can be calculated as:
256 cells
x 2 because only half of your cells are above SCR
X 53 53 bytes/cell
x 8 8 bits/byte
= 217,088 bits
now take:
(217,088 bits)(40,000,000 bits/sec) = 0.0054272 seconds
Now what happens when you burst to 40Mb/s for the 5ms that your allowed?
The rules say that you must drop to the 20Mb/s rate and never burst again until you've dropped below the 20Mbs for the number of cells that your going to burst for.
Think of MBS as a bucket full of "free passes for cells that are above SCR and not above PCR". When you put a cell into the pipe that is over SCR, you have to take a pass out of the bucket. On an MBS of 256, if you use 60, you still have 196 left. If you use all 256, you have none left and are not allowed above the 20Mb/s (every other cell). If you go for say 3 cells without sending a packet, you just earned back one free pass because there was a cell that you were allowed to have under the 20Mb/s SCR that you didn't use. As a result, you get back one of your burst passes. The bucket is only 256 cells though so if you run at 0 forever, you still only get 256 cells of burst when you want them.
Where does all this take us, well for any given length of time, the maximum throughput on vbr-nrt is SCR (in Mb/s) + MBS * 53 * 8 / (length of time). Since the + MBS part of that is so small, it's approximately SCR in addition, it gets closer and closer to SCR as the length of time goes up. At 5 ms, it might be 40Mb/s at 50ms, it's going to be around 22Mb/s, at 1s, it's going to be just slightly above 20Mb/s.
So, if your looking at performance tools, you probably won't see anything above 20Mb/s unless your monitoring your network to death which is a bad thing.
The next thing everyone says is, why then have the 40Mb/s PCR when I can't use it. Well, the issue is that you can and do use it without realizing it. Most of your traffic is highly bursty (web browsing, interactive telnet's, ssh's). Those types of traffic do really well because a given html page may only be a few KB and a few keystrokes on an ssh session is only a few bytes. The shortened response time by getting to use those extra cells every so often is very benefitial. And if you watch the traffic on a link, when people aren't browsing or hitting keystrokes, you have a chance to get those MBS "passes" back into the bucket.
So that's the detailed explanation. The short version is that PCR was never meant for large transfers like FTP. Yes it will benefit a bit, but your never going to get closer to PCR than SCR when talking about FTP. If you need 40Mb/s for FTP then you need to buy 40Mbs SCR or you need UBR traffic.