source: rtems/doc/supplements/arm/timing.texi @ 8d7393a

4.104.114.84.95
Last change on this file since 8d7393a was 8d7393a, checked in by Joel Sherrill <joel.sherrill@…>, on Jul 30, 2002 at 9:43:53 PM

2002-07-30 Joel Sherrill <joel@…>

  • BSP_TIMES, ChangeLog?, Makefile.am, arm.texi, bsp.t, callconv.t, cpumodel.t, cputable.t, fatalerr.t, intr_NOTIMES.t, memmodel.t, preface.texi, stamp-vti, timeBSP.t, timing.texi, version.texi, wksheets.texi: New files as ARM supplement initial version added.
  • Property mode set to 100644
File size: 17.0 KB
Line 
1@c
2@c  COPYRIGHT (c) 1988-2002.
3@c  On-Line Applications Research Corporation (OAR).
4@c  All rights reserved.
5@c
6@c  $Id$
7@c
8
9
10@node Timing Specification, Timing Specification Introduction, Memory Requirements RTEMS RAM Workspace Worksheet, Top
11
12@chapter Timing Specification
13@ifinfo
14@menu
15* Timing Specification Introduction::
16* Timing Specification Philosophy::
17* Timing Specification Methodology::
18@end menu
19@end ifinfo
20
21
22@node Timing Specification Introduction, Timing Specification Philosophy, Timing Specification, Timing Specification
23
24@section Introduction
25
26This chapter provides information pertaining to the
27measurement of the performance of RTEMS, the methods of
28gathering the timing data, and the usefulness of the data.  Also
29discussed are other time critical aspects of RTEMS that affect
30an applications design and ultimate throughput.  These aspects
31include determinancy, interrupt latency and context switch times.
32
33
34@node Timing Specification Philosophy, Timing Specification Determinancy, Timing Specification Introduction, Timing Specification
35
36@section Philosophy
37@ifinfo
38@menu
39* Timing Specification Determinancy::
40* Timing Specification Interrupt Latency::
41* Timing Specification Context Switch Time::
42* Timing Specification Directive Times::
43@end menu
44@end ifinfo
45
46Benchmarks are commonly used to evaluate the
47performance of software and hardware.  Benchmarks can be an
48effective tool when comparing systems.  Unfortunately,
49benchmarks can also be manipulated to justify virtually any
50claim.  Benchmarks of real-time executives are difficult to
51evaluate for a variety of reasons.  Executives vary in the
52robustness of features and options provided.  Even when
53executives compare favorably in functionality, it is quite
54likely that different methodologies were used to obtain the
55timing data.  Another problem is that some executives provide
56times for only a small subset of directives,  This is typically
57justified by claiming that these are the only time-critical
58directives.  The performance of some executives is also very
59sensitive to the number of objects in the system.  To obtain any
60measure of usefulness, the performance information provided for
61an executive should address each of these issues.
62
63When evaluating the performance of a real-time
64executive, one typically considers the following areas:
65determinancy, directive times, worst case interrupt latency, and
66context switch time.  Unfortunately, these areas do not have
67standard measurement methodologies.  This allows vendors to
68manipulate the results such that their product is favorably
69represented.  We have attempted to provide useful and meaningful
70timing information for RTEMS.  To insure the usefulness of our
71data, the methodology and definitions used to obtain and
72describe the data are also documented.
73
74
75@node Timing Specification Determinancy, Timing Specification Interrupt Latency, Timing Specification Philosophy, Timing Specification Philosophy
76
77@subsection Determinancy
78
79The correctness of data in a real-time system must
80always be judged by its timeliness.  In many real-time systems,
81obtaining the correct answer does not necessarily solve the
82problem.  For example, in a nuclear reactor it is not enough to
83determine that the core is overheating.  This situation must be
84detected and acknowledged early enough that corrective action
85can be taken and a meltdown avoided.
86
87Consequently, a system designer must be able to
88predict the worst-case behavior of the application running under
89the selected executive.  In this light, it is important that a
90real-time system perform consistently regardless of the number
91of tasks, semaphores, or other resources allocated.  An
92important design goal of a real-time executive is that all
93internal algorithms be fixed-cost.  Unfortunately, this goal is
94difficult to completely meet without sacrificing the robustness
95of the executive's feature set.
96
97Many executives use the term deterministic to mean
98that the execution times of their services can be predicted.
99However, they often provide formulas to modify execution times
100based upon the number of objects in the system.  This usage is
101in sharp contrast to the notion of deterministic meaning fixed
102cost.
103
104Almost all RTEMS directives execute in a fixed amount
105of time regardless of the number of objects present in the
106system.  The primary exception occurs when a task blocks while
107acquiring a resource and specifies a non-zero timeout interval.
108
109Other exceptions are message queue broadcast,
110obtaining a variable length memory block, object name to ID
111translation, and deleting a resource upon which tasks are
112waiting.  In addition, the time required to service a clock tick
113interrupt is based upon the number of timeouts and other
114"events" which must be processed at that tick.  This second
115group is composed primarily of capabilities which are inherently
116non-deterministic but are infrequently used in time critical
117situations.  The major exception is that of servicing a clock
118tick.  However, most applications have a very small number of
119timeouts which expire at exactly the same millisecond (usually
120none, but occasionally two or three).
121
122
123@node Timing Specification Interrupt Latency, Timing Specification Context Switch Time, Timing Specification Determinancy, Timing Specification Philosophy
124
125@subsection Interrupt Latency
126
127Interrupt latency is the delay between the CPU's
128receipt of an interrupt request and the execution of the first
129application-specific instruction in an interrupt service
130routine.  Interrupts are a critical component of most real-time
131applications and it is critical that they be acted upon as
132quickly as possible.
133
134Knowledge of the worst case interrupt latency of an
135executive aids the application designer in determining the
136maximum period of time between the generation of an interrupt
137and an interrupt handler responding to that interrupt.  The
138interrupt latency of an system is the greater of the executive's
139and the applications's interrupt latency.  If the application
140disables interrupts longer than the executive, then the
141application's interrupt latency is the system's worst case
142interrupt disable period.
143
144The worst case interrupt latency for a real-time
145executive is based upon the following components:
146
147@itemize @bullet
148@item the longest period of time interrupts are disabled
149by the executive,
150
151@item the overhead required by the executive at the
152beginning of each ISR,
153
154@item the time required for the CPU to vector the
155interrupt, and
156
157@item for some microprocessors, the length of the longest
158instruction.
159@end itemize
160
161The first component is irrelevant if an interrupt
162occurs when interrupts are enabled, although it must be included
163in a worst case analysis.  The third and fourth components are
164particular to a CPU implementation and are not dependent on the
165executive.  The fourth component is ignored by this document
166because most applications use only a subset of a
167microprocessor's instruction set.  Because of this the longest
168instruction actually executed is application dependent.  The
169worst case interrupt latency of an executive is typically
170defined as the sum of components (1) and (2).  The second
171component includes the time necessry for RTEMS to save registers
172and vector to the user-defined handler.  RTEMS includes the
173third component, the time required for the CPU to vector the
174interrupt, because it is a required part of any interrupt.
175
176Many executives report the maximum interrupt disable
177period as their interrupt latency and ignore the other
178components.  This results in very low worst-case interrupt
179latency times which are not indicative of actual application
180performance.  The definition used by RTEMS results in a higher
181interrupt latency being reported, but accurately reflects the
182longest delay between the CPU's receipt of an interrupt request
183and the execution of the first application-specific instruction
184in an interrupt service routine.
185
186The actual interrupt latency times are reported in
187the Timing Data chapter of this supplement.
188
189
190@node Timing Specification Context Switch Time, Timing Specification Directive Times, Timing Specification Interrupt Latency, Timing Specification Philosophy
191
192@subsection Context Switch Time
193
194An RTEMS context switch is defined as the act of
195taking the CPU from the currently executing task and giving it
196to another task.  This process involves the following components:
197
198@itemize @bullet
199@item Saving the hardware state of the current task.
200
201@item Optionally, invoking the TASK_SWITCH user extension.
202
203@item Restoring the hardware state of the new task.
204@end itemize
205
206RTEMS defines the hardware state of a task to include
207the CPU's data registers, address registers, and, optionally,
208floating point registers.
209
210Context switch time is often touted as a performance
211measure of real-time executives.  However, a context switch is
212performed as part of a directive's actions and should be viewed
213as such when designing an application.  For example, if a task
214is unable to acquire a semaphore and blocks, a context switch is
215required to transfer control from the blocking task to a new
216task.  From the application's perspective, the context switch is
217a direct result of not acquiring the semaphore.  In this light,
218the context switch time is no more relevant than the performance
219of any other of the executive's subroutines which are not
220directly accessible by the application.
221
222In spite of the inappropriateness of using the
223context switch time as a performance metric, RTEMS context
224switch times for floating point and non-floating points tasks
225are provided for comparison purposes.  Of the executives which
226actually support floating point operations, many do not report
227context switch times for floating point context switch time.
228This results in a reported context switch time which is
229meaningless for an application with floating point tasks.
230
231The actual context switch times are reported in the
232Timing Data chapter of this supplement.
233
234
235@node Timing Specification Directive Times, Timing Specification Methodology, Timing Specification Context Switch Time, Timing Specification Philosophy
236
237@subsection Directive Times
238
239Directives are the application's interface to the
240executive, and as such their execution times are critical in
241determining the performance of the application.  For example, an
242application using a semaphore to protect a critical data
243structure should be aware of the time required to acquire and
244release a semaphore.  In addition, the application designer can
245utilize the directive execution times to evaluate the
246performance of different synchronization and communication
247mechanisms.
248
249The actual directive execution times are reported in
250the Timing Data chapter of this supplement.
251
252
253@node Timing Specification Methodology, Timing Specification Software Platform, Timing Specification Directive Times, Timing Specification
254
255@section Methodology
256@ifinfo
257@menu
258* Timing Specification Software Platform::
259* Timing Specification Hardware Platform::
260* Timing Specification What is measured?::
261* Timing Specification What is not measured?::
262* Timing Specification Terminology::
263@end menu
264@end ifinfo
265
266
267@node Timing Specification Software Platform, Timing Specification Hardware Platform, Timing Specification Methodology, Timing Specification Methodology
268
269@subsection Software Platform
270
271The RTEMS timing suite is written in C.  The overhead
272of passing arguments to RTEMS by C is not timed.  The times
273reported represent the amount of time from entering to exiting
274RTEMS.
275
276The tests are based upon one of two execution models:
277(1) single invocation times, and (2) average times of repeated
278invocations.  Single invocation times are provided for
279directives which cannot easily be invoked multiple times in the
280same scenario.  For example, the times reported for entering and
281exiting an interrupt service routine are single invocation
282times.  The second model is used for directives which can easily
283be invoked multiple times in the same scenario.  For example,
284the times reported for semaphore obtain and semaphore release
285are averages of multiple invocations.  At least 100 invocations
286are used to obtain the average.
287
288
289@node Timing Specification Hardware Platform, Timing Specification What is measured?, Timing Specification Software Platform, Timing Specification Methodology
290
291@subsection Hardware Platform
292
293Since RTEMS supports a variety of processors, the
294hardware platform used to gather the benchmark times must also
295vary.  Therefore, for each processor supported the hardware
296platform must be defined.  Each definition will include a brief
297description of the target hardware platform including the clock
298speed, memory wait states encountered, and any other pertinent
299information.  This definition may be found in the processor
300dependent timing data chapter within this supplement.
301
302
303@node Timing Specification What is measured?, Timing Specification What is not measured?, Timing Specification Hardware Platform, Timing Specification Methodology
304
305@subsection What is measured?
306
307An effort was made to provide execution times for a
308large portion of RTEMS.  Times were provided for most directives
309regardless of whether or not they are typically used in time
310critical code.  For example, execution times are provided for
311all object create and delete directives, even though these are
312typically part of application initialization.
313
314The times include all RTEMS actions necessary in a
315particular scenario.  For example, all times for blocking
316directives include the context switch necessary to transfer
317control to a new task.  Under no circumstances is it necessary
318to add context switch time to the reported times.
319
320The following list describes the objects created by
321the timing suite:
322
323@itemize @bullet
324@item All tasks are non-floating point.
325
326@item All tasks are created as local objects.
327
328@item No timeouts are used on blocking directives.
329
330@item All tasks wait for objects in FIFO order.
331
332@end itemize
333
334In addition, no user extensions are configured.
335
336
337@node Timing Specification What is not measured?, Timing Specification Terminology, Timing Specification What is measured?, Timing Specification Methodology
338
339@subsection What is not measured?
340
341The times presented in this document are not intended
342to represent best or worst case times, nor are all directives
343included.  For example, no times are provided for the initialize
344executive and fatal_error_occurred directives.  Other than the
345exceptions detailed in the Determinancy section, all directives
346will execute in the fixed length of time given.
347
348Other than entering and exiting an interrupt service
349routine, all directives were executed from tasks and not from
350interrupt service routines.  Directives invoked from ISRs, when
351allowable, will execute in slightly less time than when invoked
352from a task because rescheduling is delayed until the interrupt
353exits.
354
355
356@node Timing Specification Terminology, MYBSP Timing Data, Timing Specification What is not measured?, Timing Specification Methodology
357
358@subsection Terminology
359
360The following is a list of phrases which are used to
361distinguish individual execution paths of the directives taken
362during the RTEMS performance analysis:
363
364@table @b
365@item another task
366The directive was performed
367on a task other than the calling task.
368
369@item available
370A task attempted to obtain a resource and
371immediately acquired it.
372
373@item blocked task
374The task operated upon by the
375directive was blocked waiting for a resource.
376
377@item caller blocks
378The requested resoure was not
379immediately available and the calling task chose to wait.
380
381@item calling task
382The task invoking the directive.
383
384@item messages flushed
385One or more messages was flushed
386from the message queue.
387
388@item no messages flushed
389No messages were flushed from
390the message queue.
391
392@item not available
393A task attempted to obtain a resource
394and could not immediately acquire it.
395
396@item no reschedule
397The directive did not require a
398rescheduling operation.
399
400@item NO_WAIT
401A resource was not available and the
402calling task chose to return immediately via the NO_WAIT option
403with an error.
404
405@item obtain current
406The current value of something was
407requested by the calling task.
408
409@item preempts caller
410The release of a resource caused a
411task of higher priority than the calling to be readied and it
412became the executing task.
413
414@item ready task
415The task operated upon by the directive
416was in the ready state.
417
418@item reschedule
419The actions of the directive
420necessitated a rescheduling operation.
421
422@item returns to caller
423The directive succeeded and
424immediately returned to the calling task.
425
426@item returns to interrupted task
427The instructions
428executed immediately following this interrupt will be in the
429interrupted task.
430
431@item returns to nested interrupt
432The instructions
433executed immediately following this interrupt will be in a
434previously interrupted ISR.
435
436@item returns to preempting task
437The instructions
438executed immediately following this interrupt or signal handler
439will be in a task other than the interrupted task.
440
441@item signal to self
442The signal set was sent to the
443calling task and signal processing was enabled.
444
445@item suspended task
446The task operated upon by the
447directive was in the suspended state.
448
449@item task readied
450The release of a resource caused a
451task of lower or equal priority to be readied and the calling
452task remained the executing task.
453
454@item yield
455The act of attempting to voluntarily release
456the CPU.
457
458@end table
459
460
Note: See TracBrowser for help on using the repository browser.