From 819c02b8391e3cadcbe814c84c5c5f366ae41e03 Mon Sep 17 00:00:00 2001
From: gdisirio <gdisirio@35acf78f-673a-0410-8e92-d51de3d6d3f4>
Date: Fri, 23 Jan 2009 16:18:13 +0000
Subject: git-svn-id: svn://svn.code.sf.net/p/chibios/svn/trunk@669
 35acf78f-673a-0410-8e92-d51de3d6d3f4

---
 docs/src/jitter.dox | 81 ++++++++++++++++++++++++++++++++++++++++-------------
 1 file changed, 61 insertions(+), 20 deletions(-)

(limited to 'docs/src')

diff --git a/docs/src/jitter.dox b/docs/src/jitter.dox
index 4bbedd7b7..1b4220dd4 100644
--- a/docs/src/jitter.dox
+++ b/docs/src/jitter.dox
@@ -8,15 +8,61 @@
  * A good place to start is this
  * <a href="http://en.wikipedia.org/wiki/Jitter">Wikipedia article</a>.
  *
- * <h2>Jitter Sources</h2>
- * Under ChibiOS/RT (or any other similar RTOS) there are several possible
- * jitter sources:
- * -# Hardware interrupts latency.
- * -# Interrupts service time and priority.
- * -# Kernel lock zones.
- * -# Higher priority threads activity.
+ * <h2>Interrupt Response Time</h2>
+ * This is the time from an interrupt event and the execution of the handler
+ * code.
  *
- * <h2>Jitter mitigation countermeasures</h2>
+ * @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"];
+      int -> busy [label="Not Ready"];
+      busy -> busy [label="Still Busy\n(jitter)"];
+      busy -> served [label="Finally Ready"];
+ * @enddot
+ *
+ * <h3>Jitter Sources</h3>
+ * In this scenario the jitter (busy state) is represented by the sum of:
+ * - Higher or equal priority interrupt sources 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 sources. 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 from an event, as example an interrupt, and the execution
+ * of a thread supposed to handle the event. 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="Other Threads\n(jitter)"];
+      busy -> thread [label="Highest Priority"];
+      served -> thread [label="Highest Priority"];
+ * @enddot
+ *
+ * <h3>Jitter Sources</h3>
+ * 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.
  *
@@ -26,7 +72,7 @@
  * architecture more efficient at interrupt handling, as example, the
  * ARM Cortex-M3 core present in the STM32 family is very efficient at that.
  *
- * <h3>Interrupts service time and priority</h3>
+ * <h3>Interrupts service time</h3>
  * This is the execution time of interrupt handlers, this time includes:
  * - Fixed handler overhead, as example registers stacking/unstacking.
  * - Interrupt specific service time, as example, in a serial driver, this is
@@ -41,16 +87,8 @@
  * An handler should 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 need to "speak" with the OS, if the handler uses full
+ * handler really needs to "speak" with the OS, if the handler uses full
  * stand-alone code then it is possible to remove the OS related overhead.<br>
- * On some architecture it is also possible to give to interrupt sources a
- * greater hardware priority than the kernel and not be affected by the
- * jitter introduced by OS itself (see next subsection).<br>
- * As example, in the ARM port, FIQ sources are not affected by the
- * kernel-generated jitter. The Cortex-M3 port is even better thanks to its
- * hardware-assisted interrupt architecture allowing handlers preemption,
- * late arriving, tail chaining etc. See the notes about the various
- * @ref Ports.
  *
  * <h3>Kernel lock zones</h3>
  * The OS kernel protects some critical internal data structure by disabling
@@ -67,12 +105,15 @@
  *
  * <h3>Higher priority threads activity</h3>
  * At thread level the response time is affected by the interrupt-related
- * jitter as seen in the previous subsections but also by the activity of the
- * higher priority threads and contention on protected resources.<br>
+ * jitter, as seen in the previous subsections, but also 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.
  */
 /** @} */
-- 
cgit v1.2.3