holdover_test/trace_repo_template

Trace-Repo-Template und Aggregationsskript für C-State- und Clocksource-Analysen

Purpose

Dokumentvorlage und Skriptstruktur zur Analyse von CPU-Governor-Einflüssen auf C-State-Residency und Clocksource-Wechsel über lange Testzeiträume.

Problemstellung: Unterschiede im CPU-Governor-Verhalten über einen 24‑h‑Testzeitraum verursachen Outlier‑Cluster, deren Korrelation mit C‑State‑ und Clocksource‑Metriken reproduzierbar dokumentiert werden soll.

Ziele:

• Einheitliche Trace-Struktur für C-State-Analysen
• Automatisierte Aggregation von Clocksource-Wechselereignissen
• Vergleich von Governor-Profilen über gleichartige Runs

Kontext & Hintergrund

Langzeit-Traces von CPU‑C‑States, Clocksource‑Wechseln und EM‑Messungen über 24‑h‑Runs unter verschiedenen CPU‑Governoren.

Gruppierung:

• powersave
• performance

Trace-Metadaten / zusätzliche Tags:

• timestamp
• cstate_level
• clocksource_event
• governor_mode
• event_latency

Domänenkontext:

• CPU power management
• kernel scheduler behavior
• BPF tracing
• bootstrap analysis

Outlier-Definition:

• Methode: Bootstrap-basiertes Resampling und Mann‑Whitney‑Test
• Beschreibung: Outlier werden als Messungen außerhalb des 95 %-Konfidenzintervalls der Referenzgruppe definiert.
• Metrik: Benchmark-Latenzabweichung pro Lauf

Motivation:

• Überprüfung des Governor‑Effekts über lange Zeiträume
• Quantifizierung der C‑State‑Einflüsse auf Stabilität
• Ausschluss elektrischer Störeinflüsse

Methode / Spezifikation

Übersicht:

• Vergleich der Outlier‑Raten zwischen powersave und performance Governors über 24 h
• Analyse der C3‑Residency im 0–1000 ms‑Fenster vor Events
• Auswertung von clocksource_switch‑BPF‑Traces

Algorithmen / Verfahren:

• Bootstrap‑Resampling mit 10 000 Iterationen, Ermittlung von 95 %‑Konfidenzintervallen
• Differenz von Anteilen (Outlier‑Raten) zwischen Gruppen
• Risikoquotient‑Schätzung (risk ratio)
• Nonparametrische Signifikanztests mittels Mann‑Whitney‑U

Bootstrap-Übersicht

Nichtparametrisches Resampling über Outlier‑Messungen pro Governor‑Gruppe.

Zielgrößen:

• Outlier‑Anteil
• Median‑Residency C3
• clocksource_switch‑Rate

Resampling-Setup

• powersave
• performance

Stichprobeneinheit: Einzelner Benchmark‑Lauf

Resampling-Schema:

• 10 000 Iterationen
• Mit Zurücklegen
• Gruppenweise Resamples

Konfidenzintervalle:

• Niveau: 0.95
• Typ: Percentilbasiert
• Ableitung: Empirisch aus Bootstrap‑Verteilung

Abgeleitete Effektgrößen

Risk Difference (Differenz der Raten):

• Definition: Differenz der Outlier‑Raten zwischen Governors.
• Bootstrap: Bootstrap‑Verteilung der Anteilsdifferenz, CI über Percentile.

Risk Ratio:

• Definition: Verhältnis der Outlier‑Wahrscheinlichkeiten zwischen powersave und performance.
• Bootstrap: Resampling der Quotenverteilung und CI‑Schätzung über log‑Transformation.

C-State-Kontrolle

Ziel: Validierung des Einflusses tiefer C‑States auf Outlier‑Rate.

Vorgehen:

• Zusätzlicher Kontrolllauf mit powersave, C0/C1‑only
• Vergleich Outlier‑Rate gegenüber performance
• Analyse C‑State‑Residency‑Reduktion

Input / Output

Input-Anforderungen

Hardware:

• x86‑Laptop mit stabiler Stromversorgung
• konstante Umgebungstemperatur

Software:

• Linux‑Kernel mit BPF‑Unterstützung
• trace‑cmd
• Python‑Bootstrap‑Auswerteskript

Konfiguration:

