Noch keine Läufe. „＋ Lauf festhalten“ übernimmt die aktuelle Simulation; danach Parameter ändern, neu simulieren und wieder festhalten. Der beste Wert je Spalte wird hervorgehoben.
#
Lauf
Ø Warten
Ø Antwort
Ø Turnaround
Makespan
CPU %
Ctx-Sw.
D-Miss
Durchsatz
Notiz
Pro-Prozess-Analyse & Verteilungen
Pro-Prozess Analyse
Sort:
Prozess
Arr ℹ
Exec. Time ℹ
Netto ℹ
Brutto ℹ
Wait ℹ
Min Resp. ℹ
Ø Resp. ℹ
Max Resp. ℹ
Turnar. ℹ
Tardin. ℹ
Jitter ℹ
D-Miss ℹ
Util % ℹ
NTT ℹ
Preem. ℹ
Metrik:Y:
Bins:auto
📋 Lernguide
🎯 Lernziel
🔍 Im Gantt beobachten
🧪 Experimente
📚 Theorie & Konzepte
Multi-Core Konfiguration
Cores: 2
Global SMP
Globale Queue
Partitioned
Core-Affinität
Work Stealing
Idle→Steal
Gang Sched.
Parallel
G-EDF
Global EDF
P-EDF
Partitioned EDF
Mit fixem Seed sind tie-breaks und Zufallsanteile reproduzierbar.
Load Balancing
Migrationen: 0
Ø Core-Auslastung: —
Algorithmus-Info
Wähle eine Strategie für Details.
Zeit: 0 | Schritt: 0/0
Entscheidung: —
Skalierungs- und Strategieanalyse
Skalierungsstudie noch nicht ausgeführt.
Strategievergleich noch nicht ausgeführt.
Core Status
Per-Core Ready Queues
NUMA Topologie
Scheduling-Overhead
Migration Events
Migration Timeline
Warnungen & Antipatterns
Noch keine Analyse.
DVFS Algorithmus
Performance
f=max immer
Powersave
f=min immer
Ondemand
Reaktiv
Conservative
Graduell
Schedutil
Util-basiert
Interactive
Latenz-opt.
25%
100%
70%
Energie-Statistik
—
Energie (J)
—
Einsparung
—
Ø Frequenz
—
Perf.-Verlust
Algorithmus-Beschreibung
Performance
Läuft immer bei maximaler Frequenz. Beste Performance, höchster Energieverbrauch.
Geeignet für Latenz-kritische Systeme.
Frequenz-Verlauf & CPU-Last über Zeit
Frequenz-Tabelle
Zeit
Auslastung
Frequenz
Leistung
Sync-Konfiguration
Sync-Metriken
Klicke "Sync aufbauen".
Deadlock-Erkennung
⚠ Deadlock erkannt!
✓ Kein Deadlock erkannt
Mutex
Semaphore
Condition Variables
RW-Lock
Producer-Consumer
Sync-Legende
Causal Timeline (State + Cause + Effect)
Thread-State-Ribbon
Resource Inspector
Klicke "Sync aufbauen".
Sync Event Log
—
Ø Wartezeit
—
Ø Turnaround
—
Ø Antwortzeit
—
CPU-Auslastung
—
Durchsatz
—
Ctx Switches
👩🏫 Lehrenden-Analytics
Noch keine Daten erfasst.
Prozess-Details
Prozess
Ankunft
Exec. Time
Start
Fertig
Warten
Turnaround
Antwort
×n: Zeile fasst mehrere Instanzen (Threads oder periodische Jobs) zusammen. Warten = Ø pro Instanz, Turnaround = längste Instanz (Worst Case).
Algorithmus-Vergleich (Ø Wartezeit)
🎲 Stochastische Workloads (Monte Carlo)
Monte-Carlo zeigt Verteilungen statt Einzelwerten: starte die Analyse mit dem aktuellen Setup.
🎯 Multi-Objective Optimization (Pareto)
Pareto-Front zeigt nicht-dominierte Trade-offs zwischen Latenz, Durchsatz, Energie und Deadline-Misses.
🧭 Real OS Mapping
Wird nach der nächsten Simulation mit einem praxisnahen OS-Mapping befüllt.
📐 Schedulierbarkeits-Rechner
🧮 WCRT-Analyse (Response Time Analysis)
Simulation ausführen, dann WCRT berechnen.
🧪 Modular Regression & Parity
Noch nicht ausgeführt.
Algorithmus A RR
Algorithmus B EDF
Speed0 / 0tA=0 | tB=0
Live-KPIs erscheinen nach dem Vergleich.
Verwendet die Prozesse aus dem Scheduler-Tab. Prozesse zuerst dort laden/erstellen.
⚖
Wähle zwei Algorithmen und klicke "Vergleichen"
Gantt-Diagramm Vergleich
A
B
Metriken-Vergleich
Balkendiagramm
📂 Lehr-Beispiele laden
Vorgefertigte Szenarien für den Unterricht. Zeigen klassische Scheduling-Phänomene.
📂 Lehr-Beispiele & Traces 22 Szenarien mit Leitfaden; Import echter Linux-/LTTng-Traces
Begriffe & Definitionen
Scheduling-Literatur verwendet teils unterschiedliche Begriffe für ähnliche Konzepte. Diese Tabelle klärt die wichtigsten Terme. Besonders wichtig: „Response Time“ bedeutet in OS-Lehrbüchern etwas anderes als in der Echtzeit-Literatur.
Zeitgrößen eines Tasks
Abb. 1 – Zeitgrößen eines Jobs (C = 4, wird bei t=5 verdrängt). Die Reaktionszeit im OS-Sinn endet beim ersten CPU-Zugriff, die Wartezeit summiert alle Bereit-Phasen, die Turnaround-Zeit reicht bis zur Fertigstellung. In der Echtzeit-Literatur heißt genau diese Spanne response time Rᵢ (hier 8); die WCRT ist ihr Worst Case.
Begriff
Symbol
Definition
Im Simulator
Execution Time auch: CPU-Burst, Compute Time
C / Cᵢ
Die reine CPU-Rechenzeit, die ein Task benötigt. Enthält keine Warte-, Blockier- oder I/O-Zeiten.
Feld „Execution Time (C)“ beim Anlegen eines Prozesses (ganzzahlig, ≥ 1).
WCET Worst-Case Execution Time
C
Die maximale Execution Time über alle möglichen Eingaben und Codepfade. Schedulierbarkeitsanalysen rechnen mit Cᵢ = WCET.
Modell „WCET (determin.)“: jeder Job rechnet genau C.
ACET Average-Case Execution Time
C̄
Durchschnittliche Execution Time unter realistischer Last. Für Garantien ungeeignet, für Leistungsmessungen sinnvoll.
Modell „ACET (Ø-Zeit)“: vereinfachend 0,7 · C. Modell „Zufällig“: C ± 20 %.
Reaktionszeit OS-Lehrbücher: response time
R
Zeit von der Ankunft bis zum ersten CPU-Zugriff. Maß für Interaktivität. R = firstCPU − arrival
Spalten Min/Ø/Max Resp. im Metriken-Panel, Overlay „Reaktionszeit“ im Gantt.
WCRT Worst-Case Response Time
R*
Begriff der Echtzeit-Literatur: dort ist die Response Time eines Jobs die Zeit von der Freigabe bis zur Fertigstellung (also die Turnaround-Zeit des Jobs), nicht bis zum ersten CPU-Zugriff. Die WCRT ist ihr garantierter Worst Case; schedulierbar, wenn R* ≤ D. Rᵢ = Cᵢ + Σⱼ∈hp(i) ⌈Rᵢ/Tⱼ⌉·Cⱼ
Statistik-Tab, Karte 🧮 WCRT-Analyse, und automatische Analyse im Scheduler-Tab.
Turnaround Time auch: Durchlaufzeit
TAT
Zeit von der Ankunft bis zur vollständigen Fertigstellung. TAT = finish − arrival = W + C
Spalte Turnar. im Metriken-Panel.
Waiting Time auch: Wartezeit
W
Gesamte Zeit zwischen Ankunft und Fertigstellung, in der der Task nicht rechnet – alle Bereit-Phasen zusammen, bei Mutex-Konflikten inklusive Blockierzeit. W = TAT − C
Spalte Wait im Metriken-Panel; gelb mit „!“, wenn mehr als das 1,5-Fache des Durchschnitts.
Laxity / Slack auch: Spielraum
L(t)
Zeitpuffer bis zur Deadline unter Berücksichtigung der noch nötigen Rechenzeit, mit der absoluten Deadline dᵢ = Ankunft + Dᵢ. L(τᵢ, t) = dᵢ − t − rem_Cᵢ L = 0: Task muss sofort laufen, L < 0: Miss unvermeidlich.
Gantt-Overlay ⚡ Kritischer Pfad; Grundlage von LLF.
Tardiness auch: Verspätung
Überschreitung der absoluten Deadline. tardiness = max(0, finish − d)
Spalte Tardin. im Metriken-Panel, rot markiert wenn > 0.
Abgrenzung: drei Fragen, drei Größen
Merkhilfe: „Wie lange rechnet der Task?“ → Execution Time C. „Wann kommt er zum ersten Mal dran?“ → Reaktionszeit R. „Wann ist er fertig?“ → Turnaround-Zeit (in der Echtzeit-Literatur: response time). Die Wartezeit ist die Differenz TAT − C.
Kennzahlen, Prozess-Details, Algorithmus-Vergleich, Monte Carlo, Pareto, OS-Mapping, Schedulierbarkeits-Rechner, WCRT-Analyse
⚖ A/B Vergleich
Zwei Algorithmen direkt gegenüberstellen: Gantt und Metriken
📖 Handbuch
Diese Seite
Tipp: Im Header befinden sich: 🌙/☀ (hell/dunkel), 💾 Presets (Szenarien speichern/laden/teilen), 🎲 Taskset-Gen, 📂 Beispiele, Export/Import und Reset. Im Expertenmodus zusätzlich 🐧 Trace ▾ für Kernel-Trace-Import.
Lernmodus und Expertenmodus
Umschalten oben links über Lernen | Experte. Das Szenario bleibt beim Wechsel erhalten.
Modus
Umfang
Lernen
FCFS, SJF, SRTF, RR, Priority, EDF, RM. Fünf Kernmetriken (weitere über „+N weitere“); erweiterte Prozess-Eigenschaften, Systemparameter und die Pro-Prozess-Analyse sind zugeklappt (▸ öffnet sie).
Experte
Zusätzlich Linux CFS/EEVDF, SCHED_FIFO/RR/DEADLINE, MLQ, MLFQ, LLF, die Tabs Multi-Core und DVFS, Trace-Import, Deadline-Debugger und Lehrenden-Analytics. Alle Details sind standardmäßig aufgeklappt.
Lädt ein Beispiel oder Import eine Expertenfunktion, wechselt der Simulator automatisch in den Expertenmodus und zeigt einen Hinweis.
Darstellung
Standard ist der Skin „Modern“ im Stil der Folien zu Betriebssysteme 1 (hell oder dunkel). Mit ?cd=hm in der Adresse schaltet der Simulator auf das HM-Corporate-Design, mit ?cd=bs1 zurück; die Wahl wird gemerkt. An Szenarien und Exporten ändert der Skin nichts.
Prozesse anlegen
Alle Felder im linken Panel des Scheduler-Tabs. Pflichtfelder: Name und Execution Time. Die Felder ab „Queue-Level“ liegen unter ▸ Erweiterte Eigenschaften.
Feld
Bedeutung
Hinweis
Name
Prozessbezeichnung
z. B. P1, τ1
Ankunft
Ankunfts- bzw. erste Freigabezeit
0 = sofort verfügbar
Execution Time (C)
Reine CPU-Rechenzeit des Tasks (= Cᵢ)
ganzzahlig, ≥ 1
Priorität
1 = höchste Priorität
Für Priority, SCHED_FIFO und SCHED_RR (bei diesen auch Reihenfolge der WCRT-Karte)
Periode
Wiederholungsintervall T
Für EDF/RM/LLF und die Job-Erzeugung periodischer Tasks
Deadline
Relative Deadline D ab jeder Freigabe
Im Formular mit 10 vorbelegt, unabhängig von der Periode; für implizite Deadlines D = T eintragen. Beim Import ohne Angabe: die Periode, ohne Periode keine Deadline.
Periodisch: Freigabe alle T ab der Ankunft. Sporadisch: Abstand mindestens MIT, schwankt um bis zu 50 % (für dasselbe Szenario immer gleich). Aperiodisch: genau ein Job zur Ankunftszeit.
MIT
Minimum Inter-arrival Time
Nur für sporadische Tasks ohne Freigabeliste
Freigaben (Liste)
Feste Freigabezeitpunkte, z. B. „3, 11, 12, 30“
Für sporadische und aperiodische Prozesse: ein Job je Zeitpunkt (Ereignisquelle, Interrupt-Muster, Bursts). Ersetzt Ankunft und MIT-Modell.
MIT-Streuung
Zufälliger Zuschlag auf die MIT
Abstand zwischen Freigaben liegt in [MIT, MIT + Streuung]; leer = halbe MIT. Reproduzierbar.
Aktivierungen
Anzahl Freigaben eines periodischen Tasks
0 = automatisch über das Simulationsfenster (siehe FAQ)
Threads
Anzahl paralleler Threads
1–8; im Gantt als Unterzeilen, für Gang-Scheduling
WCET-Modell
WCET (determin.) / ACET / Zufällig [BCET … C]
WCET: jeder Job genau C. ACET: fest 0,7 · C. Zufällig: je Job ein Wert zwischen BCET und C, gleichverteilt oder normal um die Mitte; die Analysen rechnen weiter mit C als WCET.
BCET
Best-Case Execution Time
Untergrenze beim Modell „Zufällig“; leer = 60 % von C
Core-Affinität
Bevorzugter Kern bei Multi-Core
Auto oder Core 0–3
Farbe
Farbe in Gantt und Legende
Je nach Skin etwas gedämpft dargestellt; gespeichert wird der gewählte Wert
Abhängigkeiten
„wartet auf“: Prozess startet erst, wenn die gewählten fertig sind
Im Gantt als Pfeile; für Pipelines und Fork-Join. Werden mit Export, Import und Share-Link gespeichert. Der Multi-Core-Tab beachtet sie nicht
Schnelles Setup
Name und Execution Time eingeben → + Prozess hinzufügen
Für Echtzeit: Periode und Deadline setzen, Task-Typ auf „Periodisch“
✏ zum Bearbeiten, × zum Löschen
Scheduling-Algorithmen
Algorithmus
Typ
Quantum
Eigenschaft / geeignet für
FCFS
Non-preemptiv
—
Einfache Stapelverarbeitung; zeigt den Konvoi-Effekt
SJF
Non-preemptiv
—
Minimale Ø Wartezeit unter den non-preemptiven Verfahren (bei gleichzeitiger Ankunft optimal); braucht Kenntnis von C
SRTF
Preemptiv
—
Minimiert die Ø Wartezeit (beweisbar optimal); lange Jobs können verhungern
Round Robin (RR)
Preemptiv
✓
Interaktive Systeme, gleichmäßige CPU-Verteilung. FIFO-Ready-Queue: Prozesse, die während einer Zeitscheibe ankommen, reihen sich vor dem verdrängten ein
Priority
Preemptiv (Standard) oder non-preemptiv
—
Prioritätsbasierte Systeme; zeigt Starvation. Die Checkbox Preemptiv neben dem Quantum legt fest, ob eine höher priorisierte Ankunft den laufenden Prozess verdrängt; die Kachel zeigt den Modus.
EDF
Preemptiv, dynamisch
—
Optimal auf einem Prozessor: bei D = T schedulierbar genau dann, wenn ΣU ≤ 100 %. Gleiche Deadline: Reihenfolge in der Prozessliste
Rate Monotonic
Preemptiv, statisch
—
Kürzere Periode = höhere Priorität; optimal unter den statischen Verfahren (D = T)
LLF(Experte)
Preemptiv, dynamisch
—
Kleinste Laxity zuerst; wechselt bei gleicher Laxity häufig
MLQ(Experte)
Mehrere Queues
fest
Strikte Priorität zwischen den Ebenen; innerhalb der Ebenen Round Robin mit Q = 2 (Highest) bzw. Q = 4 (Interactive), Batch FCFS
MLFQ(Experte)
Feedback
2 / 4 / 8
Neue Prozesse oben, Round Robin je Ebene; wer seine Zeitscheibe ganz verbraucht, sinkt eine Ebene; eine höhere Ebene verdrängt (der Verdrängte behält seinen Rest); Priority Boost alle S Zeiteinheiten. Quanten und S sind einstellbar, die Ebene steht als Q0/Q1/Q2 im Gantt
Linux CFS / EEVDF(Experte)
Fair (SCHED_OTHER)
—
CFS: kleinste vruntime zuerst. EEVDF (ab Linux 6.6): früheste virtuelle Deadline unter den „eligible“ Tasks
SCHED_FIFO / SCHED_RR(Experte)
Linux Echtzeit
RR: ✓
Statische RT-Prioritäten; FIFO ohne, RR mit Zeitscheibe innerhalb einer Prioritätsstufe
SCHED_DEADLINE(Experte)
Linux Echtzeit
—
EDF mit Budget-Überwachung (Constant Bandwidth Server)
Abb. 2 – Dieselbe Last, drei Verfahren (P1: a=0, C=7 · P2: a=2, C=4 · P3: a=4, C=1 · P4: a=5, C=4; Lehrbuchbeispiel nach Silberschatz). Werte aus der Simulator-Engine. SJF senkt die mittlere Wartezeit gegenüber FCFS, SRTF (preemptiv) senkt sie weiter und verbessert vor allem die Reaktionszeit – um den Preis von mehr Kontextwechseln (5 statt 3).
Algorithmen im Quellcode
Jeder Ein-Kern-Algorithmus steht in einer eigenen, kommentierten Datei sim_modules/algorithms/<id>.js (z. B. rr.js, edf.js). Genau dieser Code berechnet den Ablauf im Simulator: Wer eine Datei ändert und die Seite neu lädt, sieht das Ergebnis sofort im Gantt. Eigene Algorithmen lassen sich als weitere Datei ergänzen und erscheinen im Expertenmodus automatisch als Button. Schnittstelle und ein vollständiges Beispiel (HRRN) stehen in sim_modules/README.md.
Systemparameter
Quantum: Zeitscheibe für RR (Standard: 2). Größeres Q → weniger Kontextwechsel, schlechtere Reaktionszeit
Preemptiv: nur für Priority (Standard an); an = höher priorisierte Ankünfte verdrängen den laufenden Prozess
Seed: Startwert für alle Zufallsentscheidungen (zufällige Ausführungszeiten). Gleicher Seed = gleicher Ablauf, auch über geteilte Links; 🎲 zieht einen neuen
Deadline-Miss: bei EDF, RM und LLF „Job rechnet weiter“ (Standard) oder „Job wird abgebrochen“: Ein Job, der seine Frist erreicht, ohne fertig zu sein, wird verworfen und zählt als Miss (Konvention der BS1-Folien)
Cores: Anzahl simulierter CPU-Kerne (1–8). Bei mehr als einem Kern simuliert der Scheduler-Tab automatisch mit Global SMP.
Dauer: Auto (bis alle Jobs fertig) oder Manuell mit t_max (begrenzt auch die Job-Erzeugung periodischer Tasks)
Mutex-Protokoll: Legacy, Inversion (ohne Schutz) oder Priority Inheritance (PIP), wirkt im Priority-Scheduler
δ_cs: Kontextwechsel-Overhead pro Wechsel (0–5 in 0,5-Schritten), im Gantt als graues Band „C“. Fließt in Wartezeit, Turnaround, Reaktionszeit und CPU-Auslastung ein
δ_sched: Scheduler-Overhead pro Dispatch-Entscheidung, im Gantt als violettes Band „S“
U = CPU_busy_time / (totalTime × numCores)
Gantt-Diagramm & Overlays
Steuerleiste
⏮ ▶ ⏭ — Schritt zurück / Play-Pause / Schritt vor
Speed-Slider — Animationsgeschwindigkeit
− / + / 1:1 — Gantt-Zoom (auch per Mausrad über dem Diagramm)
👁 Ansichten ▾ — Zusatzansichten ein-/ausblenden: Erklärmodus, Ready-Queue, Explain-Timeline, Zustandsdiagramm, Core-Ansicht (ab 2 Cores) und im Expertenmodus der Deadline-Debugger. Die Zahl in Klammern zeigt, wie viele aktiv sind.
🎯 Predict — eigenen Gantt vorhersagen und mit dem Ergebnis vergleichen; ⬇ PNG exportiert das Diagramm als Bild
Links neben jeder Zeile stehen Prozessname, ein kleiner Auslastungsbalken mit Prozentwert und bei Deadline-Verletzung „⚠ miss“. Ein Klick auf einen Block oder ein Symbol öffnet den Tooltip mit Details.
Abb. 3 – Symbole im Gantt. Alle Overlays lassen sich in der Karte Gantt-Overlay einzeln schalten. Ein Klick auf einen Block oder ein Symbol zeigt Details im Tooltip.
Ein-/Ausblendbare Overlays
Die Overlays werden in der linken Karte Gantt-Overlay geschaltet (standardmäßig zugeklappt).
Overlay
Darstellung
Sync-Ereignisse
Kritischer Abschnitt (Mutex gehalten) und Blockierung. Kritischer Abschnitt im Modern-Skin: Prozessfarbe, schraffiert, Amber-Rahmen, 🔒; im HM-Skin gelb-orange. Blockiert: rot schraffiert mit „BLOCK“.
Ressourcen-Zeile
Eigene Spur pro Mutex unter den Prozessen: wer hält den Lock wann, wer wartet
DVFS-Frequenz
Frequenzverlauf als Linie unterhalb der Zeitachse
Core-Migrationen
Pfeile zwischen Kernen (Multi-Core-Gantt)
Deadlines
Raute mit „D“ und gestrichelter Linie bei jeder absoluten Deadline, in Prozessfarbe, rot bei Miss
Ankunftszeiten
Grünes Dreieck bei jeder Job-Ankunft (Folgejobs blasser)
Deadline-Misses
Rote Spanne von der Deadline bis zur Fertigstellung, ✕ am Ende
Perioden-Grenzen
Gestrichelte Linien in Prozessfarbe mit „T“ an jedem Periodenende
Reaktionszeit
Gestrichelter Pfeil von der Ankunft bis zum ersten CPU-Zugriff mit „R=…“
Ctx-Switch-Overhead
Band über alle Zeilen: grau „C“ = Kontextwechsel, violett „S“ = Scheduler
Kritischer Pfad
Laxity-Farbstreifen am linken Rand jedes Blocks, siehe Kritischer Pfad
Metriken-Panel
Erscheint nach jeder Simulation unterhalb des Gantts, einklappbar über den Titel-Balken. Ein Klick auf eine Kennzahl erklärt sie.
Zusammenfassungs-Chips
Im Lernmodus sind fünf Kernmetriken sichtbar (Ø Wartezeit, Ø Response, Ø Turnaround, CPU-Util., Deadline-Misses); „+N weitere“ zeigt den Rest.
Metrik
Formel
CPU-Util.
Σ(CPU-Blöcke) / (totalTime × Cores)
Durchsatz
fertige Prozesse / totalTime (P/t)
Ø Wartezeit
Σ(TAT_i − C_i) / n
Ø Response
Σ(firstCPU_i − arrival_i) / n (Reaktionszeit)
Ø Turnaround
Σ(finish_i − arrival_i) / n
Ø NTT
TAT_i / C_i gemittelt (normierte Turnaround-Zeit, 1,0 = nie gewartet)
(Σx_i)² / (n · Σx_i²) mit x_i = CPU-Anteil von Prozess i; 1,0 = alle gleich, 1/n = einer bekommt alles
OH-Anteil
Overhead-Zeit / Gesamtzeit (Summe der C- und S-Bänder)
Grafiken im Panel
Verteilungs-Histogramm — Response-, Warte- oder Turnaround-Zeiten (umschaltbar), wahlweise als Häufigkeit oder CDF, mit Median, Mittelwert, Streuung und p95. Erscheint ab zwei Datenpunkten, bei mindestens drei Jobs je Job.
Jitter-Verlaufskurve — Response-Zeit je Job-Instanz über die Zeit für periodische Tasks (ab 2 Instanzen).
Messreihe:＋ Lauf festhalten übernimmt die aktuelle Simulation als Tabellenzeile (Algorithmus, Parameter, Kernmetriken, Makespan); der beste Wert je Spalte ist hervorgehoben. ▶ Sweep simuliert das Szenario für einen Parameterbereich (Quantum, δ_cs oder Cores) und zeigt den Verlauf als Diagramm. ⬇ CSV exportiert die Tabelle für Excel/LibreOffice, z. B. für Praktikumsabgaben.
Automatische Schedulierbarkeitsanalyse
Bei EDF, RM oder LLF und immer, wenn alle Tasks eine Periode haben, prüft der Scheduler-Tab das Taskset analytisch und vergleicht mit der Simulation:
Test
Bedingung
Aussagekraft
Liu & Layland
Σ C_i/T_i ≤ n(2^(1/n) − 1)
hinreichend für RM
Hyperbolic Bound
Π (C_i/T_i + 1) ≤ 2
hinreichend für RM, schärfer als Liu & Layland
EDF
Σ C_i/D_i ≤ 1
exakt bei D = T, sonst hinreichend
RTA
WCRT je Task in RM-Reihenfolge (kürzeste Periode zuerst)
exakt für RM bei D ≤ T
🎲 Taskset-Generator (UUniFast)
Header-Button 🎲 Taskset-Gen. Generiert zufällige periodische Tasksets mit vorgegebener Gesamtauslastung.
Parameter
Parameter
Beschreibung
n
Anzahl Tasks (2–12)
U (%)
Ziel-Gesamtauslastung 10–99 %
T_min / T_max
Periodenbereich
Generator-Profil
Balanced (Perioden gleichverteilt), Bursty (mehr kurze Perioden, einige Tasks mit hoher Last), Harmonic (Perioden als Vielfache einer Basis)
Task-Mix
Nur periodisch, Gemischt oder Sporadic-heavy
Seed
Mit „Seed fixieren“ ist das Taskset reproduzierbar, z. B. für Übungsblätter
Deadline-Typ
Implizit (D = T) / Constrained (C ≤ D ≤ T) / Arbiträr (D kann größer als T sein)
Algorithmus
EDF, Rate Monotonic, Round Robin oder FCFS; wird für die Simulation übernommen
UUniFast-Algorithmus
Erzeugt gleichverteilte Auslastungsvektoren mit Σ U_i = U (Bini & Buttazzo, 2005):
sumU = U_total
for i = 1 to n-1:
nextSumU = sumU × rand(0,1)^(1/(n-i))
U_i = sumU - nextSumU
sumU = nextSumU
U_n = sumU
Daraus folgt C_i = round(U_i · T_i), mindestens 1. Die Vorschau zeigt Σ U, die Liu-&-Layland-Schranke und die EDF-Schedulierbarkeit. 🎲 Generieren erzeugt einen neuen Satz, ✓ Übernehmen & Simulieren lädt ihn.
Prioritäten und Auslastung: Die Prioritäten werden nach Rate Monotonic vergeben (kürzeste Periode = 1). Die Vorschau zeigt die tatsächliche Auslastung nach dem Runden von C und daneben die Ziel-Auslastung; bei Deadline-Typ Constrained/Arbiträr prüft sie EDF mit dem (nur hinreichenden) Dichte-Test Σ C/min(D,T) ≤ 1.
⚖ A/B Vergleichsmodus
Tab ⚖ A/B Vergleich. Führt dasselbe Prozess-Set mit zwei Algorithmen aus und stellt die Ergebnisse direkt gegenüber.
Workflow
Prozesse im Scheduler-Tab anlegen (oder Beispiel laden)
A/B-Tab öffnen → Algorithmus A und B wählen
Quantum für beide einstellen
⚖ Vergleichen klicken; mit Live-Vergleichsmodus laufen beide Gantts schrittweise synchron
Ausgabe
Gantt-Vergleich: beide Timelines übereinander auf derselben Zeitachse
Metriken-Tabelle: Ø Wartezeit, Ø Response, Ø Turnaround, CPU-Auslastung, Ctx-Switches; der bessere Wert ist hervorgehoben
Tipp: Lade das Lehr-Beispiel „Konvoi-Effekt“ und vergleiche FCFS mit SJF: Der Effekt ist sofort sichtbar.
🧮 WCRT-Analyse (Response Time Analysis)
Im Tab 📈 Statistiken, Karte 🧮 WCRT-Analyse → ▶ Berechnen. Berechnet die Worst-Case Response Time (Freigabe bis Fertigstellung) aller Tasks.
hp(i) = alle Tasks mit höherer Priorität als τ_i. Die Reihenfolge richtet sich nach dem gewählten Algorithmus: bei Priority, SCHED_FIFO und SCHED_RR nach dem Feld Priorität (1 = höchste), sonst nach Rate Monotonic (kürzeste Periode zuerst). Die verwendete Reihenfolge steht über der Tabelle. Die automatische Analyse im Scheduler-Tab rechnet immer mit RM-Reihenfolge und liefert dann dieselben Werte.
Ausgabe-Spalten
Spalte
Bedeutung
C
Execution Time
T
Periode (ohne Periode wird mit T = 100 gerechnet)
D
Relative Deadline
U
Auslastung C/T
WCRT R*
Berechnete Worst-Case Response Time (∞ = Iteration divergiert)
Slack
D − R* (positiv = Puffer vorhanden)
Gültigkeit: Die RTA ist exakt für preemptive feste Prioritäten (RM, DM) mit D ≤ T, unabhängigen Tasks und gleichzeitiger erster Freigabe. Blockierung durch Mutexe ist nicht eingerechnet. Für EDF mit D = T gilt stattdessen: schedulierbar genau dann, wenn Σ U_i ≤ 1.
⚡ Kritischer Pfad / Laxity-Heatmap
Overlay-Checkbox in der Karte Gantt-Overlay. Zeigt die Laxity jedes Blocks zu seinem Startzeitpunkt als Farbstreifen am linken Blockrand.
Laxity(τ_i, t) = d_i − t − rem_C(τ_i) d_i = absolute Deadline des Jobs
Farbe
Bedeutung
Grün
Hohe Laxity (mehr als ⅔ des Spielraums übrig) — Task liegt gut im Zeitplan
Gelb
Mittlere Laxity — Aufmerksamkeit empfohlen
Rot
Geringe Laxity; bei L ≤ 0 zusätzlich roter gestrichelter Rahmen: Deadline-Miss unvermeidlich
Blöcke mit L ≤ 2 tragen die Beschriftung „L=…“. Der Block mit der global niedrigsten Laxity wird mit ⚡ L=X.X annotiert.
Anwendung: Bei EDF, RM oder LLF aktivieren. Laxity = 0 bedeutet: Dieser Task muss sofort laufen. Vergleiche die Verfahren: Welches hält die Laxity stabiler?
📐 Schedulierbarkeits-Rechner
Im Tab 📈 Statistiken. Interaktiver Chart der Auslastungsschranken; über Algo lassen sich RM, EDF oder beide anzeigen.
Abb. 4 – Auslastungsschranken. Unterhalb der Liu-&-Layland-Kurve ist RM garantiert schedulierbar. Die Schranke ist nur hinreichend: Darüber (gelbe Zone) kann RM trotzdem funktionieren, z. B. bei harmonischen Perioden bis 100 %. Dort entscheidet die exakte Response-Time-Analyse.
Anzeige
Kurve — Liu & Layland RM-Schranke n(2^(1/n) − 1), gegen ln 2 ≈ 69,3 % für n → ∞
Waagrechte Linie — EDF-Grenze U = 100 %
Punkt — aktuelles Taskset: grün = unter der RM-Schranke, gelb = nur EDF garantiert, rot = Überlast
Interaktive Slider
Unter dem Chart lässt sich U_i der ersten acht Tasks per Slider ändern; der Punkt wandert mit. Die Slider arbeiten auf einer Kopie, das Szenario bleibt unverändert.
Im Menü 👁 Ansichten ▾ → 📖 Erklärmodus über dem Gantt. Zeigt für jeden Simulationsschritt, warum der aktuelle Task gewählt wurde.
Beispiele nach Algorithmus
Algorithmus
Beispiel-Erklärung
FCFS
P1 ist an erster Stelle der Warteschlange (Ankunft t=0). Läuft bis Fertig.
EDF
P3 hat die früheste Deadline (D=8). Ready-Queue: [P1(D=12), P3(D=8)].
RR
P2 ist an der Reihe. Zeitscheibe Q=2. Ready: [P1, P2, P3].
RM
P2 hat kürzeste Periode (T=5) = höchste Priorität. Ready: [P1(T=10), P2(T=5)].
Priority
P1 hat höchste Priorität (Prio=1). Ready: [P1(P=1), P3(P=3)].
Bei Overhead-Blöcken wird Typ und Dauer angezeigt (δ_cs oder δ_sched).
💾 Preset-Bibliothek
Header-Button 💾 Presets. Szenarien lokal speichern, verwalten und teilen.
Features
Speichern: Aktuelles Szenario mit Namen versehen → sofort in der Liste
Laden/Löschen: Per Knopfdruck in der Liste
Export: Alle Presets als JSON-Datei herunterladen
Import: JSON-Datei einlesen und mit bestehenden zusammenführen
🔗 Share-URL: Generiert eine URL mit dem aktuellen Szenario als Base64-Hash. Beim Öffnen des Links wird es automatisch geladen.
Tipp: Presets werden im localStorage des Browsers gespeichert — beim Löschen des Browser-Caches gehen sie verloren. Für dauerhafte Archivierung regelmäßig exportieren.
🖥 Multi-Core Simulation
Tab 🖥 Multi-Core (Expertenmodus): Kernanzahl, Basis-Algorithmus (RR, FCFS, SJF, Priority, EDF), Quantum und Seed wählen, dann eine Strategie. Zwei Strategien lassen sich direkt vergleichen.
Abb. 5 – Queue-Topologien. Global verteilt Last am besten, kostet aber Migrationen; partitioniert vermeidet Migrationen, kann aber Kerne leer laufen lassen; Work Stealing liegt dazwischen. Gang Scheduling startet alle Threads eines Prozesses gleichzeitig auf mehreren Kernen.
Strategie
Beschreibung
Global SMP
Eine globale Ready-Queue, alle Kerne teilen sich die Tasks
Partitioned
Feste Kernzuordnung per Affinität, keine Migration
Work Stealing
Leer laufende Kerne holen Tasks aus den Queues anderer Kerne
Gang Scheduling
Threads eines Prozesses laufen gleichzeitig auf mehreren Kernen
G-EDF
Globales EDF: die m frühesten Deadlines laufen auf den m Kernen
P-EDF
Partitioniertes EDF mit Bin-Packing-Zuweisung
Schnell-Setup: Im Scheduler-Tab unter Systemparameter Cores > 1 setzen → ▶ Simulieren: Das Szenario läuft dann automatisch mit Global SMP.
Die CPU-Auslastung ist core-normalisiert: U = busy / (totalTime × n_cores). Migrationen erscheinen im Gantt als Pfeile (Overlay „Core-Migrationen“).
⚡ DVFS (Dynamic Voltage/Frequency Scaling)
Tab ⚡ DVFS (Expertenmodus). Leitet aus der Auslastung des berechneten Schedules einen Frequenzverlauf ab und schätzt die Energie.
P ∝ f³ (CMOS-Näherung) E = Σ f(t)³ · Δt f relativ zu f_max
Governor
Verhalten im Simulator
Performance
Immer f_max
Powersave
Immer f_min
Ondemand
f_max ab der Lastschwelle, darunter proportional zur Last
Conservative
Schritte von 10 % des Bereichs: hoch ab der Schwelle, runter unter der halben Schwelle
Schedutil
f proportional zur aktuellen Auslastung (Linux ab 4.7)
Interactive
f_max, solange in den letzten Zeiteinheiten Last anlag, sonst f_min
Einstellbar sind Min- und Max-Frequenz (in % von f_max), die Lastschwelle und optional diskrete P-States als kommagetrennte Prozentliste (Standard 25,50,75,100).
Modellgrenze: Die Frequenz verändert hier nicht die Ausführungszeiten; der Schedule bleibt gleich. Deshalb spart „Powersave“ im Simulator immer am meisten. Real verlängert eine niedrige Frequenz die Rechenzeit, und oft ist „race to idle“ (schnell rechnen, dann schlafen) sparsamer.
🔒 Synchronisierung
Im Scheduler-Tab
Prozesse können ein Mutex (mutex_0 … mutex_2) belegen; dann läuft der ganze Job als kritischer Abschnitt. Blockierte Prozesse erscheinen im Gantt rot schraffiert, die Ressourcen-Zeile zeigt die Lock-Belegung. Das Mutex-Protokoll (Systemparameter) bestimmt, ob Prioritätsinversion auftritt oder durch Priority Inheritance verhindert wird.
⬇ Export: Speichert Prozesse, Konfiguration und Simulations-Meta als JSON-Datei
⬆ Import ▾ → Datei öffnen: Lädt eine exportierte JSON-Datei und stellt den Zustand wieder her
⬆ Import ▾ → JSON einfügen: Szenario-JSON direkt einfügen, z. B. den Szenario-Block aus einer Übungsaufgabe (auch mit Markdown-Codeblock); Fehler werden im Dialog angezeigt
Szenario-Links:#scenario=<Base64> oder #example=<id> in der Adresse lädt ein Szenario bzw. Lehrbeispiel. Zusätze: &autorun=0 (laden ohne Ergebnis, ▶ startet; in den Presets: „ohne Ergebnis teilen“), &embed=1 (reduzierte Ansicht für ein iframe, z. B. auf Folien), &theme=light|dark. Details in der README.
💾 Presets: Für dauerhaftes Speichern und Teilen (siehe Preset-Bibliothek)
Tipp: Exportiere interessante Konfigurationen vor dem Experimentieren, um zur Ausgangslage zurückzukehren.
🐧 Trace-Import (Expertenmodus)
Über 🐧 Trace ▾ lassen sich aufgezeichnete Scheduler-Abläufe echter Systeme einlesen und als Gantt darstellen:
🧾 Trace importieren: Linux sched_switch-Ereignisse aus ftrace/trace-cmd (Text), kanonisches JSON oder CSV
🧪 LTTng-JSON importieren: Kernel-Traces aus LTTng (über Babeltrace als JSON exportiert)
❓ Trace-Formate: Beschreibung der erwarteten Felder mit Beispielen
🐧 Linux-Trace: ON/OFF schaltet zwischen dem importierten Trace und der Simulation um
Beispiel-Traces liegen im Repository unter trace_examples/.
📂 Lehr-Beispiele
22 vorgefertigte Szenarien in 7 Kategorien. Öffnen über den Header-Button 📂 Beispiele. Nach dem Laden erscheint rechts ein Analyse-Leitfaden mit Beobachtungshinweisen, klickbaren Experiment-Buttons und Theorie-Hintergrund.
Musterlösungen mit Gantt-Diagramm, Kennzahlen aller Experimente und Erklärung stehen unter ✅ Lehrbeispiele – Lösungen. Die klassischen Beispiele (Konvoi, SJF/SRTF, RR, MLQ, Kontextwechsel, Multi-Core, DAG) bestehen aus einmaligen Prozessen wie im Lehrbuch; die Echtzeit-Beispiele aus periodischen Tasks.
Für Übungsaufgaben: Szenarien lassen sich als Link mit #scenario=… verteilen (siehe Share-URL in den Presets); ein Klick öffnet sie direkt im Simulator.
✅ Lehrbeispiele – Lösungen
Zu jedem Lehrbeispiel: Szenario, der vom Simulator berechnete Ablauf, die Kennzahlen des Basis-Laufs und aller Experimente sowie eine Erklärung. Die Werte gelten für die Standard-Einstellungen (keine Overhead-Kosten, sofern nicht anders angegeben). Gantt-Bilder zeigen periodische Szenarien bis t = 60. Ein Klick auf einen Titel klappt die Lösung auf.
Für Übungen: Erst selbst das Gantt-Diagramm zeichnen und Ø W / Ø R berechnen, dann hier vergleichen. Mit 🎯 Predict lässt sich das auch direkt im Simulator prüfen.
🚛 Konvoi-Effekt (FCFS)Klassisch
Ein langer CPU-Burst blockiert alle kurzen Prozesse dahinter. Das Herzstück von FCFS's Schwäche.
Szenario
Prozess
Ankunft
C
Prio
D
Typ
CPU-Last
0
20
1
30
einmalig
IO-1
1
2
1
25
einmalig
IO-2
2
2
1
25
einmalig
IO-3
3
2
1
25
einmalig
Algorithmus FCFS
Lösung
Basis-Lauf (FCFS).
Lauf
Einstellung
Ø W
Ø R
Ø TAT
CPU-Util.
Wechsel
Deadline-Misses
Basis
FCFS
15,00
15,00
21,50
100.0%
3
0
Vergleich: SJF (non-preemptiv)
SJF
15,00
15,00
21,50
100.0%
3
0
Vergleich: SRTF (preemptiv)
SRTF
2,25
0,75
8,75
100.0%
4
0
Round Robin Q=2
Round Robin, Q=2
3,50
2,00
10,00
100.0%
5
0
Erklärung
FCFS arbeitet strikt in Ankunftsreihenfolge: CPU-Last belegt die CPU von 0 bis 20, danach laufen IO-1 bis IO-3 je 2 Zeiteinheiten. Die kurzen Prozesse warten 19, 20 und 21 Zeiteinheiten, Ø W = 60/4 = 15. SJF ändert nichts, weil bei t = 0 nur CPU-Last bereit ist und SJF nicht verdrängt. SRTF verdrängt CPU-Last bei t = 1 und senkt Ø W auf 2,25, RR (Q = 2) auf 3,5. Merksatz: Der Konvoi entsteht durch fehlende Verdrängung, nicht durch die Auswahlregel.
⚖️ SJF vs. SRTFKlassisch
Non-preemptives SJF lässt laufende Jobs zu Ende; SRTF verdrängt sie sofort wenn ein kürzerer ankommt. Unterschied in Ø Wartezeit und Reaktionszeit.
Szenario
Prozess
Ankunft
C
Prio
D
Typ
P_lang
0
8
1
20
einmalig
P2
2
3
1
15
einmalig
P3
4
2
1
12
einmalig
P4
5
1
1
10
einmalig
Algorithmus SJF · Quantum 1
Lösung
Basis-Lauf (SJF).
Lauf
Einstellung
Ø W
Ø R
Ø TAT
CPU-Util.
Wechsel
Deadline-Misses
Basis
SJF
4,25
4,25
7,75
100.0%
3
0
Wechsel zu SRTF
SRTF
2,00
0,50
5,50
100.0%
4
0
Wechsel zu SJF
SJF
4,25
4,25
7,75
100.0%
3
0
δ_cs = 0.5 (Overhead)
SRTF
3,25
1,25
6,75
87.5%
4
0
Vergleich: FCFS
FCFS
5,25
5,25
8,75
100.0%
3
0
Erklärung
SJF: P_lang ist bei t = 0 allein und läuft durch (0–8). Danach entscheidet die kürzeste Rechenzeit: P4 (8–9), P3 (9–11), P2 (11–14). Wartezeiten 0, 9, 5, 3 → Ø W = 4,25. SRTF: Bei t = 2 hat P2 (3) weniger Restzeit als P_lang (6) und verdrängt ihn; danach P4 (5–6), P3 (6–8), P_lang ab t = 8. Wartezeiten 6, 0, 2, 0 → Ø W = 2,00, dafür 4 statt 3 Kontextwechsel. FCFS liegt bei 5,25. Mit δ_cs = 0,5 steigt SRTF auf 3,25 und bleibt hier trotzdem vorn.
⏱️ Round Robin: Quantum-EffektKlassisch
Das Zeitquantum Q bestimmt den Tradeoff zwischen Reaktionszeit und Overhead. Zu klein = Thrashing, zu groß = degeneriert zu FCFS.
Szenario
Prozess
Ankunft
C
Prio
D
Typ
P1
0
8
1
100
einmalig
P2
1
5
1
100
einmalig
P3
2
3
1
100
einmalig
P4
0
6
1
100
einmalig
Algorithmus Round Robin · Quantum 2
Lösung
Basis-Lauf (Round Robin, Q = 2).
Lauf
Einstellung
Ø W
Ø R
Ø TAT
CPU-Util.
Wechsel
Deadline-Misses
Basis
Round Robin, Q=2
12,75
2,25
18,25
100.0%
11
0
Quantum = 1
Round Robin, Q=1
12,00
1,00
17,50
100.0%
20
0
Quantum = 2 (Start)
Round Robin, Q=2
12,75
2,25
18,25
100.0%
11
0
Quantum = 5
Round Robin, Q=5
12,75
6,75
18,25
100.0%
5
0
δ_cs = 0.5 + Q=1
Round Robin, Q=1
20,50
1,88
26,00
68.8%
20
0
Erklärung
Ablauf mit Q = 2 (FIFO-Ready-Queue, neue Prozesse reihen sich vor dem verdrängten ein): P1, P4, P2, P3, P1, P4, P2, P3, P1, P4, P2, P1. Das Quantum verschiebt vor allem die Reaktionszeit und die Zahl der Wechsel: Q = 1 → Ø R 1,0 bei 20 Wechseln, Q = 2 → 2,25 bei 11, Q = 5 → 6,75 bei 5. Die mittlere Wartezeit bleibt fast gleich (12,0–12,75). Kosten Wechsel Zeit (δ_cs = 0,5), steigt Ø W bei Q = 1 von 12,0 auf 20,5: Ein zu kleines Quantum wird teuer.
⏳ Starvation & Priority SchedulingKlassisch
Niedriger priorisierte Prozesse "verhungern" wenn ständig höher priorisierte ankommen. Das Problem und seine Lösung (Aging) sind Kernthema im OS-Design.
Szenario
Prozess
Ankunft
C
Prio
T
D
Typ
HP-1
0
8
1
20
20
periodisch
HP-2
2
6
1
15
15
periodisch
HP-3
4
5
2
20
20
periodisch
LP-1
0
4
5
30
30
periodisch
Algorithmus Priority · Preemptiv · periodische Jobs bis t = 60
Lösung
Basis-Lauf (Priority) — Ausschnitt bis t = 60.
Lauf
Einstellung
Ø W
Ø R
Ø TAT
CPU-Util.
Wechsel
Deadline-Misses
Basis
Priority
15,25
12,42
21,17
100.0%
11
4 (HP-3: d=24→39, HP-3: d=44→58, LP-1: d=30→67 …)
Vergleich: Round Robin
Round Robin, Q=3
16,08
6,33
22,00
100.0%
24
9 (HP-1: d=20→21, HP-1: d=40→48, HP-1: d=60→71 …)
Vergleich: FCFS
FCFS
11,00
11,00
16,92
100.0%
11
4 (HP-2: d=17→18, HP-2: d=47→52, HP-2: d=62→71 …)
Alle gleiche Priorität
Priority
11,00
11,00
16,92
100.0%
11
4 (HP-2: d=17→18, HP-2: d=47→52, HP-2: d=62→71 …)
Erklärung
Die drei HP-Tasks allein lasten die CPU zu 105 % aus (8/20 + 6/15 + 5/20). Bei strikter Priorität bekommt LP-1 deshalb erst ab t = 63 Rechenzeit, als im Simulationsfenster keine neuen HP-Jobs mehr ankommen. Es ist echte Starvation, beide LP-Jobs verpassen ihre Deadline. Mit RR (Q = 3) läuft LP-1 schon bei t = 3, mit FCFS oder gleicher Priorität bei t = 8. Die Überlast verschwindet dadurch nicht, sie verteilt sich auf alle Tasks (RR: 9 Misses). Aging würde LP-1 nach einer Wartezeit hochstufen.
🗂️ Multi-Level Queue (MLQ)Klassisch
Prozesse werden in Queues unterschiedlicher Priorität eingeteilt. Queue-0 läuft mit kleinem Quantum (interaktiv), Queue-2 mit großem Quantum (Batch).
Szenario
Prozess
Ankunft
C
Prio
D
Typ
Weiteres
System
0
3
1
100
einmalig
Queue 0
Interactive
1
5
2
100
einmalig
Queue 1
Interactive2
3
4
2
100
einmalig
Queue 1
Batch
0
10
3
100
einmalig
Queue 2
Algorithmus MLQ · Quantum 2
Lösung
Basis-Lauf (MLQ, Q = 2).
Lauf
Einstellung
Ø W
Ø R
Ø TAT
CPU-Util.
Wechsel
Deadline-Misses
Basis
MLQ
5,50
4,50
11,00
100.0%
4
0
Vergleich: Round Robin
Round Robin, Q=2
9,00
2,25
14,50
100.0%
10
0
Vergleich: FCFS
FCFS
7,50
7,50
13,00
100.0%
3
0
Batch erst später
MLQ
3,00
2,00
8,50
100.0%
4
0
Erklärung
System (Queue 0) läuft zuerst (0–3). Interactive und Interactive2 (Queue 1) teilen sich die CPU mit Q = 4: 3–7, 7–11, 11–12. Batch (Queue 2) startet erst bei t = 12, als die höheren Queues leer sind, und läuft durch. Ø W = 5,5. Mit FCFS läuft Batch schon bei t = 3 und hält die interaktiven Prozesse bis t = 13 auf (Ø W 7,5). Mit RR sinkt die Reaktionszeit (2,25), die Wartezeit steigt aber auf 9,0. Kommt Batch erst bei t = 10, sinkt seine Wartezeit auf 2.
🔒 PrioritätsinversionSynchronisierung
LP hält Mutex, HP braucht ihn → HP blockiert, MP läuft stattdessen. Klassisches Mars Pathfinder-Problem. Lösung: Priority Inheritance Protocol (PIP).
Szenario
Prozess
Ankunft
C
Prio
T
D
Typ
Weiteres
HP
4
3
1
20
10
periodisch
Mutex 0
MP
2
5
2
20
20
periodisch
—
LP
0
8
3
30
30
periodisch
Mutex 0
Algorithmus Priority · Mutex-Protokoll Inversion (ohne Schutz) · Preemptiv · periodische Jobs bis t = 60
Lösung
Basis-Lauf (Priority) — Ausschnitt bis t = 60. Amber-Rahmen = kritischer Abschnitt.
Lauf
Einstellung
Ø W
Ø R
Ø TAT
CPU-Util.
Wechsel
Deadline-Misses
Basis
Priority
2,50
1,13
7,50
80.0%
10
1 (HP: d=14→16)
Mit PIP (Priority Inheritance)
Priority
2,88
0,75
7,88
80.0%
10
0
Ohne Schutz (Inversion)
Priority
2,50
1,13
7,50
80.0%
10
1 (HP: d=14→16)
Ohne Mutex (kein Block)
Priority
2,13
0,00
7,13
80.0%
11
0
Erklärung
LP sperrt Mutex 0 bei t = 0. MP (Priorität 2) verdrängt LP bei t = 2, noch bevor HP ankommt. HP erscheint bei t = 4, braucht Mutex 0 und muss warten. Ohne Schutz läuft zuerst MP (bis 7), dann LP bis zur Freigabe bei t = 13. HP rechnet 13–16 und verpasst seine Deadline 4 + 10 = 14. Mit Priority Inheritance erbt LP ab t = 4 die Priorität von HP, verdrängt MP und gibt den Mutex bei t = 10 frei. HP ist bei t = 13 fertig, rechtzeitig. Die Inversionszeit sinkt von 9 auf 6 Zeiteinheiten. Ohne Mutex startet HP sofort bei t = 4.
⧖ Kontextwechsel-OverheadSynchronisierung
Jeder Kontextwechsel kostet Zeit (Register speichern/laden, TLB flush, Cache-Pollution). Zu viele Wechsel schaden dem Durchsatz — sichtbar mit δ_cs.
Szenario
Prozess
Ankunft
C
Prio
D
Typ
P1
0
6
1
100
einmalig
P2
0
4
1
100
einmalig
P3
0
5
1
100
einmalig
P4
0
3
1
100
einmalig
Algorithmus Round Robin · Quantum 2
Lösung
Lauf mit δ_cs = 0,5: graue Lücken = Kontextwechsel.
Lauf
Einstellung
Ø W
Ø R
Ø TAT
CPU-Util.
Wechsel
Deadline-Misses
Basis
Round Robin, Q=2
11,00
3,00
15,50
100.0%
9
0
δ_cs = 0 (kein Overhead)
Round Robin, Q=2
11,00
3,00
15,50
100.0%
9
0
δ_cs = 0.5
Round Robin, Q=2
14,63
3,75
19,13
80.0%
9
0
δ_cs = 1.0
Round Robin, Q=2
18,25
4,50
22,75
66.7%
9
0
Q=1 + δ_cs=0.5
Round Robin, Q=1
17,88
2,25
22,38
67.9%
17
0
FCFS + δ_cs=0.5
FCFS
8,50
8,50
13,00
92.3%
3
0
Erklärung
Vier gleichzeitig ankommende Prozesse unter RR (Q = 2) erzeugen 9 Wechsel. Jeder Wechsel kostet δ_cs und verschiebt alles Folgende: Ø W steigt von 11,0 (δ_cs = 0) auf 14,6 (0,5) und 18,3 (1,0), der produktive Anteil der CPU sinkt auf 80 % bzw. 67 %. Halbiert man zusätzlich das Quantum (Q = 1, 17 Wechsel), wird es noch teurer. FCFS braucht nur 3 Wechsel und kommt mit δ_cs = 0,5 auf Ø W 8,5.
📡 EDF vs. Rate MonotonicEchtzeit
Utilization U ≈ 94% liegt über der RM-Grenze für n=3 (~78%). RM kann Deadlines verpassen, EDF hält sie in diesem Set ein.
Szenario
Prozess
Ankunft
C
Prio
T
D
Typ
τ1
0
3
1
7
7
periodisch
τ2
0
2
2
5
5
periodisch
τ3
0
1
3
9
9
periodisch
Algorithmus Rate Monotonic · Quantum 1 · periodische Jobs bis t = 60
Lösung
Basis-Lauf (Rate Monotonic) — Ausschnitt bis t = 60.
Lauf
Einstellung
Ø W
Ø R
Ø TAT
CPU-Util.
Wechsel
Deadline-Misses
Basis
Rate Monotonic
1,54
1,32
3,61
96.7%
28
2 (τ3: d=9→13, τ3: d=45→48)
Rate Monotonic (RM)
Rate Monotonic
1,54
1,32
3,61
96.7%
28
2 (τ3: d=9→13, τ3: d=45→48)
EDF (optimal)
EDF
1,25
1,11
3,32
96.7%
28
0
Vergleich: FCFS
FCFS
1,25
1,25
3,32
96.7%
27
0
Erklärung
U = 3/7 + 2/5 + 1/9 ≈ 94 % liegt über der RM-Schranke 78 % (n = 3). Unter RM hat τ3 (längste Periode) die niedrigste Priorität. Sein erster Job (Deadline t = 9) kommt erst bei t = 12 dran und ist bei t = 13 fertig; der zweite Miss folgt bei t = 45 → 48. EDF entscheidet nach der absoluten Deadline und lässt τ3 bei t = 5 laufen: keine Misses. FCFS kommt bei diesem Set zufällig ebenfalls ohne Miss aus. Garantiert ist das nur bei EDF (U ≤ 100 %).
⚡ Sporadische & Aperiodische TasksEchtzeit
Periodische, sporadische (mit MIT) und aperiodische Tasks koexistieren. EDF reagiert dynamisch, FCFS kann Deadlines nicht garantieren.
Szenario
Prozess
Ankunft
C
Prio
T
D
Typ
Periodisch
0
2
1
8
8
periodisch
Sporadisch
1
2
1
—
4
sporadisch (MIT 6)
Aperiodisch
3
6
2
—
20
einmalig
Algorithmus EDF · Quantum 1 · periodische Jobs bis t = 60
Lösung
Basis-Lauf (EDF) — Ausschnitt bis t = 60.
Lauf
Einstellung
Ø W
Ø R
Ø TAT
CPU-Util.
Wechsel
Deadline-Misses
Basis
EDF
0,50
0,17
2,72
65.6%
19
0
EDF (dynamisch)
EDF
0,50
0,17
2,72
65.6%
19
0
FCFS (blind)
FCFS
0,56
0,56
2,78
65.6%
17
1 (Sporadisch: d=11→12)
Rate Monotonic
Rate Monotonic
0,56
0,11
2,78
65.6%
19
0
Erklärung
Der sporadische Task hat eine enge Deadline (D = 4). Sein zweiter Job kommt bei t = 7, absolute Deadline t = 11. Unter FCFS läuft da noch der aperiodische Job (C = 6, 4–10), der Sporadische ist erst bei t = 12 fertig: Miss. EDF unterbricht den aperiodischen Job (Deadline t = 23) zugunsten des Jobs mit Deadline 11, RM wegen der höheren statischen Priorität: beide ohne Miss. Dichte-Test für EDF: 2/8 + 2/4 + 6/20 = 1,05 > 1 ist nur hinreichend; das Set ist trotzdem schedulierbar.
📊 RM AuslastungsgrenzeEchtzeit
3 Tasks mit Gesamtauslastung U=100% in einem nicht-harmonischen Set: RM verpasst Deadlines, EDF schafft das Set. Demonstriert die Lücke zwischen RM-Bound und EDF-Bound.
Szenario
Prozess
Ankunft
C
Prio
T
D
Typ
τ1
0
2
1
5
5
periodisch
τ2
0
1
2
10
10
periodisch
τ3
0
6
3
12
12
periodisch
Algorithmus Rate Monotonic · Quantum 1 · periodische Jobs bis t = 60
Lösung
Basis-Lauf (Rate Monotonic) — Ausschnitt bis t = 60.
Lauf
Einstellung
Ø W
Ø R
Ø TAT
CPU-Util.
Wechsel
Deadline-Misses
Basis
Rate Monotonic
2,09
1,00
4,70
100.0%
29
4 (τ3: d=12→14, τ3: d=24→25, τ3: d=36→38 …)
Rate Monotonic (FAIL)
Rate Monotonic
2,09
1,00
4,70
100.0%
29
4 (τ3: d=12→14, τ3: d=24→25, τ3: d=36→38 …)
EDF (optimal, U=100%)
EDF
2,35
1,78
4,96
100.0%
28
0
Utilization auf 80% senken
Rate Monotonic
0,50
0,50
1,50
81.4%
36
0
Erklärung
U = 2/5 + 1/10 + 6/12 = 100 %. Unter RM läuft τ3 (T = 12) nur in den Lücken von τ1 und τ2. Die Antwortzeitanalyse ergibt R3 = 14 > D = 12, und tatsächlich verpasst τ3 vier Deadlines. EDF nutzt die CPU lückenlos und hält alle Deadlines. Das Experiment mit U = 80 % (T = 2, 5, 10) liegt immer noch über der Schranke 78 %, und trotzdem schafft RM es ohne Miss: Die Liu-&-Layland-Schranke ist nur hinreichend, nicht notwendig.
🚦 Linux RT: SCHED_FIFOEchtzeit
Feste RT-Prioritaeten ohne Zeitscheibe innerhalb gleicher Prioritaet. Zeigt deterministisches Verhalten und Starvation-Risiko.
Szenario
Prozess
Ankunft
C
Prio
T
D
Typ
RT-High
0
7
1
20
10
periodisch
RT-Mid
1
5
2
20
14
periodisch
RT-Low
0
4
4
24
20
periodisch
Algorithmus SCHED_FIFO · periodische Jobs bis t = 60
Lösung
Basis-Lauf (SCHED_FIFO) — Ausschnitt bis t = 60.
Lauf
Einstellung
Ø W
Ø R
Ø TAT
CPU-Util.
Wechsel
Deadline-Misses
Basis
SCHED_FIFO
4,67
4,67
10,00
85.7%
8
0
SCHED_FIFO aktiv
SCHED_FIFO
4,67
4,67
10,00
85.7%
8
0
Vergleich: SCHED_RR
SCHED_RR, Q=2
4,67
4,67
10,00
85.7%
8
0
Vergleich: EDF
EDF
4,67
4,67
10,00
85.7%
8
0
Erklärung
Pro Periode läuft RT-High (Prio 1) 0–7 durch, dann RT-Mid 7–12, dann RT-Low 12–16. Der erste Job von RT-Low wartet 12 Zeiteinheiten, der zweite (Freigabe t = 24) 8. SCHED_RR und EDF liefern hier exakt denselben Ablauf: Alle Prioritäten sind verschieden, es gibt also nichts zu rotieren, und die Deadlines (10, 15, 20) ergeben dieselbe Reihenfolge. Den Rotationseffekt zeigt das Beispiel SCHED_RR.
🔁 Linux RT: SCHED_RREchtzeit
RT-Policy mit fester Prioritaet plus Zeitscheibe fuer faire Rotation innerhalb einer Prio-Stufe.
Szenario
Prozess
Ankunft
C
Prio
T
D
Typ
RR-A
0
6
2
20
16
periodisch
RR-B
0
6
2
20
16
periodisch
RT-High
2
3
1
18
10
periodisch
Algorithmus SCHED_RR · Quantum 2 · periodische Jobs bis t = 60
Lösung
Basis-Lauf (SCHED_RR, Q = 2) — Ausschnitt bis t = 60.
Lauf
Einstellung
Ø W
Ø R
Ø TAT
CPU-Util.
Wechsel
Deadline-Misses
Basis
SCHED_RR, Q=2
4,40
1,70
9,20
81.4%
21
0
SCHED_RR, Q=2
SCHED_RR, Q=2
4,40
1,70
9,20
81.4%
21
0
SCHED_RR, Q=1
SCHED_RR, Q=1
4,70
1,10
9,50
81.4%
39
0
SCHED_RR, Q=8
SCHED_RR, Q=8
3,20
2,90
8,00
81.4%
10
0
Vergleich: SCHED_FIFO
SCHED_FIFO
3,20
2,90
8,00
81.4%
10
0
Erklärung
RR-A und RR-B haben dieselbe Priorität und wechseln sich mit Q = 2 ab. RT-High (Prio 1) kommt bei t = 2 und verdrängt sofort (2–5). Mit Q = 1 wird feiner rotiert (39 statt 21 Wechsel, Ø R 1,1), mit Q = 8 läuft jeder Job am Stück, und der Ablauf ist identisch mit SCHED_FIFO (10 Wechsel, Ø W 3,2).
🎯 Linux RT: SCHED_DEADLINEEchtzeit
Deadline-getriebene Linux-RT-Policy mit Runtime/Deadline/Period. Zeigt Deadline-Fokus und Budget-Effekt.
Szenario
Prozess
Ankunft
C
Prio
T
D
Typ
DL-A
0
2
1
6
6
periodisch
DL-B
0
3
1
9
9
periodisch
DL-C
1
2
2
—
7
sporadisch (MIT 8)
Algorithmus SCHED_DEADLINE · Quantum 1 · periodische Jobs bis t = 60
Lösung
Basis-Lauf (SCHED_DEADLINE) — Ausschnitt bis t = 60.
Lauf
Einstellung
Ø W
Ø R
Ø TAT
CPU-Util.
Wechsel
Deadline-Misses
Basis
SCHED_DEADLINE
0,96
0,71
3,25
90.2%
25
0
SCHED_DEADLINE aktiv
SCHED_DEADLINE
0,96
0,71
3,25
90.2%
25
0
Vergleich: EDF
EDF
0,88
0,79
3,17
90.2%
24
0
Vergleich: SCHED_FIFO
SCHED_FIFO
1,00
0,75
3,29
90.2%
26
1 (DL-C: d=8→9)
Erklärung
SCHED_DEADLINE ordnet jedem Task ein Budget (C) pro Periode zu und plant nach der frühesten Server-Deadline. Bei t = 2 läuft deshalb DL-C (Deadline 1 + 7 = 8) vor DL-B (Deadline 9). Ergebnis: keine Misses, sehr ähnlich zu reinem EDF. Unter SCHED_FIFO mit festen Prioritäten kommt DL-C (Prio 2) zu spät und verpasst seine erste Deadline (8 → 9).
🖥️ Global SMP vs. Work StealingMulti-Core
4 Cores mit ungleichmäßiger Last: ein Heavy-Task mit 2 Threads + mehrere leichte Tasks. Vergleicht eine globale Queue, Queues pro Core mit Stehlen und feste Partitionierung.
Global SMP: alle vier Cores arbeiten, Makespan 7.Partitioned: feste Zuordnung, Core 2 und 3 bleiben leer, Makespan 13.
Erklärung
Bei 4 Cores und 6 Recheneinheiten (Heavy mit 2 Threads) entscheidet die Verteilung. Global SMP: Jeder freie Core nimmt den nächsten Prozess, alle Kerne arbeiten, Makespan 7. Work Stealing erreicht mit zwei Diebstählen dieselbe Verteilung. Partitioned hält die Bindungen ein (Med-1 → Core 0, Med-2 → Core 1) und verteilt den Rest reihum: Core 2 und 3 bleiben leer, Makespan 13. Hinweis: Die Strategien wirken im Tab Multi-Core; der Scheduler-Tab zeigt das Szenario auf einem Kern.
📈 Skalierung: 1 → 4 CoresMulti-Core
Wie skaliert Durchsatz mit Anzahl der Cores? 5 CPU-intensive Tasks — Speedup und Amdahls Gesetz beobachtbar.
Szenario
Prozess
Ankunft
C
Prio
D
Typ
Task-A
0
6
1
100
einmalig
Task-B
0
5
1
100
einmalig
Task-C
0
7
1
100
einmalig
Task-D
0
4
1
100
einmalig
Task-E
0
5
1
100
einmalig
Algorithmus FCFS
Lösung
Basis-Lauf (FCFS).
Lauf
Einstellung
Ø W
Ø R
Ø TAT
CPU-Util.
Wechsel
Deadline-Misses
Basis
FCFS
11,40
11,40
16,80
100.0%
4
0
1 Core (seriell)
FCFS
11,40
11,40
16,80
100.0%
4
0
2 Cores
FCFS, 2 Cores
4,20
4,20
9,60
90.0%
3
0
4 Cores
FCFS, 4 Cores
0,80
0,80
6,20
75.0%
1
0
Erklärung
Fünf gleichzeitig ankommende Tasks mit zusammen 27 Zeiteinheiten Rechenzeit. 1 Core: Makespan 27, Ø W 11,4. 2 Cores (Global SMP): Makespan 15, Ø W 4,2, Speedup 1,8. 4 Cores: Makespan 9, Ø W 0,8, Speedup 3,0. Der Speedup bleibt unter 4, weil sich 5 unteilbare Tasks nicht gleichmäßig auf 4 Kerne verteilen lassen (Auslastung 75 %).
🔋 DVFS Energie-TradeoffDVFS
Burstartige Last gefolgt von Idle-Phasen. Zeigt den Energie-Performance-Tradeoff verschiedener DVFS-Gouverneure.
Szenario
Prozess
Ankunft
C
Prio
T
D
Typ
Burst1
0
5
1
20
20
periodisch
Idle
6
1
2
15
15
periodisch
Burst2
8
6
1
20
20
periodisch
IO
2
2
3
12
12
periodisch
Algorithmus Round Robin · Quantum 3 · periodische Jobs bis t = 60
Lösung
Basis-Lauf (Round Robin, Q = 3) — Ausschnitt bis t = 60.
Lauf
Einstellung
Ø W
Ø R
Ø TAT
CPU-Util.
Wechsel
Deadline-Misses
Basis
Round Robin, Q=3
0,87
0,47
4,00
82.5%
17
0
Governor: Performance
Round Robin, Q=3
0,87
0,47
4,00
82.5%
17
0
Governor: Powersave
Round Robin, Q=3
0,87
0,47
4,00
82.5%
17
0
Governor: Ondemand
Round Robin, Q=3
0,87
0,47
4,00
82.5%
17
0
DVFS-Tab (f_min 25 %, Schwelle 70 %):
Governor
Energie
Ersparnis
Ø Frequenz
Performance
57,00
0,00 %
100 %
Ondemand
47,20
17,30 %
87 %
Schedutil
47,20
17,30 %
87 %
Conservative
44,80
21,40 %
90 %
Interactive
56,00
1,70 %
99 %
Powersave
0,90
98,40 %
25 %
Erklärung
Der Schedule ist für alle Governors identisch; im Modell ändert die Frequenz die Rechenzeiten nicht. Unterschiedlich ist nur die geschätzte Energie (E = Σ f³·Δt). Performance braucht am meisten, Powersave fast nichts, die adaptiven Governors liegen dazwischen. Real würde Powersave die Jobs verlängern und Deadlines gefährden. Diese Kosten zeigt das Modell bewusst nicht.
📉 Jitter-Analyse (Periodische Tasks)Analyse
Wie stark schwankt die Reaktionszeit periodischer Tasks von Job zu Job? Vergleicht RR, EDF und FCFS — mit überraschendem Ergebnis.
Szenario
Prozess
Ankunft
C
Prio
T
D
Typ
Periodic-A
0
2
1
6
6
periodisch
Periodic-B
0
2
1
8
8
periodisch
Periodic-C
0
3
1
10
10
periodisch
Algorithmus Round Robin · Quantum 2 · periodische Jobs bis t = 60
Lösung
Basis-Lauf (Round Robin, Q = 2) — Ausschnitt bis t = 60.
Lauf
Einstellung
Ø W
Ø R
Ø TAT
CPU-Util.
Wechsel
Deadline-Misses
Basis
Round Robin, Q=2
1,46
1,04
3,71
91.5%
28
0
Round Robin Q=2
Round Robin, Q=2
1,46
1,04
3,71
91.5%
28
0
EDF
EDF
1,21
1,04
3,46
91.5%
25
0
RR Q=1
Round Robin, Q=1
1,83
0,58
4,08
91.5%
47
0
FCFS (deterministisch)
FCFS
1,25
1,25
3,50
91.5%
22
0
Jitter (Standardabweichung der Reaktionszeiten, in Klammern min–max):
Verfahren
σ Periodic-A
σ Periodic-B
σ Periodic-C
RR Q=2
0,66 (0–2)
0,83 (0–2)
1,21 (0–4)
EDF
0,40 (0–1)
0,87 (0–2)
1,61 (0–4)
RR Q=1
0,46 (0–1)
0,43 (0–1)
0,69 (0–2)
FCFS
0,98 (0–3)
0,99 (0–3)
1,21 (0–4)
Erklärung
Jitter ist hier die Standardabweichung σ der Reaktionszeiten aller Jobs eines Tasks. Das Ergebnis widerlegt eine verbreitete Annahme: EDF macht Periodic-A (kürzeste Periode) so gleichmäßig wie kein anderes Verfahren, Periodic-C (späteste Deadline) aber am unruhigsten. EDF optimiert Deadlines, nicht den Jitter. RR mit Q = 1 hat insgesamt den kleinsten Jitter (höchstens 0,69), weil jeder neue Job sofort eine Zeitscheibe bekommt (um den Preis von fast doppelt so vielen Wechseln).
Drei Prozesse bilden eine Pipeline: Lesen → Verarbeiten → Schreiben. Jeder Schritt wartet auf den vorherigen. Zeigt wie Precedence Constraints den Scheduler einschränken.
Szenario
Prozess
Ankunft
C
Prio
D
Typ
Weiteres
Lesen
0
4
1
20
einmalig
—
Verarbeiten
0
5
1
25
einmalig
wartet auf Lesen
Schreiben
0
3
1
20
einmalig
wartet auf Verarbeiten
Algorithmus FCFS
Lösung
Basis-Lauf (FCFS).
Lauf
Einstellung
Ø W
Ø R
Ø TAT
CPU-Util.
Wechsel
Deadline-Misses
Basis
FCFS
4,33
4,33
8,33
100.0%
2
0
Vergleich: FCFS
FCFS
4,33
4,33
8,33
100.0%
2
0
Vergleich: SJF
SJF
4,33
4,33
8,33
100.0%
2
0
Vergleich: Round Robin
Round Robin, Q=2
4,33
4,33
8,33
100.0%
2
0
Parallele Zweige hinzufügen
FCFS
4,33
4,33
8,33
100.0%
2
0
Erklärung
Die Abhängigkeiten erzwingen die Reihenfolge Lesen (0–4) → Verarbeiten (4–9) → Schreiben (9–12), unabhängig vom Algorithmus. FCFS, SJF und RR liefern denselben Ablauf, denn zu jedem Zeitpunkt ist genau ein Prozess bereit. Ø W = (0 + 4 + 9)/3 = 4,33: Verarbeiten und Schreiben warten nicht auf die CPU, sondern auf ihre Vorgänger.
Ein Haupt-Prozess gabelt sich in zwei parallele Teilaufgaben auf. Ein abschließender Join-Prozess wartet auf beide. Klassisches paralleles Berechnungsmuster.
Szenario
Prozess
Ankunft
C
Prio
D
Typ
Weiteres
Main
0
3
1
25
einmalig
—
Worker-A
0
4
1
20
einmalig
wartet auf Main
Worker-B
0
6
1
20
einmalig
wartet auf Main
Join
0
2
1
25
einmalig
wartet auf Worker-A, Worker-B
Algorithmus Round Robin · Quantum 2
Lösung
Basis-Lauf (Round Robin, Q = 2).
Lauf
Einstellung
Ø W
Ø R
Ø TAT
CPU-Util.
Wechsel
Deadline-Misses
Basis
Round Robin, Q=2
6,25
5,25
10,00
100.0%
5
0
FCFS — sequenziell
FCFS
5,75
5,75
9,50
100.0%
3
0
SRTF — überlappend
SRTF
5,75
5,75
9,50
100.0%
3
0
Round Robin Q=2
Round Robin, Q=2
6,25
5,25
10,00
100.0%
5
0
SJF
SJF
5,75
5,75
9,50
100.0%
3
0
Erklärung
Main läuft 0–3. Danach sind Worker-A (4) und Worker-B (6) bereit. FCFS, SJF und SRTF lassen A zuerst laufen (3–7), dann B (7–13). RR verzahnt beide (A 3–5, B 5–7, A 7–9, B 9–13). Join startet in allen Fällen erst bei t = 13, wenn beide Worker fertig sind, und endet bei 15. Der kritische Pfad Main + Worker-B + Join = 11 wäre die Laufzeit auf zwei Kernen; auf einem Kern bleibt es bei 15.
Klassisches Producer-Consumer-Problem mit einem Counting Semaphor als Buffer. Die Kapazität steuert, wie viele gleichzeitige Inhaber logisch erlaubt sind.
Szenario
Prozess
Ankunft
C
Prio
T
D
Typ
Weiteres
Prod-A
0
5
2
20
20
periodisch
Mutex 0
Prod-B
1
4
2
18
18
periodisch
Mutex 0
Prod-C
2
3
2
15
15
periodisch
Mutex 0
Consumer
0
6
1
25
25
periodisch
Mutex 1
Algorithmus Round Robin · Quantum 2 · Kapazitäten S0 = 2, S1 = 1 · periodische Jobs bis t = 60
Lösung
Basis-Lauf (Round Robin, Q = 2) — Ausschnitt bis t = 60. Amber-Rahmen = kritischer Abschnitt.
Lauf
Einstellung
Ø W
Ø R
Ø TAT
CPU-Util.
Wechsel
Deadline-Misses
Basis
Round Robin, Q=2
5,93
2,00
10,29
100.0%
31
1 (Prod-C: d=17→18)
Semaphor-Kapazität = 1
Round Robin, Q=2
5,36
2,79
9,71
100.0%
27
1 (Prod-C: d=17→20)
Kapazität = 3
Round Robin, Q=2
6,00
1,64
10,36
100.0%
32
0
Vergleich: ohne Sync
Round Robin, Q=2
6,00
1,64
10,36
100.0%
32
0
Erklärung
Die drei Producer brauchen Semaphor S0, der Consumer Mutex S1. Unter Round Robin werden Producer mitten im kritischen Abschnitt verdrängt. Die Kapazität von S0 bestimmt dann, wie viele gleichzeitig „drin“ sein dürfen. Mit Kapazität 1 muss jeder Producer warten, bis der Halter fertig ist (Ø R 2,79), mit 2 sinkt die Reaktionszeit auf 2,00, mit 3 auf 1,64. Bei Kapazität 1 und 2 verpasst Prod-C knapp seine Deadline, bei 3 nicht. Ohne Synchronisation ergibt sich derselbe Ablauf wie mit Kapazität 3, nur ohne Schutz des Puffers.
🧾 Trace-Replay GrundlagenAnalyse
Zeigt, wie externe Laufzeit-Traces in ein Szenario ueberfuehrt und anschliessend mit klassischen Algorithmen analysiert werden.
Szenario
Prozess
Ankunft
C
Prio
T
D
Typ
T1
0
4
1
20
20
periodisch
T2
1
3
2
20
20
periodisch
T3
3
2
3
20
20
periodisch
Algorithmus FCFS · periodische Jobs bis t = 60
Lösung
Basis-Lauf (FCFS) — Ausschnitt bis t = 60.
Lauf
Einstellung
Ø W
Ø R
Ø TAT
CPU-Util.
Wechsel
Deadline-Misses
Basis
FCFS
2,33
2,33
5,33
55.1%
8
0
CSV-Trace importieren
FCFS
2,33
2,33
5,33
55.1%
8
0
Vergleich: Round Robin Q=2
Round Robin, Q=2
3,33
1,33
6,33
55.1%
14
0
Vergleich: SJF
SJF
2,00
2,00
5,00
55.1%
8
0
Erklärung
Das Beispiel steht für ein importiertes Trace: drei Prozesse mit 4, 3 und 2 Zeiteinheiten, Ankünfte 0, 1, 3 (Periode 20). FCFS: T1 0–4, T2 4–7, T3 7–9, Ø W 2,33. SJF zieht T3 vor T2 (Ø W 2,0), RR verzahnt T1 und T2 (Ø W 3,33, aber bessere Reaktionszeit 1,33). Der eigentliche Lerninhalt ist der Import selbst (🐧 Trace ▾ im Expertenmodus).
🐧 Linux CFS + Trace-LabAnalyse
Kombiniert Linux-aehnliches CFS-Scheduling mit Trace-Import, um Replay-Daten und Simulationsmodell systematisch zu vergleichen.
Szenario
Prozess
Ankunft
C
Prio
T
D
Typ
Weiteres
T101
0
4
20
20
20
periodisch
Core 0
T202
1
3
20
20
20
periodisch
Core 1
T303
2
2
22
20
20
periodisch
—
Algorithmus Linux CFS · Quantum 1 · Multi-Core-Tab: 2 Cores, Strategie global-smp · periodische Jobs bis t = 60
Lösung
Basis-Lauf (Linux CFS) — Ausschnitt bis t = 60.
Lauf
Einstellung
Ø W
Ø R
Ø TAT
CPU-Util.
Wechsel
Deadline-Misses
Basis
Linux CFS
2,44
0,00
5,44
55.1%
13
0
Algorithmus: CFS
Linux CFS
2,44
0,00
5,44
55.1%
13
0
Deterministisch + Seed 42
Linux CFS
2,44
0,00
5,44
55.1%
13
0
Strict Linux aktivieren
Linux CFS
2,44
0,00
5,44
55.1%
13
0
Noisy Trace importieren
Linux CFS
2,44
0,00
5,44
55.1%
13
0
Golden Baseline speichern
Linux CFS
2,44
0,00
5,44
55.1%
13
0
Erklärung
CFS wählt immer den Prozess mit der kleinsten virtuellen Laufzeit. T303 hat einen höheren nice-Wert (Priorität 22 → geringeres Gewicht), seine vruntime wächst schneller. Jeder neu ankommende Prozess kommt sofort dran (Ø R 0), danach wechseln sich die Prozesse ab. Für den Vergleich mit echten Traces dienen die Diagnosepanels nach einem Import aus trace_examples/.
⚠ Modellgrenzen
Der Simulator vereinfacht bewusst. Wer Ergebnisse mit Lehrbuch- oder Klausurlösungen vergleicht, sollte diese Punkte kennen:
Bereich
Vereinfachung
Zeitmodell
Diskrete, ganzzahlige Zeiteinheiten; I/O-Phasen innerhalb eines Jobs werden nicht modelliert.
Zufall
Zufällige Ausführungszeiten, sporadische Abstände und die Monte-Carlo-Auswertung im Statistik-Tab sind über den Seed (Systemparameter) reproduzierbar.
Overhead
Kontextwechsel-Kosten werden nach der Planung eingefügt und verschieben die folgenden Blöcke; Leerlauf fängt die Verzögerung wieder auf. Die Scheduling-Entscheidungen selbst ändern sich dadurch nicht.
Mutexe
Ein Job mit Mutex hält es während seiner gesamten Rechenzeit. MLFQ berücksichtigt keine Mutexe.
E/A
Prozesse rechnen ohne E/A-Phasen; „blockiert vor Ablauf der Zeitscheibe“ (MLFQ-Folie) lässt sich daher nur über einzelne kurze Prozesse nachbilden.
Periodische Tasks
Jobs werden in einem festen Fenster erzeugt (t = 60 oder t_max), nicht automatisch über die Hyperperiode. Ein Job wartet bei Abhängigkeiten auf die bis zu seiner Freigabe freigegebenen Jobs seiner Vorgänger.
WCRT
Blockierzeiten durch Mutexe fließen nicht ein.
Multi-Core
Prozesse laufen einmalig (keine periodischen Jobs), Abhängigkeiten werden nicht beachtet, Gang Scheduling ist vereinfacht (bis zu n bereite Prozesse laufen gemeinsam). Overhead verschiebt dort alle folgenden Blöcke.
DVFS
Frequenz ändert die Ausführungszeiten nicht; Energie nur dynamisch (f³), ohne statische Leistung.
❓ Häufige Fragen
EDF simuliert keine Wiederholungen?
Periode setzen und Task-Typ auf „Periodisch“. Der Simulator erzeugt Job-Instanzen bis t = 60, bei Dauer „Manuell“ bis t_max. Mit dem Feld „Aktivierungen“ lässt sich die Anzahl der Freigaben fest vorgeben. Hinweis: Das Fenster ist fest, nicht die Hyperperiode; für eine vollständige Analyse t_max auf die Hyperperiode (kgV der Perioden) setzen.
CPU-Util. bei Multi-Core erscheint zu niedrig?
Korrekt — die Auslastung ist core-normalisiert: U = busy / (totalTime × n_cores). 2 Kerne mit je 80 % = 80 % Util., nicht 160 %.
Kontextwechsel-Overhead hat keinen sichtbaren Effekt?
δ_cs und δ_sched stehen standardmäßig auf 0. Werte unter Systemparameter setzen; dann werden sie als Bänder eingefügt. Bei FCFS gibt es wenige Wechsel → kaum Overhead, bei RR mit kleinem Quantum sehr deutlich.
WCRT zeigt ∞?
Die Fixpunktiteration divergiert → Task nicht schedulierbar. Auslastung reduzieren oder Prioritäten prüfen (RM: kürzere Periode = höhere Priorität).
Taskset-Generator trifft die Auslastung nicht genau?
UUniFast trifft die Ziel-Auslastung exakt, aber C_i wird auf ganze Zahlen gerundet (mindestens 1). Bei kurzen Perioden weicht die tatsächliche Auslastung deshalb spürbar ab. Größere Perioden (T_min / T_max) verringern den Rundungsfehler.
Share-URL funktioniert nicht?
Der Browser muss Clipboard-Zugriff erlauben. Falls die automatische Kopie fehlschlägt, öffnet sich ein Dialog mit der URL zum manuellen Kopieren.
Preset verschwunden nach Browser-Update?
Presets liegen im localStorage. Browser-Datenlöschung oder Inkognito-Modus löscht sie. Regelmäßig über „⬇ Alle exportieren“ sichern.
∑ Formelreferenz
Größe
Formel
Anmerkung
Wartezeit
W_i = TAT_i − C_i
Alle Bereit- und Blockierphasen
Turnaround
TAT_i = finish_i − arrival_i
Gesamtdurchlaufzeit
Reaktionszeit
R_i = firstCPU_i − arrival_i
OS-Sicht („response time“)
Normierte TAT
NTT_i = TAT_i / C_i
1,0 = ohne Wartezeit
Tardiness
tard_i = max(0, finish_i − d_i)
d_i = absolute Deadline
Laxity
L_i(t) = d_i − t − rem_C_i
Verbleibender Puffer
CPU-Util.
U = Σ busy / (T_max × n_cores)
Core-normalisiert
Jain-Fairness
(Σx_i)² / (n · Σx_i²)
x_i = CPU-Anteil; 1,0 = perfekt fair
Auslastung Task
U_i = C_i / T_i
Anteil der CPU pro Periode
RM-Schranke
Σ U_i ≤ n(2^(1/n) − 1)
Hinreichend; → ln 2 ≈ 69,3 % für n → ∞
Hyperbolic Bound
Π (U_i + 1) ≤ 2
Hinreichend für RM, schärfer
EDF-Bedingung
Σ C_i/T_i ≤ 1
Notwendig und hinreichend (D = T, ein Prozessor)
WCRT (RTA)
R_i = C_i + Σ_{j∈hp(i)} ⌈R_i/T_j⌉·C_j
Iterativer Fixpunkt; exakt für preemptive feste Prioritäten, D ≤ T
DVFS-Energie
E = Σ f_t³ · Δt
CMOS-Näherung P ∝ f³, f relativ zu f_max
Anbieterkennzeichnung
HM Hochschule München University of Applied Sciences
Lothstraße 34
D-80335 München
Die Hochschule für angewandte Wissenschaften München ist eine Körperschaft des öffentlichen Rechts. Sie wird durch den Präsidenten Prof. Dr. Martin Leitner gesetzlich vertreten.
Umsatzsteuer-Identifikationsnummer gemäß § 27 Umsatzsteuergesetz (UStG): DE 235 059 152
Zuständige Aufsichtsbehörde:
Bayerisches Staatsministerium für Wissenschaft und Kunst
Salvatorstraße 2
D-80333 München
Verantwortlich für diese Webseite
Verantwortlich für Inhalt, Pflege und Aktualität dieser Webseite im Sinne von § 18 Abs. 2 Medienstaatsvertrag (MStV) ist:
Prof. Dr.-Ing. Martin Hobelsberger
Fakultät für Informatik und Mathematik
HM Hochschule München University of Applied Sciences
Lothstraße 64
E-Mail: martin.hobelsberger@hm.edu
Die Verantwortung des verfassenden Bereichs erstreckt sich insbesondere auf die Rechtmäßigkeit der Inhalte, die Einhaltung von Lizenz-, Marken- und Urheberrechten sowie die Korrektheit der veröffentlichten Informationen.
Haftungsausschluss
Die Inhalte dieser Webseite werden mit größtmöglicher Sorgfalt erstellt und regelmäßig gepflegt. Dennoch kann keine Gewähr für die Richtigkeit, Vollständigkeit und Aktualität der bereitgestellten Informationen übernommen werden. Für Schäden materieller oder immaterieller Art, die durch die Nutzung oder Nichtnutzung der Informationen verursacht werden, wird - soweit gesetzlich zulässig - keine Haftung übernommen.
Sofern von dieser Webseite auf Inhalte Dritter (externe Webseiten) verlinkt wird, liegen diese außerhalb des Verantwortungsbereiches der Hochschule München. Für illegale, fehlerhafte oder unvollständige Inhalte sowie für Schäden, die aus der Nutzung oder Nichtnutzung solcher externen Informationen entstehen, haftet ausschließlich der jeweilige Anbieter der Seiten.
Urheberrecht
Sämtliche auf dieser Webseite veröffentlichten Inhalte (Texte, Bilder, Grafiken, Layouts etc.) unterliegen - soweit nicht anders gekennzeichnet - dem Urheberrecht der jeweils genannten Rechteinhaberinnen und Rechteinhaber bzw. der Hochschule München. Eine Vervielfältigung, Bearbeitung, Verbreitung oder sonstige Nutzung außerhalb der engen Grenzen des Urheberrechts ist ohne vorherige schriftliche Zustimmung der Rechteinhaberinnen und Rechteinhaber nicht gestattet.
Bei der Verwendung fremder Inhalte werden die jeweiligen Lizenzbedingungen beachtet, insbesondere bei Werken unter Creative-Commons-Lizenzen.
Datenschutz
Hinweise zur Verarbeitung personenbezogener Daten im Zusammenhang mit der Nutzung dieser Webseite finden Sie in der gesonderten Datenschutzerklärung, die von jeder Seite aus direkt erreichbar verlinkt ist. Sie können die Seite auch direkt hier aufrufen: Datenschutz.
In der Datenschutzerklärung werden insbesondere die Arten der verarbeiteten personenbezogenen Daten, die Zwecke der Verarbeitung, eingesetzte Technologien (z. B. Protokolldateien, Cookies, eingebettete Inhalte Dritter) sowie die Kontaktdaten der bzw. des zuständigen Datenschutzbeauftragten der Hochschule München beschrieben.
Datenschutzerklärung
Datenschutz ist für die Hochschule München (HM) ein wichtiges Anliegen und gesetzliche Verpflichtung.
Diese Webseite wird betrieben im Rahmen der Hochschule München University of Applied Sciences. Verantwortlich für Inhalt und Betrieb dieser Webseite ist Bernhard Werner im Namen der Fakultät für Informatik und Mathematik.
1. Verantwortliche Stelle
Fakultät für Informatik und Mathematik
HM Hochschule München University of Applied Sciences
Lothstraße 64
D-80335 München
Telefon: +49 89 1265-3700
E-Mail: Sek-Fk07@hm.edu
Website: cs.hm.edu
Verantwortlich für diese konkrete Webseite (Inhalt und Betrieb) ist Prof. Dr.-Ing. Martin Hobelsberger, martin.hobelsberger@hm.edu.
Den behördlichen Datenschutzbeauftragten der Hochschule München erreichen Sie per E-Mail unter datenschutzbeauftragter@hm.edu.
2. Allgemeine Hinweise zur Datenverarbeitung
Beim Besuch dieser Webseite werden grundsätzlich keine personenbezogenen Daten von Nutzerinnen und Nutzern erhoben, verarbeitet oder gespeichert.
Es findet keine Erstellung von personenbezogenen Nutzungsprofilen statt, es werden keine Tracking-Tools eingesetzt und es erfolgt keine Weitergabe von Daten an Dritte zu Werbe- oder Analysezwecken.
3. Speicherung von Antworten auf Fragen (nicht-personenbezogen)
Auf dieser Webseite können Antworten auf fachliche Fragen eingegeben werden. Diese Antworten werden gespeichert, automatisch ausgewertet und ggf. korrigiert, da die technische Funktion der Seite andernfalls nicht möglich wäre. Die Verarbeitung der Antworten ist damit für die Bereitstellung des von den Nutzerinnen und Nutzern ausdrücklich gewünschten Dienstes erforderlich. Darüber hinaus werden die eingegebenen Antworten in anonymisierter Form für wissenschaftliche Forschungsvorhaben ausgewertet (z. B. zu statistischen Zwecken, zur Analyse von Antwortmustern oder zur Weiterentwicklung von Lehr- und Forschungsansätzen). Dabei wird darauf geachtet, dass kein Rückschluss auf einzelne Personen möglich ist.
Bei der Konzeption der Eingabemöglichkeiten wird darauf geachtet, dass keine personenbezogenen Daten erhoben werden (insbesondere keine Namen, Kontaktdaten oder direkt zuordenbaren Identifikatoren). Nutzerinnen und Nutzer werden gebeten, in ihren Antworten keine Informationen einzugeben, die Rückschlüsse auf ihre Person oder auf andere identifizierbare Personen zulassen.
Soweit im Einzelfall dennoch personenbezogene Angaben freiwillig gemacht werden, werden diese - soweit technisch möglich - vor der Auswertung anonymisiert oder gelöscht, sodass kein Personenbezug mehr besteht. Eine Zusammenführung der Antworten mit anderen Datenquellen zum Zweck der Identifizierung von Personen findet nicht statt.
4. Einsatz von Cookies und ähnlichen Technologien
Auf dieser Webseite werden keine Cookies zu Zwecken des Trackings, des Marketings oder der Reichweitenanalyse eingesetzt.
Es kommen lediglich technisch erforderliche Mechanismen zum Einsatz, die für die Bereitstellung der Webseite selbst notwendig sind (z. B. Server-Logik, Session-Handling ohne personenbezogene IDs), ohne dass hierdurch ein Personenbezug hergestellt wird. Ein separates Cookie-Banner oder Einwilligungsmanagement ist daher nicht erforderlich.
5. Server-Logfiles
Die technische Infrastruktur der Hochschule München kann aus Gründen der IT-Sicherheit und Betriebsstabilität Server-Logfiles erzeugen (z. B. zur Abwehr von Angriffen).
Soweit hierbei IP-Adressen verarbeitet werden, geschieht dies ausschließlich zur Sicherstellung des technischen Betriebs, nach dem Prinzip der Datenminimierung und nur für den erforderlichen Zeitraum; danach werden die Daten gelöscht oder anonymisiert.
6. Ihre Rechte
Soweit im Einzelfall doch personenbezogene Daten verarbeitet werden sollten, stehen Ihnen die folgenden Rechte gemäß Art. 15 ff. DSGVO zu:
Recht auf Auskunft über die zu Ihrer Person gespeicherten Daten
Recht auf Berichtigung unrichtiger Daten
Recht auf Löschung (Recht auf Vergessenwerden)
Recht auf Einschränkung der Verarbeitung
Recht auf Widerspruch gegen die Verarbeitung
Recht auf Datenübertragbarkeit
Sie haben zudem das Recht, sich bei einer Datenschutz-Aufsichtsbehörde zu beschweren, wenn Sie der Ansicht sind, dass die Verarbeitung der Sie betreffenden personenbezogenen Daten gegen datenschutzrechtliche Bestimmungen verstößt.
Aktualisierung dieser Datenschutzerklärung
Diese Datenschutzerklärung wird bei Bedarf an geänderte rechtliche Vorgaben sowie an technische oder organisatorische Änderungen angepasst. Es gilt jeweils die auf dieser Webseite veröffentlichte aktuelle Fassung.
📋 Szenario-JSON einfügen
Füge das JSON aus einer Aufgabe oder einem Export ein, z. B. den Block „Importierbares Szenario“.
🧾 Trace-Format Hilfe
Der Trace-Import akzeptiert Textzeilen im Format pid,start,end oder JSON-Events. Im Linux-Trace-Modus werden kanonisch sched_switch, sched_wakeup(_new), sched_migrate_task und optional sched_eevdf_pick verarbeitet. Der LTTng-Import erwartet ein JSON-Exportformat mit Event-Array.
Linux-Policies im Simulator: EEVDF, SCHED_FIFO, SCHED_RR, SCHED_DEADLINE.
Importierte Linux-Traces werden standardmaessig auf EEVDF gesetzt und koennen anschliessend mit anderen Policies verglichen werden (Replay vs. Modellverhalten).
LTTng Export-Hinweis (v1): Exportiere Events als JSON-Array (z. B. ueber ein externes Skript aus CTF) und nutze dann 🐧 Trace ▾ → LTTng-JSON importieren. Der Adapter mappt name, timestamp_ns, cpu_id und Felder wie prev_tid/next_tid, pid, orig_cpu/dest_cpu auf das kanonische Scheduler-Modell.
Hinweis: Beim Standard-Import werden gleiche PID-Werte zu einem Prozess aggregiert (Burst-Zeit = Summe aller Intervalle, Arrival = fruehester Start). Im Linux-Trace-Modus entstehen Laufintervalle aus sched_switch-Sequenzen; Wakeup/Migrate/EEVDF-Pick werden fuer Diagnostik und Replay-Analyse mitgefuehrt.
💾 Preset-Bibliothek
🎲 Taskset-Generator (UUniFast)
Generiert Tasksets mit vorgegebener Gesamtauslastung nach dem UUniFast-Algorithmus (Bini & Buttazzo).
