Merge pull request #5 from themultiplexer/hw4

hw4

.gitignore

@@ -1,6 +1,6 @@
 # Generated by Cargo
 # will have compiled files and executables
-/target/
+*/target/
 
 # Remove Cargo.lock from gitignore if creating an executable, leave it for libraries
 # More information here http://doc.crates.io/guide.html#cargotoml-vs-cargolock

hw4/simu1/ANSWERS.md

@@ -0,0 +1,39 @@
+# hw4 - Simulation 1 - Lösungen
+
+### Warmup
+
+`0x611c` =>
+
+`0110 0001 0001 1100` =>
+
+| Valid | PDE | PTE | Offset |
+|-------|-----|-----|--------|
+|0      |11000|01000|11100   |
+| False | 24  | 8   | 28     |
+
+PDE at index 24:
+
+> page 108: 83 [...] e9 **a1** e8 [...] ff
+
+
+
+`0xa1` => `1010 0001` => `1 | 0100001` => Valid | 33
+
+PTE at index 8 in page 33 (found in PDE):
+
+> page 33: 7f [...] 7f **b5** 7f [...] 7f
+
+
+`0xb5` => `1011 0101` => `1 | 0110101` => Valid | 53
+
+Final Value is in page `0xb5` (53) with offset 28 => 0x08 (8).
+
+
+
+### Aufgaben
+
+1. Für eine zweistufige Seitentabelle benötigt man ein Register, für eine dreistufige Seitentabelle bräuchte man ein zweites PDBR.
+
+2. Da es sich bei dieser Simulation um eine zweistufige Seitentabelle handelt, gibt es eine Referenz für den PDE, eine für den PTE und schlussendlich noch eine dritte Referenz, in der das Endergebnis steht.
+
+3. Da der Cache nicht im Voraus weiß, auf welche Adresse nach der Übersetzung des PDE bzw. PTE zugegriffen wird, müssen danach erst wieder Daten in den Cache geladen werden. Dies führt zu einer Reihe von Cache Misses.

hw4/simu2/ANSWERS.md

@@ -0,0 +1,31 @@
+
+# Simulation 2 - Antworten
+
+Diese Simulation wurde auf einem Laptop mit 8GB RAM, einer 8GB swapfile und 4 Prozessorkernen ausgeführt.
+
+
+1. Wenn man *mem* mit auch nur mit 1 MB Speicher aufruft, dann geht die CPU Auslastung eines Kerns auf 100%. Im Idle Zustand war die user-time bei ~1%. Bei nur einem laufenden mem-Programm betrug die user-time ~25%. Bei 3 laufenden Instanzen waren es ~80% und bei 4 ~99% user-time.
+
+   Das klingt absolut logisch, da der Prozessor des Systems 4 Kerne hat. Denn wenn auf jedem Kern ein mem-Programm läuft, dann hat das Bertriessystem keinen eigenen Kern und die prozentuale sys-time wird winzig.
+
+2. Direkt nach dem Ausführen von ./mem 1024 hat sich der freie Speicher um ~1.050.000 Byte verringert und die Spalte swpd hat sich nicht verändert, sondern blieb auf 0. Sobald wir das mem-Programm (mit Ctrl-C) beendet haben, ist der freie Speicher (free) fast wieder auf den Urprungswert gesprungen.
+
+   Es fehlten ~250 Byte. Der freie Speicher hat sich danach also verkleinert. Auf der Workstation wurde bereits bei 1024 Byte *geswapped* und der freie Speicher war nach dem Beenden des Programms größer.
+
+3. Bei ./mem 4000 gab es auf dem Rechner (mit 8GB RAM) absolut kein swap-in / swap-out. Es sei denn, der freie Speicher von den gesamten 8GB war kleiner als die ~4GB. Unter normaler Last war erst bei ./mem 7000 ein deutlicher swap-in und -out sichtbar.
+
+   Bei jedem der Werte war jedoch der erste *loop* immer langsamer. Durschnittlich war er oft ~50% langsamer. Im ersten Loop werden 6x durchschnittlich 244.000 Byte in den Swap geschrieben (swap-out). Das ergibt die ~1.700.000 bei (swpd). Es werden bei ./mem 7000 ~5.400.000 Bytes in den physikalischen Speicher ausgelagert und insgesamt ~1.700.000 in den Swap. Das sind zusammen ungefähr die angeforderten 7 GB.
+   
+   In den folgenden Loops fand kaum noch ein swap-out statt (durchschnittlich ~0 Byte), dafür aber Rückschrieb von Swap in den RAM (swap-in).
+
+4. Die CPU Auslastung durch das mem-Programm ist immens. Wenn man es auf dem Laptop ausführt, drehen direkt die Lüfter hoch. Doch wie zu erwarten und im Quellcode zu sehen, ist das C-Programm nicht *multi-threaded*. In einem beliebigen System Monitor (z.B. htop) sieht man, dass nur ein Kern ausgelastet ist.
+
+   Im ersten Loop entsprechen die Werte von **swap-out** ungefähr den den Werten von **block-out**, aber es finden auch **block-in**s im ähnlichen Werteberich statt.
+
+5. Bei 4000 Byte braucht der erste loop 1070 ms und alle restlichen 745ms
+
+   Da bereits beim Aufruf von ./mem 8192 ein Segmentation Fault auftritt, war es nicht möglich über die Grenze des physikalischen 8GB Speichers (8192 kByte) zu gehen. Der Rest dieser Aufgabe ist also nicht wirklich beantwortbar.
+
+   Bei ./mem 8191 muss allerdings auch schon massiv *geswapped* werden. Der erste Loop braucht 6 Sekunden und die folgenden mehr als 60 Sekunden. Die Bandbreite in Loop 0 war noch bei 1317 MB/s in Loop 1 schon 128 MB/s und in den folgenden Loops ~110 MB/s. Man merkt dass nun die Festplatte der *bottleneck* ist, da das Programm kaum noch CPU Leistung benötigt.
+
+6. Bei 14584 schlägt die Speicheralloziierung fehl.

