Embedded Computer Network Latency Measurements with the G1-TSUMMARY
This Application Note defines a methodology for measuring an embedded protocol stack for packet latency. By sending a packet to a DUT and having test code in the DUT return that packet to the network in an echo-like function while measuring the time from stimulus packet time to response packet time (latency) as the packet rate is increased, a measure of performance of the DUT’s protocol stack may obtained. By adding CPU loading to the DUT representing the various applications that the CPU would normally be performing as part of its embedded processing mission while measuring the packet latency, the impact of the CPU loading on communications performance including determining maximum packet rate processing without loss and added packet jitter can be measured. These performance parameters are particularly important for applications including streaming media communications for voice and video. Results of optimizing network traffic buffer use, buffer copies, interrupt use, CPU utilization, etc. can be easily viewed thus expediting the typical system tuning iterations needed to obtain optimum performance.
INTRODUCTION AND BACKGROUND
Many current embedded applications include high speed network connections utilizing Ethernet and, commonly, a standard protocol stack such as TCP/IP for system communications. Such stacks are often obtained as companions to the off-the-shelf embedded operating system or from another vendor. In many cases the performance of the network interface is critical for successful system operation but thorough evaluation and system tuning for network performance is complicated by lack of real time performance observability. Factors such as interrupt performance, communications buffer management, instantaneous CPU utilization, etc. can all affect obtainable network throughput and jitter performance. Measuring the impact of system changes on communications performance is made easier with realtime feedback.
One way to obtain a measure of communications stack performance is to implement a simple echo function in the DUT. When a packet arrives from the network and traverses the stack to the application layer, it is simply turned around and transmitted back down the stack to the network. By observing the arrival and departure times at the network interface, the DUT’s stack latency can be measured as well as the total DUT induced jitter. By increasing the network stimulus packet rate up to line rate, the DUT’s maximum packet handling capacity can be determined. By dynamically varying the arrival times through stimulus traffic shaping, the DUT’s burst packet handling capability can be determined. By introducing other DUT stresses such as variable CPU utilization either through a dummy task or the actual embedded application loading, these factors impact on the communications performance may be analyzed.
TEST SETUP
Figure 1 – Measurement of DUT Stack Latency
The straightforward test setup is shown in Figure 1. The network traffic stimulus provided to the DUT may originate from a test tool such as the Singulus G1-T for convenience in crafting and shaping packet contents and loading factors. Or, the traffic stimulus may be the target system ultimately intended for interoperation with the DUT to achieve the actual operating network traffic characteristics. If the actual operating network traffic is used for testing, the DUT would need to generate responses to the stimulus traffic so that its latency may be measured. It may also be a combination of controlled stimulus as well as actual operating network traffic. Wherever the traffic originates, it is connected to the DUT via the Singulus G1-T Network Tap. The Singulus G1-T acts as a pass through network connection with a minimum of temporal distortion while it filters, captures, timestamps, and analyzes the line-rate bidirectional traffic on its network connections. Access to, and control of the Singulus G1-T is via a 10/100 Ethernet connection to a standard PC.
Figure 2 - Capture Screen with Time Stamps
Figure 2 shows the user interface view of a portion of the time stamped bidirectional traffic captured by the Singulus G1-T Network Tap shown in Figure 1. The “Time” column shows elapsed time during the capture while “Delta Time” shows the time between packets. In this example, stimulus packets are arriving approximately every 4.15 msec and are being echoed back to the Singulus G1-T in approximately 65.5 usec. The G1-T timestamp offers a 10 nsec resolution for precise characterization of the protocol stack jitter and latency performance.
By using the Singulus G1-T’s data export facilty, a capture may easily be transferred to an Excel spreadsheet for plotting loopback times vs packet stimulus rates, jitter, etc. and for test and qualification documentation archival.
The Singulus G1-T’s Monitor mode provides Received and Transmitted packet counters for each Network Tap interface to permit easy detection of DUT dropped or errored packets by length and type.
By using the Singulus G1-T’s capture filter options shown in Figure 3, it is easy to capture only the traffic being used for measuring performance. Figure 3 shows the setup for capturing only IP packets, for example. Up to 4 filters may be used simultaneously to capture only the traffic of interest. This can be especially useful in verifying the DUT stack performance with test traffic in the presence of normal application traffic loading as discussed below in “DUT Requirements”.
DUT REQUIREMENTS
An advantage of the suggested performance evaluation is that special, test-only DUT requirements are minimal for the tests described. Either all packets received at the top layer of the protocol stack are simply retransmitted or, perhaps, only the selected test packet types are retransmitted. The latter would allow full DUT application functionality thus allowing for the analysis of stack performance under realistic system loads.
Other DUT resident functionality might include a method to vary the DUT CPU loading or the setup of other DUT stress conditions to determine their effect on the stack performance. Although beyond the scope of this Application Note, the Fatpipe protocol and functionality (see [2], [3]) of the Singulus product line might be considered for in-band DUT control communications to facilitate dynamic DUT configuration during traffic analysis.
CONCLUSIONS AND OBSERVATIONS
A simple method of evaluating the performance of an embedded protocol stack utilizing the Stimulus, Filtered Capture, and Time Stamping functionality of the Singulus G1-T has been presented. The dynamic load stimulus capability, flexible line rate filter and capture capability, and low temporal distortion imposed on tapped traffic features of the Singulus G1-T make it an especially attractive low cost instrument for protocol stack performance analysis. Since a single high resolution timebase is used for time stamping traffic entering and leaving the DUT, time stamp coherency between data stream directions is guaranteed and jitter performance measurements may be made with high precision. With line rate filtering capabilities to separate the test traffic for measurement, realistic packets that are subject to full stack processing may be used for tests rather than relying on custom crafted packets with embedded timestamps and/or tags which might require special processing by the DUT. The capture results may be exported to a standard spreadsheet for analysis, graphing, and record keeping.
REFERENCES
1. Singulus G1-T User Guide, www.IneoQuest.com 2. Fatpipe Protocol Specification, www.IneoQuest.com 3. Fatpipe Debugging Article, www.IneoQuest.com
Download |
