Version 1.0, 4/10/02
Queue to Core Measurement Technique
The performance of the queue-to-core path can be measured by modifying a nominal input data stream such that the entire stream is forwarded to core. For example, changing the IP version in the IP header from 4 to 5 will cause the packets to be forwarded to the core.
The lab equipment sends this data stream at a known rate, and the amount of it that gets to the core is measured. Both the StrongARM core and the microcode count how many packets successfully reach the core. The microcode also counts how many packets failed to get queued to the core because the queue was full. In addition, the PHY or MAC count any packets that are dropped before they were received by the microengines. The ratio of packets that made it to the core over the total packets sent is multiplied by the input wire-rate to arrive at the queue to core success rate.
ATM Queue to Core Throughput
For ATM management cells, and PDUs with IP exceptions, the core interrupt service routine schedules a user-context interrupt handler that consumes the appropriate message queue. Then it simply re-cycles the buffer descriptors by pushing them back onto the freelist without further processing.
When faced with a stream of 100% exception PDUs, the IP Router Microengine is able to send over 200,000 PDUs/second to the core by this method. This is over half of OC-3’s 353,207 cells/second link capacity. The throughput of this communication method peaks at over 320,000 cells/second, but at that point over 10% of the input streams is discarded due to full queues to core, and the VxWorks interrupt handler sub-system complains about ring buffer overflow as it attempts to schedule the user-context interrupt handlers.
Ethernet Queue to Core Throughput
Ethernet exception frames are sent to the StrongARM core via the same message queue technique as ATM exceptions. Again, the interrupt service routine schedules a user-context interrupt handler for every interrupt. However, the Ethernet core handler copies the packets into the VxWorks pseudo-Ethernet driver and sends them up the VxWorks IP stack before re-cycling the buffer descriptors.
When forwarding exception packets to the VxWorks IP stack this way, the system is able to send 37,500 frames/second to the core. This is about 1/3 of the 148,810 frames/second on a 100Mbps Ethernet link (minimum-sized Ethernet frames).
If the packets are simply discarded by the user-context interrupt handler instead of being copied into VxWorks, then the success rate rises to over 145,000 frames/second – nearly full 100Mbps link bandwidth. The system is able to send more packets to the StrongARM core – rising to over 500,000 frames/second when faced with 4 ports at full bandwidth. However, the more it is over- subscribed, the higher percentage of packets the system drops – particularly as VxWorks succumbs to ring buffer overflow at about 200,000 frames/second.