hw4/simu3/ANSWERS.md

@@ -0,0 +1,18 @@
+# hw4 - Simulation 3 - Antworten
+
+1.
+    1. FIFO: Da immer das älteste Element aus dem Cache geworfen wird, verursacht `1,2,3,4,5,6,1,2,...` ausschließlich Cache-Misses.
+    2. LRU: Nun wird immer das am längsten nicht getroffene Element aus dem Cache geworfen. Die Strategie bei FIFO funktioniert auch hier.
+    3. MRU: Hier funktioniert die bisher verwendete Folge nicht mehr. Da immer das zuletzt verwendete Element aus dem Cache entfernt wird, ist `1,2,3,4,5,6,5,6,...` eine Möglichkeit, um ausschließlich Cache-Misses zu provozieren. Die Folge `1-6` dient dabei dazu, den Cache zuerst aufzufüllen.
+    4. Für unseren Fall (eine Abfolge von 6 verschiedenen Zugriffen) braucht der Cache eine minimale Größe von 6, um sehr viel mehr Cache-Hits zu erreichen. Um genau zu sein, sind dann immer alle Einträge im Cache vorhanden, und nach der anfänglichen Auffüllphase (in der nur Misses auftreten) ist jeder Zugriff ein Hit.
+
+2. Für unser Programm, siehe `randomtrace.c`.
+    1. Wir erwarten, dass sich die verschiedenen Policies entsprechend dem, wie wir es in der Vorlesung besprochen hatten, verhalten.
+
+3. *Traces* mit *locality*:
+
+    i. Um räumliche Lokalität (spatial locality) herzustellen darf man die TLB Abdeckung nicht überschreiten bzw. müssen Zahlen gewählt werden, die in der Nähe von einander liegen. Zusätzlich kann man zeitliche Lokalität erzeugen, in dem sich Zahlen wiederholen (temporal locality). Das bedeutet 1,2,2,3,2,3,2,3,2,3,2,2,2,2 ist von räumlicher und zeitlicher Lokalität.
+
+    ii. LRU hatte beim Auruf mit solchen traces eine Hitrate von ca. 80%
+
+    iii. Mit der Policy RAND gab es trotzdem immer die selbe Hitrate wie mit LRU...

hw4/simu3/randomtrace.c

@@ -0,0 +1,25 @@
+#include <stdio.h>
+#include <stdlib.h>
+#include <time.h>
+
+int main(int argc, char* argv[]) {
+  srand(time(NULL));
+
+  if (argc != 3) {
+    fprintf(stderr, "Usage: ./randomtrace <count> <size>\n");
+    return -1;
+  }
+
+  int i, r, s, t;
+  s = atoi(argv[1]);
+  t = atoi(argv[2]);
+  for (i = 0; i < s; i++) {
+    r = (int) (rand() % t);
+    if (i != s - 1) {
+      printf("%d,", r);
+    } else {
+      printf("%d", r);
+    }
+  }
+  printf("\n");
+}

hw4/task1/Cargo.toml

@@ -0,0 +1,8 @@
+[package]
+name = "task1"
+version = "0.1.0"
+authors = ["Lorenz Bung & Joshua Rutschmann"]
+
+[dependencies]
+procinfo = "^0.4.2"
+libc = "^0.2"

hw4/task1/src/main.rs

