Back to the basics: How to measure real-time performance - Embedded.com

Back to the basics: How to measure real-time performance

Real-time performance generally is agreed to be one of the most important criteria considered by developers when selecting an RTOS for embedded applications.

Embedded market researchers Evans Data Corporation and Venture Development Corporation (VDC) recently found that “real-time performance” ranked #1 among factors considered by developers when selecting a commercial real-time operating system. But, just what is “real-time performance,” and how is it measured?

Real-time performance
Real-time performance can be defined as the speed with which an RTOS (or any software for that matter) can complete its functions in response to an event. The “real-time” aspect implies that the software response to one event is needed before some independently occurring second event takes place.

For example, in response to an automobile engine’s intake valve opening, the engine control software must calculate the correct air-fuel mixture and have it injected into the cylinder before the valve closes in preparation for the compression stroke. It is critical that the response to the first event is completed in time to meet the needs of the second event. This response may include many things, but paramount among them are interrupt processing and system services.

Interrupt Processing
Real-time systems are generally designed to be reactive in nature, and the events to which they must react are generally made known to the system as interrupts. The processor, upon recognizing an interrupt, performs certain actions and executes instructions that were designed to react to this event.

In most cases, the processor is already performing some instructions immediately prior to recognizing the interrupt. This processing must be “interrupted,” and then later resumed when the critical real-time response of the interrupt has been completed. Most RTOSes are designed to provide a means for the developer to handle interrupt processing and also to schedule and manage execution of application software threads. Interrupt processing generally includes the following:

* suspending whatever thread currently is executing,
* saving thread-related data that will be needed when the thread is resumed,
* transferring control to an interrupt service routine (ISR),
* performing some amount of processing in the ISR to determine exactly what action is needed,
* retrieving/saving any critical (incoming) data associated with the interrupt,
* setting any required device-specific (output) values,
* determining which thread should now execute given the change in environment created by the interrupt and its processing,
* clearing the interrupt hardware to allow the next interrupt to be recognized,
* transferring control to the selected thread, including retrieval of any of its environment data that was saved when it was last interrupted.

All of that (and perhaps more, depending on the RTOS) is included in “interrupt processing,” which is only one aspect of real-time performance. It’s no wonder that implementation of these operations in a particular RTOS can make a significant difference in real-time performance.

System Services
Real-time operating systems must do more than simply respond to interrupts. They also must schedule and manage the execution of application software threads. The RTOS handles requests from threads to perform scheduling, message passing, resource allocation, and many other services. In most instances, services must be performed quickly, so the thread can complete its assigned processing before the occurrence of the next interrupt.

While not a part of interrupt processing, the system service is a critical real-time response that can make or break a system. System service processing includes the following:

* scheduling a task or thread to run upon the occurrence of some future event,
* passing a message from one thread to another,
* claiming a resource from a common pool,

Even more variable than interrupt processing, the implementation of system services is equally critical in achieving good real-time performance in an RTOS. Together with interrupt processing, system services combine to form the most significant processing that an RTOS is asked to perform. Different RTOS implementations will approach these functions differently, and with different architectures, producing a wide range of performance.

Why is performance so critical?
The time required for completion of these functions is particularly critical in real-time systems, which must be deterministic, and also must respond rapidly or suffer loss of data or even fundamental malfunction of the system.

An example might be a flight-control system that must respond to a pilot input in time to avoid a stall, or a disk-drive controller that must stop the drive’s read head at precisely the point at which data is to be read or written. Rapid-fire interrupts from high-speed data packet arrival into a DSL router also must be handled promptly to avoid triggering a retry because one was missed.

Processor speed is critical in executing all of the RTOS instructions required to perform the desired function, but brute force alone cannot satisfy system demands, nor can it provide the most economical or efficient solution.

While a 2GHz processor might breeze through code in satisfactory time, it also might be too costly, or draw too much power, or present physical packaging challenges that make it undesirable for some embedded applications. A more economical processor, running an efficient RTOS, might do just as well in performance, or even better, yet cost far less and not pose the power/heat/packaging problems of a faster processor.

How is real-time performance measured?
By focusing on the most significant elements of performance, a reasonable assessment of real-time performance can be measured in a rigorous fashion that lends itself to comparisons between multiple RTOSes on a common hardware platform.

Thus, by comparing each RTOS according to how well it performs specific critical functions, developers can quantify real-time performance and make the best decision according to their application needs. The critical RTOS functions to be measured include:

RTOS Functions Measured

* Context Switch (CS) : Time required to save current thread’s context, find highest priority ready thread, and restore its context.

* Interrupt Latency Range (ILR) : Amount of time interrupts are disabled.

* RTOS System Services
o tx_thread_suspend. Suspend an application theread.
o tx_thread_resume. Resume a previously suspended thread.
o tx_thread_relinquish. Relinquish control to other application threads.
o tx_queue_send . Send a message to a message queue.
o tx_queue_receive. Get a message from a message queue.
o tx_semaphore_get. Get an instance from a counting semaphore.
o tx_semaphore_put. Place an instance in a counting semaphore.
o tx_mutex_get. Obtain ownership of a mutex.
o tx_mutex_put. Release ownership of a mutex.
o tx_event_flags_set. Set or clear event flags.
o tx_event_flags_get. Retrieve event flags.
o tx_block_allocate. Allocate a memory block.
o tx_block_release. Release a memory block.
o tx_byte_allocate. Allocates bytes of memory.
o tx_byte_release. Release a previously allocated memory area.

For each system service above, the following are measured:

o Immediate Response(IR) :Time required to process the request immediately, i.e., no thread suspension or thread resumption.

o Thread Suspend(TS) : Time required to process the request when the calling thread is suspended due to unavailability of the resource.

o Thread Resumed(TR) : Time required to process the request when a previously suspended thread (of the same or lower priority) is resumed as a result of the request.

o Thread Resumed and Context Switched (TRCS) : Time required to process the request when a previously suspended higher-priority thread is resumed as a result of the request. Since the resumed thread is higher-priority, a context switch to the resumed thread is also performed from within the request.

Example timings of these functions are shown in the Table below . The reference platform used was an ARM9 processor, running at 40MHz, under the ThreadX RTOS. These times generally scale linearly with clock rate for most 32-bit processors.

John Carbone is vice president of marketing at Express Logic, Inc.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.