From a454e88d34be216c74e26fa196cc861fe09a1f03 Mon Sep 17 00:00:00 2001 From: Ralf Corsepius Date: Wed, 22 Jan 2003 05:53:29 +0000 Subject: 2003-01-22 Ralf Corsepius * wksheets.texi: Remove from CVS. * timing.texi: Remove from CVS. --- doc/supplements/arm/timing.texi | 460 ---------------------------------------- 1 file changed, 460 deletions(-) delete mode 100644 doc/supplements/arm/timing.texi (limited to 'doc/supplements/arm/timing.texi') diff --git a/doc/supplements/arm/timing.texi b/doc/supplements/arm/timing.texi deleted file mode 100644 index 302a1391a8..0000000000 --- a/doc/supplements/arm/timing.texi +++ /dev/null @@ -1,460 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - - -@node Timing Specification, Timing Specification Introduction, Memory Requirements RTEMS RAM Workspace Worksheet, Top - -@chapter Timing Specification -@ifinfo -@menu -* Timing Specification Introduction:: -* Timing Specification Philosophy:: -* Timing Specification Methodology:: -@end menu -@end ifinfo - - -@node Timing Specification Introduction, Timing Specification Philosophy, Timing Specification, Timing Specification - -@section Introduction - -This chapter provides information pertaining to the -measurement of the performance of RTEMS, the methods of -gathering the timing data, and the usefulness of the data. Also -discussed are other time critical aspects of RTEMS that affect -an applications design and ultimate throughput. These aspects -include determinancy, interrupt latency and context switch times. - - -@node Timing Specification Philosophy, Timing Specification Determinancy, Timing Specification Introduction, Timing Specification - -@section Philosophy -@ifinfo -@menu -* Timing Specification Determinancy:: -* Timing Specification Interrupt Latency:: -* Timing Specification Context Switch Time:: -* Timing Specification Directive Times:: -@end menu -@end ifinfo - -Benchmarks are commonly used to evaluate the -performance of software and hardware. Benchmarks can be an -effective tool when comparing systems. Unfortunately, -benchmarks can also be manipulated to justify virtually any -claim. Benchmarks of real-time executives are difficult to -evaluate for a variety of reasons. Executives vary in the -robustness of features and options provided. Even when -executives compare favorably in functionality, it is quite -likely that different methodologies were used to obtain the -timing data. Another problem is that some executives provide -times for only a small subset of directives, This is typically -justified by claiming that these are the only time-critical -directives. The performance of some executives is also very -sensitive to the number of objects in the system. To obtain any -measure of usefulness, the performance information provided for -an executive should address each of these issues. - -When evaluating the performance of a real-time -executive, one typically considers the following areas: -determinancy, directive times, worst case interrupt latency, and -context switch time. Unfortunately, these areas do not have -standard measurement methodologies. This allows vendors to -manipulate the results such that their product is favorably -represented. We have attempted to provide useful and meaningful -timing information for RTEMS. To insure the usefulness of our -data, the methodology and definitions used to obtain and -describe the data are also documented. - - -@node Timing Specification Determinancy, Timing Specification Interrupt Latency, Timing Specification Philosophy, Timing Specification Philosophy - -@subsection Determinancy - -The correctness of data in a real-time system must -always be judged by its timeliness. In many real-time systems, -obtaining the correct answer does not necessarily solve the -problem. For example, in a nuclear reactor it is not enough to -determine that the core is overheating. This situation must be -detected and acknowledged early enough that corrective action -can be taken and a meltdown avoided. - -Consequently, a system designer must be able to -predict the worst-case behavior of the application running under -the selected executive. In this light, it is important that a -real-time system perform consistently regardless of the number -of tasks, semaphores, or other resources allocated. An -important design goal of a real-time executive is that all -internal algorithms be fixed-cost. Unfortunately, this goal is -difficult to completely meet without sacrificing the robustness -of the executive's feature set. - -Many executives use the term deterministic to mean -that the execution times of their services can be predicted. -However, they often provide formulas to modify execution times -based upon the number of objects in the system. This usage is -in sharp contrast to the notion of deterministic meaning fixed -cost. - -Almost all RTEMS directives execute in a fixed amount -of time regardless of the number of objects present in the -system. The primary exception occurs when a task blocks while -acquiring a resource and specifies a non-zero timeout interval. - -Other exceptions are message queue broadcast, -obtaining a variable length memory block, object name to ID -translation, and deleting a resource upon which tasks are -waiting. In addition, the time required to service a clock tick -interrupt is based upon the number of timeouts and other -"events" which must be processed at that tick. This second -group is composed primarily of capabilities which are inherently -non-deterministic but are infrequently used in time critical -situations. The major exception is that of servicing a clock -tick. However, most applications have a very small number of -timeouts which expire at exactly the same millisecond (usually -none, but occasionally two or three). - - -@node Timing Specification Interrupt Latency, Timing Specification Context Switch Time, Timing Specification Determinancy, Timing Specification Philosophy - -@subsection Interrupt Latency - -Interrupt latency is the delay between the CPU's -receipt of an interrupt request and the execution of the first -application-specific instruction in an interrupt service -routine. Interrupts are a critical component of most real-time -applications and it is critical that they be acted upon as -quickly as possible. - -Knowledge of the worst case interrupt latency of an -executive aids the application designer in determining the -maximum period of time between the generation of an interrupt -and an interrupt handler responding to that interrupt. The -interrupt latency of an system is the greater of the executive's -and the applications's interrupt latency. If the application -disables interrupts longer than the executive, then the -application's interrupt latency is the system's worst case -interrupt disable period. - -The worst case interrupt latency for a real-time -executive is based upon the following components: - -@itemize @bullet -@item the longest period of time interrupts are disabled -by the executive, - -@item the overhead required by the executive at the -beginning of each ISR, - -@item the time required for the CPU to vector the -interrupt, and - -@item for some microprocessors, the length of the longest -instruction. -@end itemize - -The first component is irrelevant if an interrupt -occurs when interrupts are enabled, although it must be included -in a worst case analysis. The third and fourth components are -particular to a CPU implementation and are not dependent on the -executive. The fourth component is ignored by this document -because most applications use only a subset of a -microprocessor's instruction set. Because of this the longest -instruction actually executed is application dependent. The -worst case interrupt latency of an executive is typically -defined as the sum of components (1) and (2). The second -component includes the time necessry for RTEMS to save registers -and vector to the user-defined handler. RTEMS includes the -third component, the time required for the CPU to vector the -interrupt, because it is a required part of any interrupt. - -Many executives report the maximum interrupt disable -period as their interrupt latency and ignore the other -components. This results in very low worst-case interrupt -latency times which are not indicative of actual application -performance. The definition used by RTEMS results in a higher -interrupt latency being reported, but accurately reflects the -longest delay between the CPU's receipt of an interrupt request -and the execution of the first application-specific instruction -in an interrupt service routine. - -The actual interrupt latency times are reported in -the Timing Data chapter of this supplement. - - -@node Timing Specification Context Switch Time, Timing Specification Directive Times, Timing Specification Interrupt Latency, Timing Specification Philosophy - -@subsection Context Switch Time - -An RTEMS context switch is defined as the act of -taking the CPU from the currently executing task and giving it -to another task. This process involves the following components: - -@itemize @bullet -@item Saving the hardware state of the current task. - -@item Optionally, invoking the TASK_SWITCH user extension. - -@item Restoring the hardware state of the new task. -@end itemize - -RTEMS defines the hardware state of a task to include -the CPU's data registers, address registers, and, optionally, -floating point registers. - -Context switch time is often touted as a performance -measure of real-time executives. However, a context switch is -performed as part of a directive's actions and should be viewed -as such when designing an application. For example, if a task -is unable to acquire a semaphore and blocks, a context switch is -required to transfer control from the blocking task to a new -task. From the application's perspective, the context switch is -a direct result of not acquiring the semaphore. In this light, -the context switch time is no more relevant than the performance -of any other of the executive's subroutines which are not -directly accessible by the application. - -In spite of the inappropriateness of using the -context switch time as a performance metric, RTEMS context -switch times for floating point and non-floating points tasks -are provided for comparison purposes. Of the executives which -actually support floating point operations, many do not report -context switch times for floating point context switch time. -This results in a reported context switch time which is -meaningless for an application with floating point tasks. - -The actual context switch times are reported in the -Timing Data chapter of this supplement. - - -@node Timing Specification Directive Times, Timing Specification Methodology, Timing Specification Context Switch Time, Timing Specification Philosophy - -@subsection Directive Times - -Directives are the application's interface to the -executive, and as such their execution times are critical in -determining the performance of the application. For example, an -application using a semaphore to protect a critical data -structure should be aware of the time required to acquire and -release a semaphore. In addition, the application designer can -utilize the directive execution times to evaluate the -performance of different synchronization and communication -mechanisms. - -The actual directive execution times are reported in -the Timing Data chapter of this supplement. - - -@node Timing Specification Methodology, Timing Specification Software Platform, Timing Specification Directive Times, Timing Specification - -@section Methodology -@ifinfo -@menu -* Timing Specification Software Platform:: -* Timing Specification Hardware Platform:: -* Timing Specification What is measured?:: -* Timing Specification What is not measured?:: -* Timing Specification Terminology:: -@end menu -@end ifinfo - - -@node Timing Specification Software Platform, Timing Specification Hardware Platform, Timing Specification Methodology, Timing Specification Methodology - -@subsection Software Platform - -The RTEMS timing suite is written in C. The overhead -of passing arguments to RTEMS by C is not timed. The times -reported represent the amount of time from entering to exiting -RTEMS. - -The tests are based upon one of two execution models: -(1) single invocation times, and (2) average times of repeated -invocations. Single invocation times are provided for -directives which cannot easily be invoked multiple times in the -same scenario. For example, the times reported for entering and -exiting an interrupt service routine are single invocation -times. The second model is used for directives which can easily -be invoked multiple times in the same scenario. For example, -the times reported for semaphore obtain and semaphore release -are averages of multiple invocations. At least 100 invocations -are used to obtain the average. - - -@node Timing Specification Hardware Platform, Timing Specification What is measured?, Timing Specification Software Platform, Timing Specification Methodology - -@subsection Hardware Platform - -Since RTEMS supports a variety of processors, the -hardware platform used to gather the benchmark times must also -vary. Therefore, for each processor supported the hardware -platform must be defined. Each definition will include a brief -description of the target hardware platform including the clock -speed, memory wait states encountered, and any other pertinent -information. This definition may be found in the processor -dependent timing data chapter within this supplement. - - -@node Timing Specification What is measured?, Timing Specification What is not measured?, Timing Specification Hardware Platform, Timing Specification Methodology - -@subsection What is measured? - -An effort was made to provide execution times for a -large portion of RTEMS. Times were provided for most directives -regardless of whether or not they are typically used in time -critical code. For example, execution times are provided for -all object create and delete directives, even though these are -typically part of application initialization. - -The times include all RTEMS actions necessary in a -particular scenario. For example, all times for blocking -directives include the context switch necessary to transfer -control to a new task. Under no circumstances is it necessary -to add context switch time to the reported times. - -The following list describes the objects created by -the timing suite: - -@itemize @bullet -@item All tasks are non-floating point. - -@item All tasks are created as local objects. - -@item No timeouts are used on blocking directives. - -@item All tasks wait for objects in FIFO order. - -@end itemize - -In addition, no user extensions are configured. - - -@node Timing Specification What is not measured?, Timing Specification Terminology, Timing Specification What is measured?, Timing Specification Methodology - -@subsection What is not measured? - -The times presented in this document are not intended -to represent best or worst case times, nor are all directives -included. For example, no times are provided for the initialize -executive and fatal_error_occurred directives. Other than the -exceptions detailed in the Determinancy section, all directives -will execute in the fixed length of time given. - -Other than entering and exiting an interrupt service -routine, all directives were executed from tasks and not from -interrupt service routines. Directives invoked from ISRs, when -allowable, will execute in slightly less time than when invoked -from a task because rescheduling is delayed until the interrupt -exits. - - -@node Timing Specification Terminology, MYBSP Timing Data, Timing Specification What is not measured?, Timing Specification Methodology - -@subsection Terminology - -The following is a list of phrases which are used to -distinguish individual execution paths of the directives taken -during the RTEMS performance analysis: - -@table @b -@item another task -The directive was performed -on a task other than the calling task. - -@item available -A task attempted to obtain a resource and -immediately acquired it. - -@item blocked task -The task operated upon by the -directive was blocked waiting for a resource. - -@item caller blocks -The requested resoure was not -immediately available and the calling task chose to wait. - -@item calling task -The task invoking the directive. - -@item messages flushed -One or more messages was flushed -from the message queue. - -@item no messages flushed -No messages were flushed from -the message queue. - -@item not available -A task attempted to obtain a resource -and could not immediately acquire it. - -@item no reschedule -The directive did not require a -rescheduling operation. - -@item NO_WAIT -A resource was not available and the -calling task chose to return immediately via the NO_WAIT option -with an error. - -@item obtain current -The current value of something was -requested by the calling task. - -@item preempts caller -The release of a resource caused a -task of higher priority than the calling to be readied and it -became the executing task. - -@item ready task -The task operated upon by the directive -was in the ready state. - -@item reschedule -The actions of the directive -necessitated a rescheduling operation. - -@item returns to caller -The directive succeeded and -immediately returned to the calling task. - -@item returns to interrupted task -The instructions -executed immediately following this interrupt will be in the -interrupted task. - -@item returns to nested interrupt -The instructions -executed immediately following this interrupt will be in a -previously interrupted ISR. - -@item returns to preempting task -The instructions -executed immediately following this interrupt or signal handler -will be in a task other than the interrupted task. - -@item signal to self -The signal set was sent to the -calling task and signal processing was enabled. - -@item suspended task -The task operated upon by the -directive was in the suspended state. - -@item task readied -The release of a resource caused a -task of lower or equal priority to be readied and the calling -task remained the executing task. - -@item yield -The act of attempting to voluntarily release -the CPU. - -@end table - - -- cgit v1.2.3