![]() |
|
| F E A T U R E | |
|
|
|
September 4, 2000 |
||
|
|
How We Tested ATM IADs We stress-tested the ATM integrated access devices with voice and data traffic, both in large and small packets, looking at voice-prioritization and call-completion capabilities. By Darrin Woods To put the products through their paces, we ran a combination of voice and data traffic through the boxes to see how they responded. We wanted to stress the units to see if voice prioritization would allow calls to go through at the expense of data. We devised six 30-minute tests: Three acted as baselines of voice and data, and three served as combinations of voice and data traffic. We created two PVCs on each unit: One was a VBR-rt circuit with a PCR of 1,811 cps for our voice calls, and the other was a UBR PVC with a PCR of 3,622 cps. We used G.729A voice compression on all units except Accelerated Networks' AN-30, which supports only G.726. Our baselines consisted of one test to see how many voice calls could be completed on all 24 channels simultaneously without any other traffic, and two tests to determine how well the units could handle both large and small data packet sizes. In one of those two tests, we sent 1,512-byte packets through the IADs at a rate of 1,408 Kbps; thus, we could run the ATM DS-1 above line rate and make sure that every box dropped cells, letting us determine the maximum rate at which data could be pushed. The other data-packet test was similar, except we used 64-byte packets. In the fourth and fifth tests, we combined simultaneous calls from the first test with the data of the second and third, to determine how well the units lived up to their IAD designations. Our last test most closely resembled the real world, with simultaneous calls placed along with the transmission of data packets containing anywhere from 64 to 1,512 bytes, with the Adtech AX/4000 Gaussian distribution pattern sent over the same ATM DS-1 connection. We connected the units back-to-back via a single DS-1 connection (see "Test-Equipment Topology"), without an ATM network between them. Although this let us avoid any problems that might occur within an ATM network (such as congestion that would cause the units to drop packets or not complete calls), it also prevented us from testing how the units would be able to deal with delay and jitter in the voice calls. We used AAL2 encapsulation for voice calls and AAL5 for data, except in our testing of the Memotec device, which supports AAL0. For data generation, we used two 10/100 Ethernet modules in an Adtech AX/4000. One generated IP traffic at the packet size and line rate specified, while the other analyzed the packets at the receiving end and determined just how much was lost due to congestion. For all data tests, we transmitted data at a rate of 1,408 Kbps; we chose this rate to push as much data through as possible and show where each product would begin dropping cells. On the voice side, we used Hammer Technologies' Hammer IT call generator to place and receive calls over the network. The Hammer IT allowed us to create quick and easy scripts, and it came with prerecorded male voice samples, which we used in our tests. Our test call consisted of several voice samples sent in both directions over the network, with the total call lasting about 50 seconds (see "Voice Calls Placed Over the Network" for a description of the call). In the first of our six tests, all channels were brought up at the same time; in the other tests involving voice, all channels were brought up in random sequence over a 10-second period.
|
|
|
|
PAGE: 1 I 2 I 3 I 4 I 5 I 6 I 7 I 8 I NEXT PAGE |
||












