summaryrefslogtreecommitdiffstats
path: root/doc/supplements/arm/timing.texi
blob: 302a1391a8167be73660ea3449145727de96d9f7 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
@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