- 4chan hell raisers finding fame brings heat?
- The 10 dumbest mistakes network managers make
- NetApp quits bidding war in face of EMC opposition
- CompuServe closes after 30 years
- Google to launch open-source Chrome OS this year
While our single frame size throughput and latency tests are useful in describing system limits, they are not representative of what's actually seen on enterprise networks in everyday use.
To model more real-world conditions, we used VeriWave's WiMix program -- so named because it involves wireless clients handling different packet sizes -- to generate enterprise application traffic. In this case, we offered a combination of VoIP, Windows Media video, Web and Windows file transfer (SMB, or server message block) traffic. WiMix not only forces access points to interleave long and short frames, but also to use QoS mechanisms to ensure timely delivery of voice and video.
We defined separate service-level agreements for each of the four traffic classes and gradually increased the overall load until one or more traffic classes violated its SLA. The highest load we could offer at which access points delivered all four traffic classes within their SLAs constituted the final result in this test.
The SLA parameters put the highest emphasis on protecting voice and video traffic. Voice had to meet a minimum R-value, a method of scoring audio quality. Video had to maintain strict boundaries on delay, jitter and loss. Web and SMB traffic could use whatever bandwidth was left over, but never less than 5% each of the total. (We used 5% minimums as a way of ensuring voice or video wouldn't "starve" the other classes.)
Well after testing concluded, we discovered an issue that caused us to offer only about a quarter as much video traffic as we intended. The other traffic classes – voice, Web and Windows file traffic – weren't affected. While the results we're presenting are valid, even for video, the traffic we offered didn’t push the systems as hard as we intended. It's possible that any or all of the systems might have delivered different results had we actually sent more video.
The good news is that all systems did an excellent job of protecting voice quality, and most handled huge numbers of concurrent calls. R-value, a VoIP scoring method, was uniformly high. All systems scored R-values of nearly 86 out of a possible 93 (though scores higher than 86 or 87 are rarely seen in live networks), with Motorola's access points slightly edging out the others.
Comment