@@ -0,0 +1,95 @@
+extern crate procinfo;
+
+use std::env;
+use std::process;
+
+mod readproc;
+mod pstree;
+
+mod unit_test_pstree;
+mod unit_test_readproc;
+
+/// Mainfunction
+fn main() {
+
+    let args: Vec<String> = env::args().collect();
+
+    match args.len() {
+        1 => {
+            if let Ok(pid_tuple) = readproc::self_pids() {
+                let pid = pid_tuple.0;
+                let ppid = pid_tuple.1;
+
+                // Commands & Threads for PID
+                if let Ok(pid_command) = readproc::get_pid_command(pid) {
+                    if let Ok(pid_threads) = readproc::get_thread_count(pid) {
+                        println!(
+                            "My PID : {} - {} running {} threads",
+                            pid,
+                            pid_command,
+                            pid_threads
+                        );
+                    }
+                }
+
+                // Commands & Threads for Parent-PID
+                if let Ok(ppid_command) = readproc::get_pid_command(ppid) {
+                    if let Ok(ppid_threads) = readproc::get_thread_count(ppid) {
+                        println!(
+                            "My PPID: {} - {} running {} threads",
+                            ppid,
+                            ppid_command,
+                            ppid_threads
+                        );
+                    }
+                }
+
+            }
+
+
+            if let Ok(size_tuple) = readproc::get_ownprocess_mem() {
+                // Memory
+                let vspace = size_tuple.0;
+                let code = size_tuple.1;
+                let data = size_tuple.2;
+
+                println!(
+                    "My mem : {} (vspace), {} (code), {} (data)",
+                    vspace,
+                    code,
+                    data
+                );
+            }
+
+            if let Ok(last_command) = readproc::get_last_created_command() {
+                // Last Process
+                println!("Last process created in system was: {}", last_command);
+            }
+
+
+            if let Ok(task_total) = readproc::get_task_total() {
+                // Number of tasks
+                println!("Total number of tasks: {}", task_total);
+            }
+        }
+
+        2 => {
+            match args[1].parse::<i32>() {
+                Ok(pid) => {
+                    if !pstree::print(pid) {
+                        process::exit(1);
+                    }
+                }
+                Err(_) => {
+                    println!("Error while parsing PID");
+                    process::exit(1);
+                }
+            }
+        }
+
+        _ => {
+            println!("Correct usage: no param or param PID");
+            process::exit(1);
+        }
+    }
+}

hw4/task1/src/pstree.rs

@@ -0,0 +1,95 @@
+extern crate libc;
+
+use procinfo::pid;
+use self::libc::pid_t;
+
+/// Datenstruktur für einen Prozess.
+pub struct Process {
+    name: String,
+    pid: pid_t,
+    ppid: pid_t,
+}
+
+impl Process {
+    /// Erstellt eine Prozess-Datenstruktur aus procinfo::Stat.
+    pub fn new(with_pid: pid_t) -> Self {
+        if let Ok(stat) = pid::stat(with_pid) {
+            Process {
+                name: stat.command,
+                pid: stat.pid,
+                ppid: stat.ppid,
+            }
+        } else {
+            panic!("Internal Error: Process not found")
+        }
+    }
+
+    /// Erstellt eine Prozess-Datenstruktur aus procinfo::Stat.
+    pub fn me() -> Self {
+        if let Ok(my_pid) = pid::stat_self() {
+            Process::new(my_pid.pid)
+        } else {
+            panic!("Internal Error: I don't have a PID but I am running.")
+        }
+    }
+
+    /// Prüft ob das Prozess-Struct ein Elternprozess besitzt.
+    pub fn has_parent(&self) -> bool {
+        self.ppid != 0
+    }
+
+    /// Gibt den Elternprozess zurück.
+    pub fn parent(&self) -> Self {
+        Process::new(self.ppid)
+    }
+
+    /// Prüft ob das Prozess-Struct einen (entfernten) Elternprozess mit dem übergebenen pid hat.
+    pub fn has_parent_with_pid(&self, pid: pid_t) -> bool {
+        if self.pid == pid {
+            return true;
+        }
+
+        if self.has_parent() {
+            return self.parent().has_parent_with_pid(pid);
+        }
+
+        false
+    }
+
+    /// Gibt über Rekursion über die Eltern eine Prozesskette aus.
+    pub fn print_recursive(&self, to_pid: pid_t, output: &mut String) {
+
+        if output.len() == 0 {
+            *output = format!("{}({}){}", self.name, self.pid, output);
+        } else {
+            *output = format!("{}({})---{}", self.name, self.pid, output);
+        }
+
+        if self.has_parent() && self.pid != to_pid {
+            self.parent().print_recursive(to_pid, output);
+        }
+    }
+}
+
+/// Geht von eigenem Prozess aus und gibt die Prozesskette bis zum übergebenem PID aus
+/// und fängt mögliche Fehler ab.
+pub fn print(pid: pid_t) -> bool {
+
+    if let Err(_) = pid::stat(pid) {
+        println!("Invalid PID");
+        return false;
+    }
+
+    let my_proc = Process::me();
+
+    if !my_proc.has_parent_with_pid(pid) {
+        println!("This Process has no parent {}", pid);
+        return false;
+    }
+
+    let mut output = String::new();
+    my_proc.print_recursive(pid, &mut output);
+    println!("{}", output);
+
+    true
+}

