Version 1.0, 4/10/02
Page 13 of 17 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.
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 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.