Merge pull request #9 from tony2guo/fix-typo

Fix typo

Author: 2b-t

doc/RealTimeLinux.md

@@ -6,7 +6,7 @@ Author: [Tobit Flatscher](https://github.com/2b-t) (August 2021 - March 2023)
 
 ## 1. Introduction
 
-Task scheduling on standard operating systems is to some extend non-deterministic, meaning one cannot give a guaranteed - mathematically provable - upper bound for the execution time. This is somewhat desired for most applications as this increases throughput but for any real-time system one wants to be able to give such an upper bound that a given task will never exceed. Rather than executing something as fast as possible the aim is to **execute tasks consistently**, in a deterministic fashion: What matters is the **worst case latency** rather than the average latency. There are different approaches for rendering (Linux) operating systems real-time capable. These will be discussed in the next section. A introduction to real-time operating systems can be found [here](https://www.youtube.com/watch?v=4UY7hQjEW34) and [here](https://www.youtube.com/watch?v=w3yT8zJe0Uw). [This NASA conference paper](https://ntrs.nasa.gov/citations/20200002390) discusses challenges they encountered with Linux as a real-time operating system. In case you are interested in how the Linux kernel and scheduler works under the hood I recommend reading [this guide](https://wxdublin.gitbooks.io/deep-into-linux-and-beyond/content/index.html) written by someone who is much more knowledgable on this topic than I am. The topic also discusses load balancing on multi-core architectures.
+Task scheduling on standard operating systems is to some extent non-deterministic, meaning one cannot give a guaranteed - mathematically provable - upper bound for the execution time. This is somewhat desired for most applications as this increases throughput but for any real-time system one wants to be able to give such an upper bound that a given task will never exceed. Rather than executing something as fast as possible the aim is to **execute tasks consistently**, in a deterministic fashion: What matters is the **worst case latency** rather than the average latency. There are different approaches for rendering (Linux) operating systems real-time capable. These will be discussed in the next section. An introduction to real-time operating systems can be found [here](https://www.youtube.com/watch?v=4UY7hQjEW34) and [here](https://www.youtube.com/watch?v=w3yT8zJe0Uw). [This NASA conference paper](https://ntrs.nasa.gov/citations/20200002390) discusses challenges they encountered with Linux as a real-time operating system. In case you are interested in how the Linux kernel and scheduler works under the hood I recommend reading [this guide](https://wxdublin.gitbooks.io/deep-into-linux-and-beyond/content/index.html) written by someone who is much more knowledgeable on this topic than I am. The topic also discusses load balancing on multi-core architectures.
 
 
 
@@ -37,7 +37,7 @@ By **default** the Linux kernel can be [compiled with different levels of preemp
 
 These can be combined with the feature of [control groups (`cgroups` for short)](https://man7.org/linux/man-pages/man7/cgroups.7.html) by setting [`CONFIG_RT_GROUP_SCHED=y` during kernel compilation](https://stackoverflow.com/a/56189862/9938686), which reserves a certain fraction of CPU-time for processes of a certain (user-defined) group. This seems to be though connected to [high latency spikes](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_for_real_time/8/html-single/optimizing_rhel_8_for_real_time_for_low_latency_operation/index#further_considerations), something that can be observed with control groups by means of [`cyclicytest`s](https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cyclictest/start).
 
-**`PREEMPT_RT`** developed from `PREEMPT` and is a set of patches that aims at making the kernel fully preemptible, even in critical sections (`PREEMPT_RT_FULL`). For a more detailed explanation refer to [this Ubuntu in depth-guide](https://ubuntu.com/blog/real-time-kernel-technical). For this purpose e.g. [spinlocks are largely replaced by mutexes](https://wiki.linuxfoundation.org/realtime/documentation/technical_details/sleeping_spinlocks). This way there is no need for kernel space programming - instead on can use the standard C and Posix threading libraries. In mid 2021 Linux lead developer Linus Torvalds [merged 70 of the outstanding 220 patches](https://linutronix.de/news/The-PREEMPT_RT-Locking-Code-Is-Merged-For-Linux-5.15) into the Linux mainline. In the near future `PREEMPT_RT` should be available by default to the Linux community without needing to patch the system, guaranteeing also the maintenance of the patch. For a more detailed overview have a look at [this](https://bootlin.com/doc/training/preempt-rt/preempt-rt-slides.pdf) presentation as well as the Ubuntu introductory series (see [this webinar](https://ubuntu.com/engage/an-introduction-to-real-time-linux-part-i) as well as [this blog post](https://ubuntu.com/blog/real-time-kernel-technical)). One potential problem with this is that the kernel drivers are not necessarily developed with real-time constraints in mind.
+**`PREEMPT_RT`** developed from `PREEMPT` and is a set of patches that aims at making the kernel fully preemptible, even in critical sections (`PREEMPT_RT_FULL`). For a more detailed explanation refer to [this Ubuntu in depth-guide](https://ubuntu.com/blog/real-time-kernel-technical). For this purpose e.g. [spinlocks are largely replaced by mutexes](https://wiki.linuxfoundation.org/realtime/documentation/technical_details/sleeping_spinlocks). This way there is no need for kernel space programming - instead one can use the standard C and Posix threading libraries. In mid 2021 Linux lead developer Linus Torvalds [merged 70 of the outstanding 220 patches](https://linutronix.de/news/The-PREEMPT_RT-Locking-Code-Is-Merged-For-Linux-5.15) into the Linux mainline. In the near future `PREEMPT_RT` should be available by default to the Linux community without needing to patch the system, guaranteeing also the maintenance of the patch. For a more detailed overview have a look at [this](https://bootlin.com/doc/training/preempt-rt/preempt-rt-slides.pdf) presentation as well as the Ubuntu introductory series (see [this webinar](https://ubuntu.com/engage/an-introduction-to-real-time-linux-part-i) as well as [this blog post](https://ubuntu.com/blog/real-time-kernel-technical)). One potential problem with this is that the kernel drivers are not necessarily developed with real-time constraints in mind.
 
 `PREEMPT_RT` is widely used in robotics: