Texas Instruments SPRAA56 Measuring Task Scheduling Latencies, Measuring End-to-End Latencies

Page 12

SPRAA56

4.2Measuring Task Scheduling Latencies

Scheduling latency is defined as the time between a wakeup signal (semaphore post) to a pending task and the actual start of that task's execution.

DSP/BIOS provides a mechanism for measuring scheduling latency with the TSK_settime and TSK_deltatime APIs. These functions accumulate the difference in time from when a task is made ready to the time TSK_deltatime is called. The placement of the TSK_deltatime API therefore determines what is actually measured. Scheduling latency can be measured by placing the API directly after the task’s blocking call, which may be MBX_pend, SCOM_getMsg, or a similar API.

Time differences are accumulated in each task's internal STS object, so there is no need to create a separate STS object to measure scheduling latency.

This technique is used for each task in the instrumented application. For example, in the input task, the beginning of the run-time loop contains a call to TSK_deltaTime as follows:

while(1) // Tsk main processing loop begins

{

/* TSK_deltatime called immediately after last blocking call, to measure scheduling latency */

TSK_deltatime(TSK_self());

...

SCOM_getMsg(fromProctoInput, SYS_FOREVER); /* end of main processing loop */

...

}

4.3Measuring End-to-End Latencies

End-to-end latency is the time between the capture of a video frame in real-time, and the display of that same video frame some number (T) of milliseconds later. Long latencies are undesirable in bi-directional video applications, such as in a video conferencing systems. Such latency causes delays between questions and responses, and makes conversation difficult. In media playback systems, the tolerance for latency is usually higher.

In the example application, encode and decode occur within the same system. However, in many designs the encoder and decoder could be part of separate systems. To accurately measure latency, you need a method of indicating frame numbers and types and a method of measuring latency on both ends of the system. This example application provides frame numbering and identification as I or P frames, as well as a rudimentary measurement of latency from input to output.

The code to implement the latency measurement is divided into two sections. The first section makes a timestamp for a frame if the latency measurement has been completed for the previously timestamped frame. This code section is included in the video input task:

//measure input to output frame latency if (benchCapVid.captodisplay.done) {

benchCapVid.captodisplay.frameNum = frameCaptureCnt; benchCapVid.captodisplay.latency = CLK_getltime(); benchCapVid.captodisplay.done = 0;

}

12DSP/BIOS Real-Time Analysis (RTA) and Debugging Applied to a Video Application

Image 12
Contents Modifications to the Base Example RTA Techniques for Performance MeasurementViewing Benchmarks in the Instrumented Application References Appendix A. Performance ImpactImportant Benchmarks for Video Applications FiguresBase Application Overview SPRAA56TskInput DSP/BIOS and RF5 Components Used 1 LOG2 STS 3 TRC4 UTL Modifications to the Base Example Requirements for Viewing RTA BenchmarksSplitting the Encode and Decode CELLs Adding the Control TSK and MBX CommunicationQuerying the H.263 Encoder for Status TskInputTskO utput Controlling the Frame Rate RTA Techniques for Performance Measurement Measuring Function Execution Time with the UTL ModuleMeasuring Task Scheduling Latencies Measuring End-to-End LatenciesMeasuring the Frame Rate Programmatic Measurement of Total CPU Load Memory Bus Utilization 720*480 = 345,600 B 86,400 B14,400 B External memoryBitrate and Frame Type Methods for Transmitting Measured Performance Data Viewing Benchmarks in the Instrumented Application Application-Specific Control via GEL Scripts in CCStudioRequirements Running the Application Load the h263loopbackrta.out programSPRAA56 Interpreting the Benchmarks Expected Values for the STS Objects Expected and Measured STS Benchmarks Debug Mode Expected Values Delivered to the Message LogControlling the Run-Time Parameters Dynamically Expected and Measured Logged BenchmarksReferences Capture and Display Task BenchmarkingAppendix A. Performance Impact Overhead of Performance Measurement TechniquesRTA Effects on CPU Load Measured Performance of Benchmarking TechniquesMemory Footprint Memory Footprint DetailsImportant Notice