ab_testing_pinning/experiment_analysis/README.md

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.