FRAMINGHAM (07/31/2000) - Our test environment consisted of a Netcom Systems' SmartBits 6000 chassis with four LAN 6,201-byte modules, each module containing two 1000BaseSX ports with SC connectors. The SmartBits chassis was running OS 1.4.15 with firmware Version 2.1.24. You can visit www.netcomsystems.com for more information on this testing product. Autonegotiation on all ports was enabled by default with flow control turned off. All frame loss and latency tests were performed using Netcom's SmartFlow Version 1.12.1. This software allows you to conduct throughput and latency tests in different configurations, and provides tools for analyzing and reporting the test data. The error test was conducted with Netcom's SmartWindow.
New 6-foot multimode fiber cables were used for the test. The same cables were used for all tests on all switches. All tests were conducted with 64-byte, 512-byte, 1,518-byte sized packets. To assure reliability of the testing conditions, each test was repeated three times on each device under test, with a cold boot of the DUT between test runs. The results of the three tests were averaged within each test situation.
The first test performed measured frame loss associated with traffic going through the DUT. During the throughput tests, each port on the chassis was configured to represent 100 different media access control (MAC)/IP addresses.
The traffic load was varied from 10% to 100% wire speed in 10% increments. When frame loss was encountered in a particular iteration, a finer granularity test was conducted using 1% traffic load increments. Frame loss was measured in following configurations:
Port to port, full-duplex - Ports 1,2 and 3 on the SmartBits chassis were configured to transmit to Ports 4, 5 and 6, respectively, with all traffic going through the switch. Each port on the chassis was configured to represent 100 users (different MAC/IP addresses).
Full-mesh throughput, full-duplex mode - The SmartBits chassis was configured to generate traffic in a full-mesh pattern, in which each port transmitted to all other ports. Each of the six ports on the chassis were configured to transmit equal amounts of traffic to five other ports, resulting in equal aggregate load on each port. The SmartBits chassis measured the data rate on incoming data streams from all six switch ports to determine if "internal" constraints are prevalent on the switch.
Multiple-to-single port throughput - Ports 1 and 2 on the SmartBits chassis were configured to transmit to Port 5, and Ports 3 and 4 were configured to transmit to Port 6, all traffic going through the DUT. The traffic load on Ports 1 through 4 was varied from 10% to 50% wire speed in 10% increments, resulting in an aggregate load of 20% to 100% on the receiving ports. This again was analyzing internal architecture and limitations of the switch under test.
The second major test performed measured the latency of the unicast packet going through the switch matrix. Latency was measured in a port-to-port configuration at the maximum traffic load with no frame loss (loaded) and at 50% load (unloaded). Latency was reported in microseconds, using the first-in/first-out method. The purpose of the third test was to determine how the switch handles frames with Cyclical Redundancy Check (CRC) errors. Each transmit port generated two traffic streams - all CRC errors and no errors. The traffic stream on egress ports was monitored for CRC errors to determine whether the DUT filtered out or forwarded bad frames. The fourth test determined whether the DUT exhibited head-of-line blocking (HOLB). A HOLB condition occurs when a congested port on the DUT causes frame loss on uncongested ports. To simulate a HOLB scenario, one of the ports was overloaded with 120% traffic, while another port received only a 40% load. We monitored frame loss on the uncongested port to determine whether the DUT exhibited HOLB.
A detailed description of the testing methodology, the raw data of the tests, and pictures of the testing conditions can be found at www.appliedresearch.org.