diff --git a/examples/timing_resources.rs b/examples/timing_resources.rs
index b55f2ee18c1c512d6ed1b05da8557e6cb9c5ca85..ecd1f96784869709ccfa89dcba4483a71fccc3a0 100644
--- a/examples/timing_resources.rs
+++ b/examples/timing_resources.rs
@@ -269,13 +269,18 @@ const APP: () = {
 //
 // You find a comparison to a typical threaded counterpart `freeRTOS` in Table 1.
 //
-// Give a rough estimate based on this info how long the complete task `uart1`,
+// Give a rough estimate based on this info how long the complete task `exti1`,
 // would take to execute if written in FreeRTOS. (Include the context switch, to higher
 // priority task, the mutex lock/unlock in both "threads".)
 //
 // Motivate your answer (not just a number).
 //
 // [Your answer here]
+// Job latency and job overhead for both exti0 and exti2: 2* (650 + 1522)
+// Lock and unlock in exti1 260 + 170
+// Critical section in the lock 40
+// Memory job 462 * 2 (It changes the resources 2 times, one time in exti0 and exti1 each.)
+// Result: 2* (650 + 1522)+260 + 170+40+462 * 2 = 5738 cycles
 //
 // Notice, the Rust implementation is significantly faster than the C code version
 // of Real-Time For the Masses back in 2013.
@@ -283,6 +288,10 @@ const APP: () = {
 // Why do you think RTIC + Rust + LLVM can do a better job than hand written
 // C code + Macros + gcc?
 //
-// (Hint, what possible optimization can safely be applied.)
+// (Hint, what possible optimization can safely be applied by RTIC + Rust + LLVM.)
 //
 // [Your answer here]
+// Rust with RTIC does not have threads which means it is not switching task as often as in C.
+// When there are fewer switches between tasks, the need for locks is less.
+// There are no need for memory managment in rust compared to C.
+//