From 672fb83fa475643b6cbd4f3cdd0b799aa17e8b32 Mon Sep 17 00:00:00 2001 From: gdisirio Date: Fri, 23 Jan 2009 19:25:13 +0000 Subject: git-svn-id: svn://svn.code.sf.net/p/chibios/svn/trunk@670 35acf78f-673a-0410-8e92-d51de3d6d3f4 --- docs/src/jitter.dox | 68 +++++++++++++++++++++++++---------------------------- 1 file changed, 32 insertions(+), 36 deletions(-) (limited to 'docs/src') diff --git a/docs/src/jitter.dox b/docs/src/jitter.dox index 1b4220dd4..da3251369 100644 --- a/docs/src/jitter.dox +++ b/docs/src/jitter.dox @@ -4,13 +4,25 @@ * 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 + * system. A good place to start is this * Wikipedia article. * + *

Interrupt handlers execution time

+ * 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. + * *

Interrupt Response Time

- * This is the time from an interrupt event and the execution of the handler - * code. + * 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 { @@ -20,28 +32,27 @@ int [label="Interrupt"]; busy [label="Busy"]; served [label="Interrupt\nServed"]; - int -> served [label="Not Busy"]; + int -> served [label="Not Busy (minimum latency)"]; int -> busy [label="Not Ready"]; - busy -> busy [label="Still Busy\n(jitter)"]; + busy -> busy [label="Still Busy\n(added latency)"]; busy -> served [label="Finally Ready"]; * @enddot * - *

Jitter Sources

* In this scenario the jitter (busy state) is represented by the sum of: - * - Higher or equal priority interrupt sources execution time combined. + * - 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 sources. This value is zero + * - 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. * *

Threads Flyback Time

- * 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. + * 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 { @@ -51,13 +62,12 @@ served [label="Interrupt\nServed"]; busy [label="Busy"]; thread [label="Thread\nAwakened"]; - served -> busy [label="Not Highest Priority"]; - busy -> busy [label="Other Threads\n(jitter)"]; + 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"]; + served -> thread [label="Highest Priority (minimum latency)"]; * @enddot * - *

Jitter Sources

* 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. @@ -66,28 +76,14 @@ * For each of the previously described jitter sources there are possible * mitigation actions. * - *

Hardware interrupts latency

- * This parameter is pretty much fixed and a characteristic of the system. - * Possible actions include higher clock speeds or switch to an hardware - * architecture more efficient at interrupt handling, as example, the - * ARM Cortex-M3 core present in the STM32 family is very efficient at that. - * - *

Interrupts service time

- * 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 - * 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. - * + *

Interrupt handlers optimization

* An obvious mitigation action is to optimize the interrupt handler code as * much as possible for speed.
* Complex actions should never be performed in interrupt handlers. * An handler should serve the interrupt and wakeup a dedicated thread in order * to handle the bulk of the work.
* Another possible mitigation action is to evaluate if a specific interrupt - * handler really needs to "speak" with the OS, if the handler uses full + * 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.
* *

Kernel lock zones

@@ -95,7 +91,7 @@ * (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 both using adequate data structure, algorithms and good coding + * kernel by using adequate data structures, algorithms and coding * practices.
* 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 @@ -104,9 +100,9 @@ * time but others may have linear execution time or be even more complex. * *

Higher priority threads activity

- * 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.
+ * 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.
* 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.
-- cgit v1.2.3