timing_exam 3)

.vscode/tasks.json

@@ -23,12 +23,12 @@
         },
         {
             "type": "cargo",
-            "command": "build --example ${fileBasenameNoExtension} --release --features nightly",
+            "command": "build --example ${fileBasenameNoExtension} --release --features nightly",a
             "problemMatcher": [
                 "$rustc"
             ],
             "group": "build",
             "label": "cargo build --examples --release --nightly"
-        }
+        },
     ]
 }
\ No newline at end of file

examples/timing_exam.rs

@@ -219,6 +219,8 @@ const APP: () = {
 //
 // Commit your repository once you are done with the instrumentation.
 //
+//
+//
 // 3) Code Testing:
 //
 // Once the instrumentation code is in place, its finally time
@@ -257,62 +259,109 @@ const APP: () = {
 // 3A) Why is there an offset 50240 (instead of 50000)?
 //
 // [Your answer here]
+// The difference is there because there is some overhead to start executing the task.
+// CYCCNT = 50245
+//
 //
 // 3B) Why is the calculated response time larger than the
 // delays you inserted to simulate workload?
 //
 // [Your answer here]
+// The few extra cycles comes from the overhead of starting the process and from scheduling the next occurrent of
+// the task.
+// response_time = 30321 
+//
 //
 // 3C) Why is the second arrival of `t3` further delayed?
 //
 // [Your answer here]
+// Both T1 and T3 are to start at time 100 000 cycles and thus there is some extra overhead from deciding
+// on with one should execute.
+// CYCCNT = 100290
 // Hint, think about what happens at time 100_000, what tasks
 // are set to `arrive` at that point compared to time 50_000.
 //
+//
 // 3D) What is the scheduled time for task `t1` (130595 is the
 // measured time according to CYCYCNT).
 //
 // [Your answer here]
+// T1 is scheduled to start at time 100 000 cycles.
+// CYCCNT = 130557
+//
 //
 // Why is the measured value much higher than the scheduled time?
 //
 // [Your answer here]
+// Because T3 is also scheduled for time 100 000 cycles and has a higher priority. Thus T3 is
+// executed first and takes about 30 000 cycles. After T3 is done T1 will execute and that is why
+// the measured value is about 30 000 cycles more then the scheduled one.
+//
+//
 //
 // Now you can continue until you get a first update of `T1_MAX_RP`.
 //
 // What is the first update of `T1_MAX_RP`?
 //
 // [Your answer here]
+// T1_MAX_RP = 40645
+//
 //
 // Explain the obtained value in terms of:
 // Execution time, blocking and preemptions
 // (that occurred for this task instance).
 //
 // [Your answer here]
+// The execution time of T1 is about 10 000 cycles.
+// The blocking time of T1 is 0 cycles because there are no lower priority tasks that can hold a
+// resource that T1 needs.
+// The preemption time is about 30 000 cycles because task T3 was scheduled at the same time and has
+// a higher priority. Thus the execution time of T3 is equal to the preemption time in this case.
+// response time = execution time + blocking time + preemption time 
+//               = 10 000 + 0 + 30 000 = 40 000
+//
 //
 // Now continue until you get a first timing measurement for `T2_MAX_RP`.
 //
 // What is the first update of `T2_MAX_RP`?
 //
 // [Your answer here]
+// T2_MAX_RP = 91062
+//
 //
 // Now continue until you get a second timing measurement for `T1_MAX_RP`.
 //
 // What is the second update of `T3_MAX_RP`?
 //
 // [Your answer here]
+// T1_MAX_RP = 131766
+//
 //
 // Now you should have ended up in a deadline miss right!!!!
 //
 // Why did this happen?
 //
 // [Your answer here]
+// It looks like all three tasks were scheduled for the same time and thus T3 ran 3 times and T2
+// ran 1 time and T1 ran 1 time.
+// This gives the response time:
+// 3 * 30 + 1 * 30 + 1 * 10 = 130 sec = ~130 000 cycles.
+//
 //
 // Compare that to the result obtained from your analysis tool.
 //
 // Do they differ, if so why?
 //
 // [Your answer here]
+// Yes, they differ. My says the response time is R(T1) = 100 sec and not 130 sec.
+// 
+// The reason why they differ is because my tool calculates that T3 will only execute 2 time and not
+// 3 times like it did. The tool doesn't account for any overhead thus when doing the calculation
+// for how many times T3 can preempt T1 it isn't totally accurate in the special case when Bp(t)
+// is a multiple of A(h) in the equation: 
+// I(t) = sum(C(h) * ceiling( Bp(t) / A(h))), P(h) > P(t)
+//
+//
 //
 // Commit your repository once you completed this part.
 //