• Governor festgesetzt (powersave oder performance)
• clocksource Kernel‑Trace aktiviert

Erwartete Rohdaten

Felder pro Run:

• timestamp
• latency_ms
• cstate
• clocksource_event_count
• governor
• run_id

Formatbeispiele:

• 2024‑12‑01T06:00:00Z, 2.35 ms, C3, 1, powersave, run_01

Trace-Daten:

• Format: FTRACE/BPF‑Events im Text‑ oder JSON‑Exportformat
• Hinweis: Jede Zeile enthält Event‑Timestamp und C‑State‑Wechselkennung.

Analyse-Ausgaben

Pro Gruppe / pro Governor:

• Outlier‑Rate (%)
• Median‑C3‑Residency (ms)
• clocksource_switch‑Events pro Benchmark

Vergleichsausgaben:

• powersave vs performance

  • Δ: ≈18 Prozentpunkte
  • CI(Δ): [~12, 24]
  • RR: ≈4.1
  • CI(RR): [~2.0, 6.8]
  • Tests: ≈0.003

• C-State-Korrelation: Residency‑Zunahme in C3 korreliert mit Outlier‑Häufungen.

• Trace-Muster: C‑State‑Exit gefolgt von clocksource_switch‑Event innerhalb 20–200 ms.

Workflow / Nutzung

Analyse-Workflow:

• Traces erfassen mit trace‑cmd oder BPF‑Programmen
• Aggregationsskript aus Template anwenden
• Bootstrap‑Analyse der Outlier‑Raten durchführen
• Ergebnisse in Gruppen‑Report konsolidieren

Trace-Template-Anforderungen

Ziel: Standardisierte Aufnahme und Auswertung von C‑State‑Residency und Clocksource‑Wechseln.

Erforderliche Tags & Metadaten:

• governor
• timestamp
• cstate
• clocksource_event
• latency_ms

trace-cmd-Setup:

• trace‑cmd record ‑e power/cpu_idle ‑e clockevents/clock_*
• BPF‑Tracing optional für clocksource_switch aktivieren

Run-Design für Contributors:

• Identische Hardware‑Parameter pro Lauf beibehalten
• Getrennte Runs für powersave und performance
• Laufzeit mindestens 24 h pro Konfiguration

Interpretation & erwartete Ergebnisse

Kernbefunde:

• Governor‑Effekt bleibt über 24 h stabil nachweisbar.
• powersave zeigt erhöhte Outlier‑Raten und tiefere C‑States.
• C‑State‑Exits stehen in zeitlicher Nähe zu clocksource_switch‑Events.

Implikationen für Experimente:

• Governor‑Wahl beeinflusst zeitliche Stabilität von Benchmarks.
• C‑State‑Management ist kritischer Faktor bei Latenzanalysen.

Planungsziel:

• Ziel: Reduktion der Outlier‑Rate durch gezielte C‑State‑Begrenzung.
• Vorgehen:
  • Kontrolllauf mit C0/C1‑Only‑Regime
  • Analyse, ob Outlier‑Rate auf performance‑Niveau absinkt

Limitationen & Fallstricke

Datenbezogene Limitationen:

• Langzeit‑Test unterliegt Temperatur‑ und Spannungsdrift.
• Spätere Tageszyklen können Einfluss auf System‑Thermik haben.

Bootstrap-spezifische Limitationen:

• Abhängigkeit der CIs von der Stichprobengröße.
• Bootstrap‑Verteilungen können bei kleinen N verzerrt sein.

Kausalität & Generalisierbarkeit:

• Beobachtete Korrelationen nicht zwingend kausal.
• Ergebnisse spezifisch für getestete Hardware/Kernel‑Version.

Praktische Fallstricke:

• Falsche Governorumschaltung während Testlauf verfälscht Ergebnis.
• Nicht‑synchronisierte Traces erschweren Zuordnung von Events.

Nächste Schritte & Erweiterungen

Geplante Experimente:

• Kontrolllauf mit powersave (nur C0/C1 erlaubt).

Analyseziele:

• Quantitative Validierung des Einflusses tiefer C‑States auf Outlier‑Raten.

Regression & Modellierung:

• Modellierung der Outlier‑Wahrscheinlichkeit als Funktion der C‑State‑Residency.

Community-Beiträge:

• Template‑Bereitstellung im Trace‑Repository für Replikations‑Experimente.