diff --git a/examples/timing_exam.rs b/examples/timing_exam.rs
index 535e44125a7b2cca52668f28e474cdb1a94f8118..cd57eba23b2e26cddd6281190ab9cc7ac47a7987 100644
--- a/examples/timing_exam.rs
+++ b/examples/timing_exam.rs
@@ -417,5 +417,28 @@ In this real life example we have some longer responsetimes which means it doesn
 // - How would an ideal tool for static analysis of RTIC models look like.
 //
 // [Your ideas and reflections here]
+/*
+- RTIC and scheduling overhead
+The re-scheduling OH in RTIC is ~180 cycles when running a mix of lower and higher prio tasks.
+This is very low and is a very fair tradeof for what you get.
+
+If you run the re-scheduler on a timestamp when there is no other tasks, you will see that the re-scheduler will finish much bellow 180 cycles_
+The differnce in excection time for this procedure can make it hard to estimete WCET for the task.
+The question is if it is possible to make this a constant time operation? And in that case, how?
+I don't have the answers for this but it's an interesting thought.
+
+- Coupling in between theoretical model and measurements
+The OH of the context switching, preemption check and re-schedueling will give you a differense from the theoretical values deffined_
+
+Basically the formula for the actual response time becomes_
+R(t) = I(t) + B(t) + C(t) + OH(t)
+
+- How would an ideal tool for static analysis of RTIC models look like.
+It's a bit hard to make a educated guess without having in-depth knowledge about how the preemption check is implemented.
+But my thoughts are that you would measure the WCET of the preemption check and re-scheduling (when using multiple tasks) and combine it with the OH for the context switching.
+This would give you a static value that you can add to your response time during analysis.
+
+These values would then be combined with the WCET of the User code to give you the WCET of the entire task.
+*/
 //
 // Commit your thoughts, we will discuss further when we meet.