source: rtems/doc/supplements/mips64orion/timeBSP.t @ 6449498

4.104.114.84.95
Last change on this file since 6449498 was 6449498, checked in by Joel Sherrill <joel.sherrill@…>, on Jan 17, 2002 at 9:47:47 PM

2001-01-17 Joel Sherrill <joel@…>

  • SUPPORT, LICENSE: New files.
  • Numerous files touched as part of merging the 4.5 branch onto the mainline development trunk and ensuring that the script that cuts snapshots and releases works on the documentation.
  • Property mode set to 100644
File size: 4.5 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@include common/timemac.texi
10@tex
11\global\advance \smallskipamount by -4pt
12@end tex
13
14@chapter BSP_FOR_TIMES Timing Data
15
16@section Introduction
17
18The timing data for the XXX version of RTEMS is
19provided along with the target dependent aspects concerning the
20gathering of the timing data.  The hardware platform used to
21gather the times is described to give the reader a better
22understanding of each directive time provided.  Also, provided
23is a description of the interrupt latency and the context switch
24times as they pertain to the XXX version of RTEMS.
25
26@section Hardware Platform
27
28All times reported except for the maximum period
29interrupts are disabled by RTEMS were measured using a Motorola
30BSP_FOR_TIMES CPU board.  The BSP_FOR_TIMES is a 20Mhz board with one wait
31state dynamic memory and a XXX numeric coprocessor.  The
32Zilog 8036 countdown timer on this board was used to measure
33elapsed time with a one-half microsecond resolution.  All
34sources of hardware interrupts were disabled, although the
35interrupt level of the XXX allows all interrupts.
36
37The maximum period interrupts are disabled was
38measured by summing the number of CPU cycles required by each
39assembly language instruction executed while interrupts were
40disabled.  The worst case times of the XXX microprocessor
41were used for each instruction.  Zero wait state memory was
42assumed.  The total CPU cycles executed with interrupts
43disabled, including the instructions to disable and enable
44interrupts, was divided by 20 to simulate a 20Mhz XXX.  It
45should be noted that the worst case instruction times for the
46XXX assume that the internal cache is disabled and that no
47instructions overlap.
48
49@section Interrupt Latency
50
51The maximum period with interrupts disabled within
52RTEMS is less than RTEMS_MAXIMUM_DISABLE_PERIOD
53microseconds including the instructions
54which disable and re-enable interrupts.  The time required for
55the XXX to vector an interrupt and for the RTEMS entry
56overhead before invoking the user's interrupt handler are a
57total of RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK
58microseconds.  These combine to yield a worst case
59interrupt latency of less than
60RTEMS_MAXIMUM_DISABLE_PERIOD + RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK
61microseconds at 20Mhz.  [NOTE:  The maximum period with interrupts
62disabled was last determined for Release
63RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
64
65It should be noted again that the maximum period with
66interrupts disabled within RTEMS is hand-timed and based upon
67worst case (i.e. CPU cache disabled and no instruction overlap)
68times for a 20Mhz XXX.  The interrupt vector and entry
69overhead time was generated on an BSP_FOR_TIMES benchmark platform
70using the Multiprocessing Communications registers to generate
71as the interrupt source.
72
73@section Context Switch
74
75The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS
76microseconds on the BSP_FOR_TIMES benchmark platform when no floating
77point context is saved or restored.  Additional execution time
78is required when a TASK_SWITCH user extension is configured.
79The use of the TASK_SWITCH extension is application dependent.
80Thus, its execution time is not considered part of the raw
81context switch time.
82
83Since RTEMS was designed specifically for embedded
84missile applications which are floating point intensive, the
85executive is optimized to avoid unnecessarily saving and
86restoring the state of the numeric coprocessor.  The state of
87the numeric coprocessor is only saved when an FLOATING_POINT
88task is dispatched and that task was not the last task to
89utilize the coprocessor.  In a system with only one
90FLOATING_POINT task, the state of the numeric coprocessor will
91never be saved or restored.  When the first FLOATING_POINT task
92is dispatched, RTEMS does not need to save the current state of
93the numeric coprocessor.
94
95The exact amount of time required to save and restore
96floating point context is dependent on whether an XXX or
97XXX is being used as well as the state of the numeric
98coprocessor.  These numeric coprocessors define three operating
99states: initialized, idle, and busy.  RTEMS places the
100coprocessor in the initialized state when a task is started or
101restarted.  Once the task has utilized the coprocessor, it is in
102the idle state when floating point instructions are not
103executing and the busy state when floating point instructions
104are executing.  The state of the coprocessor is task specific.
105
106The following table summarizes the context switch
107times for the BSP_FOR_TIMES benchmark platform:
108
Note: See TracBrowser for help on using the repository browser.