How We Tested And What We Discovered
We used the MCI Developer's Lab facilities in Richardson, Texas, to conduct our tests. MCI supplied most of the test equipment, as well as four live T1 circuits for trunking between the switches. T1 service showed a baseline delay of about 20 milliseconds. The concentrators received clock from a Northern Telecom Nortel Meridian PBX T1 connection, which used an MCI circuit as its reference source.
We created a small network between the two switches, first using a single T1 trunk (see "ATM Access Concentrator Test Infrastructure," above). Our analyzers supplied varying loads of ATM and Ethernet data traffic across multiple interfaces and monitored a test pattern over a T1 interface. All traffic measurements were taken concurrently.
We rated performance in three
categories:
T1 interface bit-error rates (Traffic Priority 1: highest); ATM throughput and latency (Priority 2); and Ethernet bridging throughput and latency (Priority 4).
For these comparative tests, we set ATM circuit parameters identically on each box--using the same SCR/PCR (Sustained Cell Rate/Peak Cell Rate) values, with SCR=1/2 PCR. We used identical traffic priority levels and ATM Adaptation Layers. Policing for inbound traffic was turned on, restricting the amount of traffic that the devices would accept. We also turned on Early Packet Discard to keep congestion from spiraling out of control.
Data traffic was generated and analyzed using the Wandel and Goltermann DA-30 Internetwork Analyzer's RTBench Application. RTBench generates IP packets of various sizes, increasing the injection rate in 10 percent increments, up to our target maximum. RTBench reports throughput at the maximum loss-less level, which is the highest point at which 100 perce
nt of submitted packets are still being received. In addition, we made latency calculations at this level.
The performance charts show the maximum lossless throughput at various packet sizes (64, 128, 256, 512, 768, 1,024, 1,280 and 1,518 bytes). The opposite axis reflects the delay at this point. Thus, you learn how much can be stuffed through the network without losing anything along with the time it takes to move the traffic.
· Interpreting the Results
Both the ADC Kentrox and 3Com Corp. units provide excellent unstructured T1 service, running a bit-error rate of 10-10 under normal conditions, getting as high as 10-8 under stress. This is well below our acceptable target of 10-6 errors.
ADC delivered excellent performance under perfect conditions--when our traffic was carefully controlled to fit within the available bandwidth. Under these conditions, ADC delivered more traffic with minimal delay.
However, when we forced the systems to
prioritize and police traffic, with SCR values above available bandwidth, 3Com's AccessBuilder 9600 performed much better. Because it is these heavy loading conditions that make the best use of ATM, filling pipes with only the most important traffic, we gave an overall performance lead to 3Com in the high-capacity IMA (Inverse Multiplexing over ATM) tests.
In our first round of tests, we used a single T1 trunk and did not oversubscribe services (see "T1 Test [Not Oversubscribed]" at left). The total of all PCR values was less than the capacity of the T1 trunk. We set up a circuit emulation stream at 452 Kbps, assigned highest priority, and also gave ATM and Ethernet bridging roughly 452 Kbps each. ATM took priority over Ethernet, with both getting less priority than the circuit emulation.
ADC Kentrox's AAC-3 turned in excellent performance in this first test. The 3Com unit showed wild variation in delay based on the Ethernet packet size used and showed consistently lower throughput. The ADC unit's num
bers remained very stable at any packet size.
Our next round of tests involved Inverse Multiplexing over ATM, bundling together four T1s into a single logical circuit (see ıIMA Test [4 T1 Bundle]ı page 91). By design, our data overran the circuitıs capacity, giving us a real opportunity to see how traffic prioritization works. We blasted 2,736 Kbps over the ATM links and 10 Mbps over the Ethernet (to be shaped to 1.5 Mbps by the switches), again giving priority to circuit emulation, ATM and then Ethernet bridging.
At this point, we allocated a full T1 PVC to our TTC FireBERD 6000 testers, sending a DDS-5 traffic pattern on one side while examining items like bit-error rates, frame loss and sync loss on the other. We found both tested products excel in handling high-priority circuit emulation traffic, to which you might allocate a video feed, for example. The FireBERD showed typical bit-error rates of 10-9, increasing errors to 10-8 under impaired conditio
ns. This is well within the acceptable range.
We noticed a momentary frame slip when we dropped T1 circuits from the IMA bundle, but the signal and timing were restored within 5 seconds in all cases.
In the healthy IMA tests, 3Comıs ATM performance held steady, with very consistent results. ADC showed much lower throughput with high variations in delay (see ıIMA Impaired Test [4 T1 Bundle]ı above right).
Simultaneously, 3Comıs bridging latency held steady at a low throughput rate, showing the effects of the bridging traffic getting prioritized out. ADC didnıt drop traffic but buffered insteadıresulting in higher bridging throughput with much more delay, but unfortunately affecting higher-priority traffic.
Test 3 introduced differential delay in two of the four T1s in the IMA bundle, adding 20 milliseconds to one and 30 milliseconds to the other. This can stress IMA service, because ATM cells must be delivered in order. If one pipe delivers cells late, cells from the others have to be buffered. Her
e the 3Com AccessBuilder 9600 maintained good performance while the AAC-3 showed inconsistent throughput and latency.
The final test used a degraded IMA trunk, with two of the four T1s completely disconnected. Now the ADC ATM performance became highly unstable, with 3Com holding steady though losing packets (as should be expected). Low-priority Ethernet bridging traffic still got through on the ADC switches, though it should have been starved out entirely, as it was on the 3Com device.
|