Notes on RT scheduling policy.

NOTES.md

@@ -4,6 +4,35 @@ A collection of stuff that we noticed during development.
 Useful later on two write a project report and to go back
 in time to find out why certain decisions where made.
 
+## 14.06.2019 - Benchmark Settings/Real Time Execution on Linux
+
+Our set goal of this project is predictable execution times.
+To ensure this it would be perfect to run our benchmark in perfect
+isolation/in a perfectly predictable and controlled environment.
+A truly predictable environment is only possible on e.g. a fully
+real time os on a board that supports everything.
+As this is a lot work, we look at real time linux components,
+the preemt rt patch.
+
+We already execute our program with `chrt -f 99` to run it as a real
+time task. We still have seen quite big jumps in latency.
+This can be due to interrupts or other processes preemting our
+benchmark. We found [in this blog post](https://ambrevar.xyz/real-time/)
+about some more interesting details on real time processes.
+There is a variable `/proc/sys/kernel/sched_rt_runtime_us` to set the
+maximum time a real time process can run per second to ensure that
+a system does not freeze when running a RT process.
+When setting this to 1 second the RT processes are allowed to fully
+take over the system (we will do this for further tests, as first
+results show us that this drasticly improoves jitter).
+Further information on RT groups can be [found here](https://www.kernel.org/doc/Documentation/scheduler/sched-rt-group.txt).
+The RT patch of linux apparently allows the OS to preemt even
+most parts of interrupts, thus providing even more isolation
+(can be also found [in this blog post](https://ambrevar.xyz/real-time/)).
+
+We will further investigate this by looking at a book on RT Liunx.
+
+
 ## 14.06.2019 - Range Class
 
 For iterating on integers (e.g. from 0 to 10) a translation from