diff options
Diffstat (limited to 'docs/src/jitter.dox')
| -rw-r--r-- | docs/src/jitter.dox | 135 |
1 files changed, 0 insertions, 135 deletions
diff --git a/docs/src/jitter.dox b/docs/src/jitter.dox deleted file mode 100644 index 759425b4e..000000000 --- a/docs/src/jitter.dox +++ /dev/null @@ -1,135 +0,0 @@ -/*
- ChibiOS/RT - Copyright (C) 2006,2007,2008,2009,2010 Giovanni Di Sirio.
-
- This file is part of ChibiOS/RT.
-
- ChibiOS/RT is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 3 of the License, or
- (at your option) any later version.
-
- ChibiOS/RT is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
-
- You should have received a copy of the GNU General Public License
- along with this program. If not, see <http://www.gnu.org/licenses/>.
-*/
-
-/**
- * @page article_jitter Response Time and Jitter
- * Response time jitter is one of the most sneaky source of problems when
- * designing a real time system. When using a RTOS like ChibiOS/RT one must
- * be aware of what the jitter is and how it can affect the performance of the
- * system. A good place to start is this
- * <a href="http://en.wikipedia.org/wiki/Jitter" target="_blank">Wikipedia
- * article</a>.
- *
- * <h2>Interrupt handlers execution time</h2>
- * The total execution time of an interrupt handler includes:
- * - Hardware interrupts latency, this parameter is pretty much fixed and
- * characteristic of the system.
- * - Fixed handler overhead, as example registers stacking/unstacking.
- * - Interrupt specific handler code execution time, as example, in a serial
- * driver, this is the time used by the handler to transfer data from/to
- * the UART.
- * - OS overhead. Any operating system requires to run some extra code
- * in interrupt handlers in order to handle correct preemption and Context
- * Switching.
- * .
- * <h2>Interrupt Response Time</h2>
- * The Interrupt Response Time is the time from an interrupt event and the
- * execution of the handler code. Unfortunately this time is not constant
- * in most cases, see the following graph:
- *
- * @dot
- digraph example {
- rankdir="LR";
- node [shape=circle, fontname=Helvetica, fontsize=8, fixedsize="true", width="0.75", height="0.75"];
- edge [fontname=Helvetica, fontsize=8];
- int [label="Interrupt"];
- busy [label="Busy"];
- served [label="Interrupt\nServed"];
- int -> served [label="Not Busy (minimum latency)"];
- int -> busy [label="Not Ready"];
- busy -> busy [label="Still Busy\n(added latency)"];
- busy -> served [label="Finally Ready"];
- }
- * @enddot
- *
- * In this scenario the jitter (busy state) is represented by the sum of:
- * - Higher or equal priority interrupt handlers execution time combined.
- * This time can go from zero to the maximum randomly. This value can be
- * guaranteed to be zero only if the interrupt has the highest priority in
- * the system.
- * - Highest execution time among lower priority handlers. This value is zero
- * on those architectures (Cortex-M3 as example) where interrupt handlers
- * can be preempted by higher priority sources.
- * - Longest time in a kernel lock zone that can delay interrupt servicing.
- * This value is zero for fast interrupt sources, see @ref system_states.
- * .
- * <h2>Threads Flyback Time</h2>
- * This is the time between an event, as example an interrupt, and the
- * execution of the thread that will process it. Imagine the following
- * graph as the continuation of the previous one.
- *
- * @dot
- digraph example {
- rankdir="LR";
- node [shape=circle, fontname=Helvetica, fontsize=8, fixedsize="true", width="0.75", height="0.75"];
- edge [fontname=Helvetica, fontsize=8];
- served [label="Interrupt\nServed"];
- busy [label="Busy"];
- thread [label="Thread\nAwakened"];
- served -> busy [label="Not highest Priority"];
- busy -> busy [label="Higher priority Threads\n(added latency)"];
- busy -> thread [label="Highest Priority"];
- served -> thread [label="Highest Priority (minimum latency)"];
- }
- * @enddot
- *
- * In this scenario all the jitter sources previously discussed are also
- * present and there is the added jitter caused by the activity of the
- * higher priority threads.
- *
- * <h2>Jitter Mitigation</h2>
- * For each of the previously described jitter sources there are possible
- * mitigation actions.
- *
- * <h3>Interrupt handlers optimization</h3>
- * An obvious mitigation action is to optimize the interrupt handler code as
- * much as possible for speed.<br>
- * Complex actions should never be performed in interrupt handlers.
- * An handler should just serve the interrupt and wakeup a dedicated thread in
- * order to handle the bulk of the work.<br>
- * Another possible mitigation action is to evaluate if a specific interrupt
- * handler really needs to interact with the OS, if the handler uses full
- * stand-alone code then it is possible to remove the OS related overhead.<br>
- *
- * <h3>Kernel lock zones</h3>
- * The OS kernel protects some critical internal data structure by disabling
- * (fully in simple architecture, to some extent in more advanced
- * microcontrollers) the interrupt sources. Because of this the kernel itself
- * is a jitter cause, a good OS design minimizes the jitter generated by the
- * kernel by using adequate data structures, algorithms and coding
- * practices.<br>
- * A good OS design is not the whole story, some OS primitives may generate
- * more or less jitter depending on the system state, as example the maximum
- * number of threads on a certain queue, the maximum number of nested mutexes
- * and so on. Some algorithms employed internally can have constant execution
- * time but others may have linear execution time or be even more complex.
- *
- * <h3>Higher priority threads activity</h3>
- * At thread level, the response time is affected by the interrupt-related
- * jitter but mainly by the activity of the higher priority threads and
- * contention on protected resources.<br>
- * It is possible to improve the system overall response time and reduce jitter
- * by carefully assigning priorities to the various threads and carefully
- * designing mutual exclusion zones.<br>
- * The use of the proper synchronization mechanism (semaphores, mutexes, events,
- * messages and so on) also helps to improve the overall system performance.
- * The use of the Priority Inheritance algorithm implemented in the mutexes
- * subsystem can improve the overall response time and reduce jitter but it is
- * not a magic wand, a proper system design comes first.
- */
|