hw4/task1/src/readproc.rs

@@ -0,0 +1,66 @@
+use procinfo::pid;
+use procinfo::loadavg;
+
+/// Returns the PID and PPID of the current process.
+/// Throws an error if the current process doesn't exist (should never occur).
+pub fn self_pids() -> Result<(i32, i32), &'static str> {
+    match pid::stat_self() {
+        Ok(stat) => Ok((stat.pid, stat.ppid)),
+        Err(_) => Err("PID not alive: PID and PPID not found"),
+    }
+}
+
+/// Returns the command (string) belonging to the given PID.
+/// Throws an error if the given PID doesn't exist.
+pub fn get_pid_command(pid: i32) -> Result<String, &'static str> {
+    match pid::stat(pid) {
+        Ok(stat) => Ok(stat.command),
+        Err(_) => Err("PID not alive: no command name found"),
+    }
+}
+
+/// Returns the last created command (string) of the system.
+/// Throws an error if there is no last Command.
+pub fn get_last_created_command() -> Result<String, &'static str> {
+    match loadavg() {
+        Ok(stat) => {
+            let last_pid = stat.last_created_pid;
+            match pid::stat(last_pid) {
+                Ok(st) => Ok(st.command),
+                Err(_) => Err("No last command via PID found"),
+            }
+        }
+        Err(_) => Err("No last command found"),
+    }
+}
+
+/// Returns the number of threads belonging to the given PID.
+/// Throws an error if the given PID doesn't exist.
+pub fn get_thread_count(pid: i32) -> Result<u32, &'static str> {
+    match pid::stat(pid) {
+        Ok(stat) => Ok(stat.num_threads as u32),
+        Err(_) => Err("PID not alive: no threads counted"),
+    }
+}
+
+/// Returns the number of total tasks running in the system.
+/// Throws an error if the total number of tasks doesn't exist.
+pub fn get_task_total() -> Result<u32, &'static str> {
+    match loadavg() {
+        Ok(stat) => Ok(stat.tasks_total),
+        Err(_) => Err("No total count of tasks in system found"),
+    }
+}
+
+/// Returns the size of the virtual, code and data memory size of the current process.
+/// Throws an error if the current process doesn't exist (should never occur).
+pub fn get_ownprocess_mem() -> Result<(usize, usize, usize), &'static str> {
+    match pid::stat_self() {
+        Ok(stat) => {
+            let csize = stat.end_code - stat.start_code;
+            let dsize = stat.end_data - stat.start_data;
+            Ok((stat.vsize, csize, dsize))
+        }
+        Err(_) => Err("PID not alive: no memory found"),
+    }
+}

hw4/task1/src/unit_test_pstree.rs

@@ -0,0 +1,57 @@
+#[cfg(test)]
+mod tests {
+    use pstree::Process;
+    use pstree::print;
+
+    #[test]
+    #[should_panic]
+    fn new_invalid_pid() {
+        Process::new(-1000);
+    }
+
+    #[test]
+    fn new_valid_pid() {
+        Process::new(1);
+    }
+
+    #[test]
+    fn hasparent_no() {
+        assert_eq!(false, Process::has_parent(&Process::new(1)));
+    }
+
+    #[test]
+    fn hasparent_yes() {
+        assert_eq!(true, Process::has_parent(&Process::me()));
+    }
+
+    #[test]
+    #[should_panic]
+    fn parent_not_existing() {
+        Process::parent(&Process::new(1));
+    }
+
+    #[test]
+    fn parent_existing() {
+        Process::parent(&Process::me());
+    }
+
+    #[test]
+    fn hasparent_with_pid_not_existing() {
+        assert_eq!(false, Process::has_parent_with_pid(&Process::me(), -1000));
+    }
+
+    #[test]
+    fn hasparent_with_pid_existing() {
+        assert_eq!(true, Process::me().has_parent_with_pid(1));
+    }
+
+    #[test]
+    fn print_not_existing() {
+        assert_eq!(false, print(-1000));
+    }
+
+    #[test]
+    fn print_existing() {
+        assert_eq!(true, print(1));
+    }
+}

hw4/task1/src/unit_test_readproc.rs

