# Analyse: Einfluss von 'Pinned' vs. 'Unpinned' CPU-Zuweisung auf Mischfenster und Step-Reihenfolge

## Purpose

Vergleichsanalyse zwischen pinned und unpinned A/B-Test-Varianten zur Bewertung der Mischfenster-Dauer und Stabilität der Step-Reihenfolge in VM-Umgebungen.

**Problemstellung:** Nicht deterministische Step-Ausführungsreihenfolgen und verlängerte Mischfenster unter unpinned CPU-Zuweisung erschweren die Konsistenzbewertung in A/B-Testläufen.

**Ziele:**
- Ermitteln, wie CPU-Pinning die Mischfenster-Dauer beeinflusst.
- Quantifizieren der Stabilität der Step-Sequenz bei identischen Setup-Bedingungen.

## Kontext & Hintergrund

Pro Fall jeweils 10 Runs pinned und 10 Runs unpinned; identische Kernel-, VM- und Parser-Settings; Metriken pro corr_id aggregiert.

**Gruppierung:**
- Case_03
- Case_04

**Trace-Metadaten / zusätzliche Tags:**
- corr_id
- Mischfenster-Dauer pro Zone
- Step-Order-Sequenzen
- read_between_steps

**Domänenkontext:**
- VM-basierte Performanceanalysen
- A/B-Testauswertung technischer Scheduler-Artefakte

**Outlier-Definition:**
- Methode: Empirisch per p95/max-Grenze bestimmt
- Beschreibung: Mischfenster oberhalb des p95 werden als Ausreißer betrachtet.
- Metrik: Mischfenster-Dauer in Millisekunden

**Motivation:**
- Ermittlung des Pinning-Einflusses auf deterministische Verarbeitung.
- Identifikation von Scheduling-bedingten Verzerrungen.
- Abgrenzung von Publish-Order- und Preemption-Effekten.

## Methode / Spezifikation

**Übersicht:**
- Vergleichende Auswertung zweier Konfigurationen (pinned, unpinned) bei identischen Testbedingungen.
- Messung der Mischfensterkennzahlen (p50, p95, max) sowie des step-order-stability-Scores.

**Algorithmen / Verfahren:**
- Parser aggregiert Werte pro corr_id.
- Berechnung von p50, p95 und max der Mischfenster-Dauer je Zone.
- step-order-stability-Score = Anteil Runs mit identischer Step-Sequenz.

### Bootstrap-Übersicht

Kein Resampling-Verfahren eingesetzt, direkte Aggregation von Stichproben.

**Zielgrößen:**
- Mischfenster-Dauer
- Step-Order-Stabilität

### C-State-Kontrolle

**Ziel:** Minimierung von Laufzeitvarianz durch CPU-Pinning.

**Vorgehen:**
- Pinning von VMs auf dedizierte vCPUs.
- Vergleich mit unpinned Ausführungen ohne Affinitätsbindung.

## Input / Output

### Input-Anforderungen

**Hardware:**
- Virtuelle Maschinen mit CPU-Affinitätssteuerung

**Software:**
- Trace-Parser
- Python-Skript trace_agg.py

**Konfiguration:**
- Konstante Kernel-/VM-Parameter
- Aktives Pinning via vCPU Affinity oder isolcpus

### Erwartete Rohdaten

**Felder pro Run:**
- corr_id
- Zone-ID
- p50/p95/max Mischfenster
- step_order_sequence
- read_between_steps

**Formatbeispiele:**
- {"corr_id": "abc123", "mischfenster_ms": {"p95": 1.6, "max": 3.1}, "step_order_stability": 0.68}

**Trace-Daten:**
- Format: kompaktes JSON pro Run
- Hinweis: Generiert durch trace_agg.py, standardisierte Felder pro Zone und Run.

### Analyse-Ausgaben

**Pro Gruppe / pro Governor:**
- p50/p95/max Mischfenster je Zone
- step-order-stability

**Vergleichsausgaben:**
- unpinned vs pinned
  - Δ: step-order-stability +30–40 Prozentpunkte
  - CI(Δ): nicht berechnet (direkte Aggregation)
  - RR: RR ~1.4–1.6 in Richtung höherer Stabilität bei pinned

- C-State-Korrelation: Hoher Zusammenhang zwischen CPU-Migration und Mischfenster-Ausweitung.
- Trace-Muster: Stabile Sequenzen unter pinned; unpinned zeigt variierende Step-Reihenfolgen und breitere Mischzonen.

## Workflow / Nutzung

**Analyse-Workflow:**
- Runs in VM ausführen mit wechselndem Pinning-Schalter.
- Traces per corr_id sammeln.
- trace_agg.py ausführen zur JSON-Summary-Erzeugung.
- Aggregationsvergleich zwischen pinned und unpinned.

### Trace-Template-Anforderungen

**Ziel:** Vergleichbare trace-Ereignisse aus identischen Step-Triggern.

**Erforderliche Tags & Metadaten:**
- corr_id
- step_name
- timestamp_ns
- zone_id

**trace-cmd-Setup:**
- Verwendung identischer Tracepoints pro Run.
- Keine Änderungen an Parser-Version oder Triggerdefinition.

**Run-Design für Contributors:**
- 10 pinned + 10 unpinned Runs pro Case.
- VMs mit kontrollierter CPU-Zuweisung ausführen.

## Interpretation & erwartete Ergebnisse

**Kernbefunde:**
- Pinned reduziert p95-Mischfenster signifikant (1,6→0,4 ms).
- Pinned erhöht step-order-stability von ~65 % auf bis zu 100 %.
- Migration und Preemption verstärken Mischfenster in unpinned Szenarien.

**Implikationen für Experimente:**
- CPU-Affinität ist kritischer Faktor für zeitnahe Step-Verarbeitung.
- Unpinned Konfigurationen erzeugen Scheinvariabilität in Publikations-Timings.

**Planungsziel:**
- Ziel: Trennung der Effekte von Publish-Order und seqcount-Retry.
- Vorgehen:
  - Gezieltes Hooking um Write-Operationen.
  - Messung der Reihenfolge und Retry-Zyklen unter kontrollierter Pinning-Variante.

## Limitationen & Fallstricke

**Datenbezogene Limitationen:**
- Begrenzte Run-Anzahl pro Case.
- Keine vollständige Randomisierung innerhalb der VM-Platzierung.

**Bootstrap-spezifische Limitationen:**
- Keine Resampling-basierten Unsicherheitsintervalle.

**Kausalität & Generalisierbarkeit:**
- Ergebnisse nur für getestete Kernel-/VM-Versionen gültig.
- Nicht direkt auf physische Maschinen übertragbar.

**Praktische Fallstricke:**
- Falsches Pinning-Setup führt zu irreführender Stabilität.
- VM-interne Scheduler können residuale Migrationen erzwingen.

## Nächste Schritte & Erweiterungen

**Geplante Experimente:**
- Hooking der Write-Operationen zur sauberen Trennung von Publish-Order und Retry-Pfaden.

**Analyseziele:**
- Messung der Latenzen innerhalb der Publikationssequenz.
- Einführung alternativer Stabilitätsmetriken (z. B. Edit-Distance).

**Regression & Modellierung:**
- Erweiterung um lineare Modelle zur Quantifizierung des Pinning-Effekts über verschiedene Zonen.

**Community-Beiträge:**
- Feedback zu alternativen Pinning-Strategien (vCPU-Affinity, isolcpus, cgroup-cpuset) erwünscht.