@@ -1,8 +1,8 @@
 #[cfg(test)]
 mod tests {
     use procinfo::pid::{status, status_self};
-    use {get_ownprocess_mem, get_pid_command, get_task_total, get_thread_count, self_pids};
-
+    use readproc::{get_ownprocess_mem, get_pid_command, get_task_total, get_thread_count,
+                   self_pids};
 
     fn sol_self_pids() -> (i32, i32) {
         match status_self() {

hw4/task2/README.md

@@ -1,376 +0,0 @@
-# Homework hw4 task2
-
-Die folgenden Informationen sollen helfen, sich schneller in die Materie des
-'Timings' von Programmen einzuarbeiten:
-
-- Das externe Crate [time][] bietet mehr und vor allem einfachere Funktionalität
-  als die Rust Standard-Bibliothek.
-- Alle Betriebssysteme stellen eine Time API zu Verfügung. Es kann hilfreich
-  sein zu verstehen, wie diese funktioniert. Daher beschäftigt sich das nächste
-  Kapitel ausführlich mit dieser API.
-- Das Modul [std::mem] aus der Standardbibliothek ist zur Lösung dieser Aufgabe
-  sehr hilfreich.
-
-[time]: https://docs.rs/time
-[std::mem]: https://doc.rust-lang.org/std/mem/
-
-## Warmup für das Programm
-
-Um mit hoher Wahrscheinlichkeit Instruktionen und Daten aus dem Cache zu beziehen, sollte Ihr Programm ein kleines 'Cache' Warmup durchlaufen.
-
-Dies kann über ein simples Inkrementieren erreicht werden. Bei der Berechnung müssen Sie aber darauf achten, dass der Compiler das Ergebnis nicht vorausberechnen kann. Sonst würde bei der Optimierung der Compiler einfach das Ergebnis ausrechnen und das Ergebnis direkt in den Code schreiben. Damit wäre das Warmup (Durchlaufen des Codes) dahin.
-
-Mit einer Parameterübergabe durch die Kommandozeile steht das Ergebnis zur Compile-Zeit nicht fest und somit kann der Code nicht einfach 'weg'-optimiert werden. Dazu ein Beispiel:
-
-```Rust
-//where page_count and jump are cmd arguments
-let mut a = vec![0i32; page_count * jump];
-
-    // warm up
-    for i in a.iter_mut() {
-        *i += 1;
-    }
-```
-
-## Zeiten lesen in C
-
-Das folgende Kapitel muss zur Lösung von task2 nicht komplett verstanden werden.
-Vielmehr soll es weitere Informationen liefern, wenn Ihnen gewisse
-Funktionalitäten der Thematik 'Timing' unklar sind.
-
-- [Datenstrukturen](#datenstrukturen)
-- [Zeit lesen](#zeit-lesen)
-- [Zeitvergleich: Differenzzeitmessung](#zeitvergleich-differenzzeitmessung)
-
-### Datenstrukturen
-
-Betriebssysteme stellen Anwendungen Zeitgeber mit unterschiedlichen
-Eigenschaften zur Verfügung, über die das Zeitverhalten kontrolliert wird. Diese
-sind gekennzeichnet durch ihre
-
-- Genauigkeit,
-- die Zuverlässigkeit,
-- den Bezugspunkt,
-- die Darstellung und
-- den maximalen Zeitbereich.
-
-Das Betriebssystem repräsentiert Zeiten unter anderem mit den folgenden
-Datentypen (Darstellung):
-
-- clock_t: Timerticks.
-- struct timeval: Zeit in Mikrosekunden-Auflösung.
-- struct timespec: Zeit in Nanosekunden-Auflösung.
-- struct tm: absolute Zeitangabe.
-
-```c
-struct timeval {
-
-    time_t      tv_sec;     /* seconds */
-    suseconds_t tv_usec;    /* microseconds */
-};
-
-struct timespec {
-    time_t tv_sec; /* seconds */
-    long tv_nsec; /* nanoseconds */
-};
-
-struct tm
-{
-    int tm_sec; /* seconds */
-    int tm_min; /* minutes */
-    int tm_hour; /* hours */
-    int tm_mday; /* day of the month */
-    int tm_mon; /* month */
-    int tm_year; /* year */
-    int tm_wday; /* day of the week */
-    int tm_yday; /* day in the year */
-    int tm_isdst; /* daylight saving time */
-};
-```
-
-Die Strukturen struct timeval und struct timespec bestehen aus jeweils zwei
-Variablen, die einmal den Sekundenanteil und einmal den Mikro- beziehungsweise
-den Nanosekundenanteil repräsentieren. Die Darstellung erfolgt jeweils normiert.
-Das bedeutet, dass der Mikro- oder Nanosekundenanteil immer kleiner als eine
-volle Sekunde bleibt. Ein Zeitstempel von beispielsweise 1 Sekunde, 123456
-Mikrosekunden ist gültig, 1 Sekunde, 1234567 Mikrosekunden ist ungültig. In
-normierter Darstellung ergäbe sich 2 Sekunden, 234567 Mikrosekunden.
-
-Die Darstellungs- beziehungsweise Repräsentationsform reflektiert auch den
-darstellbaren Wertebereich. Da bei den dargestellten Datenstrukturen für den Typ
-time\_t ein long eingesetzt wird, lassen sich auf einer 32-Bit Maschine rund 4
-Milliarden Sekunden zählen, auf einer 64-Bit Maschine 2\^64 (mehr als 500
-Milliarden Jahre).
-
-Als Bezugspunkte haben sich die folgenden eingebürgert: *Start des Systems,
-*Start eines Jobs und \*Start einer Epoche, beispielsweise "Christi Geburt" oder
-der 1.1.1970 (Unix-Epoche). Dieser Bezugspunkt weist zudem noch eine örtliche
-Komponente auf: Der Zeitpunkt 19:00 Uhr in Europa entspricht beispielsweise
-einem anderen Zeitpunkt in den USA (minus sechs Stunden zur Ostküste).
-
-Die Genauigkeit wird beeinflußt durch, die Taktung des Zeitgebers, deren
-Schwankungen und durch Zeitsprünge.
-
-Das Attribut Zuverlässigkeit eines Zeitgebers beschreibt dessen Verhalten bei
-(bewußten) Schwankungen der Taktung und bei Zeitsprüngen: Ein Zeitgeber kann
-beispielsweise der Systemuhr folgen (CLOCK\_REALTIME) oder unabhängig von
-jeglicher Modifikation an der Systemzeit einfach weiterzählen
-(CLOCK\_MONOTONIC). Die Posix-Realzeiterweiterung beziehungsweise Linux-Systeme
-definieren hierzu folgende Clocks [Man-Page zu
-clock\_gettime()](http://linux.die.net/man/3/clock_gettime):
-
-- **CLOCK\_REALTIME**: Dieser Zeitgeber repräsentiert die systemweite, aktuelle
-  Zeit. Er reagiert auf Zeitsprünge, sowohl vorwärts als auch rückwärts, die
-  beispielsweise beim Aufwachen (Resume) nach einem Suspend (Schlafzustand des
-  gesamten Systems) ausgelöst werden. Er reagiert ebenfalls auf unterschiedliche
-  Taktungen, die beispielsweise durch NTP erfolgen. Dieser Zeitgeber liefert die
-  Sekunden und Nanosekunden seit dem 1.1. 1970 UTC (Unixzeit) zurück.
-- **CLOCK\_MONOTONIC**: Dieser Zeitgeber läuft entsprechend seiner Auflösung
-  stets vorwärts, ohne dabei Zeitsprünge zu vollziehen. Er ist also unabhängig
-  von der mit Superuserprivilegien zu verändernden Systemuhr. Allerdings
-  reagiert dieser Zeitgeber auf Modifikationen der Taktung, die beispielsweise
-  durch NTP erfolgen.
-- **CLOCK\_MONOTONIC_RAW**: Dieser Zeitgeber ist linuxspezifisch. Er reagiert
-  weder auf Zeitsprünge noch auf in Betrieb geänderte Taktungen (NTP).
-- **CLOCK\_PROCESS\_CPUTIME_ID**: Dieser Zeitgeber erfasst die Verarbeitungszeit
-  (Execution Time) des zugehörigen Prozesses. Das funktioniert aber nur
-  zuverlässig auf Single-Core-Systemen beziehungsweise wenn sichergestellt
-  werden kann, dass keine Prozessmigration stattfindet.
-- **CLOCK\_THREAD\_CPUTIME\_ID**: Dieser Zeitgeber erfasst die Verarbeitungszeit
-  (Execution Time) des zugehörigen Threads. Das funktioniert aber nur
-  zuverlässig auf Single-Core-Systemen beziehungsweise wenn sichergestellt
-  werden kann, dass keine Prozessmigration stattfindet.
-
-Der maximale Zeitbereich schließlich ergibt sich durch die Auflösung des
-Zeitgebers und die Bitbreite der Variablen:
-
-```text
-zeitbereich = auflösung * 2^bitbreite
-```
-
-### Zeit lesen
-
-Es gibt unterschiedliche Systemfunktionen, mit denen die aktuelle Zeit gelesen
-werden kann. Favorisiert ist die Funktion *int clock\_gettime(clockid\_t
-clk\_id, struct timespec * tp)*, die die Zeit seit dem 1.1.1970 (Unixzeit) als
-Universal Time (Zeitzone UTC) zurückliefert (struct timespec). Konnte die
-aktuelle Zeit gelesen werden, gibt die Funktion Null, ansonsten einen Fehlercode
-zurück. Allerdings ist das Auslesen auf 32-Bit Systemen in so fern
-problematisch, da der 32-Bit Zähler am 19. Januar 2038 überläuft.
-
-```c
-struct timespec {
-        time_t   tv_sec;        /* seconds */
-        long     tv_nsec;       /* nanoseconds */
-};
-
-```
-
-```c
-struct timespec timestamp;
-    ...
-    if (clock_gettime(CLOCK_MONOTONIC,&timestamp))
-    {
-        perror("timestamp");
-        return -1;
-    }
-    printf("seconds: %ld, nanoseconds: %ld\n",
-        timestamp.tv\_sec, timestamp.tv\_nsec);
-```
-
-Durch die Wahl der Clock CLOCK\_PROCESS\_CPUTIME\_ID beziehungsweise
-CLOCK\_THREAD\_CPUTIME\_ID kann auch die Verarbeitungszeit ausgemessen werden
-(Profiling).
-
-Die Genauigkeit der zurückgelieferten Zeit kann mit Hilfe der Funktion
-*clock\_getres(clockid\_t clk\_id, struct timespec * res)* ausgelesen werden.
-
-Die Funktion *clock\_gettime()* ist nicht in der Standard-C-Bibliothek zu
-finden, sondern in der Realzeit-Bibliothek librt. Daher ist bei der
-Programmgenerierung diese Bibliothek hinzuzulinken (Parameter -lrt). Steht nur
-die Standard-C-Bibliothek zur Verfügung, kann
-
-- time\_t time(time\_t *t) oder auch
-- int gettimeofday(struct timeval * tv, struct timezone * tz)
-
-eingesetzt werden.
-
-*time()* gibt die Sekunden zurück, die seit dem 1.1.1970 (UTC) vergangen sind.
-
-```c
-time_t now;
-...
-now = time(NULL);
-```
-
-*gettimeofday()* schreibt an die per tv übergebene Speicheradresse die Sekunden
-und Mikrosekunden seit dem 1.1.1970. Das Argument tz wird typischerweise mit
-NULL angegeben.
-
-Liegen die Sekunden seit dem 1.1.1970 vor (timestamp.tv\_sec), können diese mit
-Hilfe der Funktionen
-
-- struct tm *localtime\_r(const time\_t *timep, struct tm *result) oder
-- struct tm *gmtime\_r(const time\_t * timep, struct tm *result)
-
-in die Struktur *struct tm* konvertiert werden.
-
-```c
-struct tm absolute_time;
-if (localtime_r( timestamp.tv_sec, &absolute_time )==NULL)
-{
-    perror("localtime_r" );
-    return -1;
-}
-
-printf("year: %d\n", absolute_time.tm_year);
-```
-
-Die Funktion *time\_t mktime(struct tm * tm)* konvertiert eine über die Struktur
-struct tm gegebene Zeit in Sekunden seit dem 1.1.1970 (time\_t).
-
-Mit Hilfe der Funktion *clock\_t times(struct tms \ buf)* lässt sich sowohl die
-aktuelle Zeit zu einem letztlich nicht genau definierten Bezugspunkt, als auch
-die Verarbeitungszeit (Execution-Time) des aufrufenden Prozesses bestimmen. Die
-Zeiten werden als Timerticks (clock\_t) zurückgeliefert. Die zurückgelieferte
-Verarbeitungszeit ist aufgeschlüsselt in die Anteile, die im Userland und die
-Anteile, die im Kernel verbraucht wurden. Außerdem werden diese Anteile auch für
-Kindprozesse gelistet.
-
-```c
-#include <stdio.h>
-#include <sys/times.h>
-#include <unistd.h>
-#include <time.h>
-
-int main( int argc, char **argv, char **envp )
-{
-    struct tms exec_time;
-    clock_t act_time;
-    long ticks_per_second;
-    long tickduration_in_ms;
-
-    ticks_per_second = sysconf(_SC_CLK_TCK);
-    tickduration_in_ms = 1000/ticks_per_second;
-
-    act_time = times( &exec_time );
-    printf("actual time (in ms): %ld\n", act_time*tickduration_in_ms);
-    printf("execution time (in ms): %ld\n",
-            (exec_time.tms_utime+exec_time.tms_stime)*tickduration_in_ms);
-
-    return 0;
-
-}
-```
-
-Sehr genaue Zeiten lassen sich erfassen, falls der eingesetzte Prozessor einen
-Zähler besitzt, der mit der Taktfrequenz des Systems getaktet wird. Bei einer
-x86-Architektur (PC) heißt dieser Zähler Time Stamp Counter (TSC). Der TSC kann
-auch von einer normalen Applikation ausgelesen werden, allerdings muss
-sichergestellt sein, dass sich die Taktfrequenz zwischen zwei Messungen ändert.
-Alternativ kann man sich vom Betriebssystem über die Taktänderung informieren
-lassen.
-
-### Zeitvergleich: Differenzzeitmessung
-
-Zwei Absolutzeiten (struct tm) werden am einfachsten über deren Repräsentation
-in Sekunden verglichen. Die Umwandlung erfolgt über die Funktion (time\_t
-mktime(struct tm \*tm)). Allerdings ist dabei zu beachten, dass es auf einem
-32-Bit System am 19. Januar 2038 zu einem Überlauf kommt. Wird einer der beiden
-Zeitstempel vor dem 19. Januar 2038 genommen, der andere danach, kommt es zu
-einem falschen Ergebnis, wenn nur die beiden Werte per "\<" beziehungsweise "\>"
-verglichen werden.
-
-Das ist ein generelles Problem und kann dann gelöst werden, wenn sichergestellt
-ist, dass die zu vergleichenden Zeiten nicht weiter als die Hälfte des gesamten
-Zeitbereiches auseinanderliegen. In diesem Fall lassen sich die Makros
-einsetzen, die im Linux-Kernel für den Vergleich zweier Zeiten eingesetzt
-werden. Das Makro time\_after(a,b) liefert true zurück, falls es sich bei a um
-eine spätere Zeit als b handelt. Das Makro time\_after\_eq(a,b) liefert true
-zurück, falls es sich bei a um eine spätere Zeit oder um die gleiche Zeit
-handelt, wie b handelt. Die Zeitstempel a und b müssen beide vom Typ unsigned
-long sein. Natürlich können die Makros auch auf andere Datentypen angepasst
-werden
-
-[HEADERDATEI linux/jiffies.h].
-
-```c
-#define time_after(a,b)         \
-        (typecheck(unsigned long, a) && \
-         typecheck(unsigned long, b) && \
-         ((long)(b) - (long)(a) < 0))
-
-#define time_before(a,b)        time_after(b,a)
-
-#define time_after_eq(a,b)      \
-        (typecheck(unsigned long, a) && \
-         typecheck(unsigned long, b) && \
-         ((long)(a) - (long)(b) \>= 0))
-
-#define time_before_eq(a,b)     time_after_eq(b,a)
-```
-
-Beim Benchmarking ist es häufig notwendig eine Zeitdauer zu messen, Zeitpunkte
-zu erfassen oder eine definierte Zeit verstreichen zu lassen. Dabei sind
-folgende Aspekte zu beachten:
-
-- Die Genauigkeit der eingesetzten Zeitgeber,
-- die maximalen Zeitdifferenzen,
-- Schwankungen der Zeitbasis, beispielsweise durch Schlafzustände,
-- Modifikationen an der Zeitbasis des eingesetzten Rechnersystems (Zeitsprünge)
-  und
-- die Ortsabhängigkeit absoluter Zeitpunkte.
-
-Zur Bestimmung einer Zeitdauer verwendet man häufig eine Differenzzeitmessung.
-Dabei wird vor und nach der auszumessenden Aktion jeweils ein Zeitstempel
-genommen. Die Zeitdauer ergibt sich aus der Differenz dieser beiden Zeitstempel.
-
-Dies ist allerdings nicht immer ganz einfach. Liegt der Zeitstempel
-beispielsweise in Form der Datenstruktur struct timeval (als Ergebnis der
-Funktion *gettimeofday()*) vor, müssen die Sekunden zunächst getrennt von den
-Mikrosekunden subtrahiert werden. Ist der Mikrosekundenanteil negativ, muss der
-Sekundenanteil um eins erniedrigt und der Mikrosekundenanteil korrigiert werden.
-Dazu wird auf die Anzahl der Mikrosekunden pro Sekunde (also eine Million) der
-negative Mikrosekundenanteil addiert.
-
-```c
-#define MICROSECONDS\_PER\_SECOND 1000000
-
-struct timespec * diff_time( struct timeval before, struct timeval after,
-    struct timeval *result )
-{
-    if (result==NULL)
-        return NULL;
-
-    result->tv_sec = after.tv_sec - before.tv_sec;
-    result->tv_usec= after.tv_usec- before.tv_usec;
-
-    if (result->tv_usec<0) {
-        result->tv_sec--;
-        /* result->tv_usec is negative, therefore we use "+" */
-        result->tv_usec = MICROSECONDS_PER_SECOND+result->tv_usec;
-    }
-    return result;
-
-}
-```
-
-Für Zeitstempel vom Typ struct timeval gilt entsprechendes. Anstelle der
-MICROSECONDS\_PER\_SECOND sind NANOSECONDS\_PER\_SECOND einzusetzen. Sind die
-Zeitstempel vorzeichenlos, sieht die Rechnung für den Sekundenanteil etwas
-komplizierter aus. Das soll hier aber nicht weiter vertieft werden.
-
-Etwas einfacher ist die Differenzbildung, wenn aus der Datenstruktur eine
-einzelne Variable mit der gewünschten Auflösung, beispielsweise Mikrosekunden,
-generiert wird. Im Fall von struct timeval wird dazu der Sekundenanteil mit
-einer Million multipliziert und der Mikrosekundenanteil aufaddiert. Bei der
-Multiplikation können natürlich Informationen verloren gehen, allerdings geht
-der gleiche Informationsgehalt auch beim zweiten Zeitstempel verloren. Für die
-Differenzbildung ist das damit nicht relevant, solange der zu messende zeitliche
-Abstand kleiner als 1000 Sekunden ist und es während der Messung keinen Überlauf
-beim Sekundenanteil gibt.
-
-```c
-time_in_usec=((nachher.tv_sec*1000000)+nachher.tv_usec)-
-    ((vorher.tv_sec*1000000)+vorher.tv_usec);
-```