| .. | ||
| README.md | ||
Deterministische Exit-Regel für Stabilitätsbewertung von Systemmetriken
Purpose
Definition einer deterministischen Exit-Regel zur Bewertung der Stabilität von unpinned Systemmetriken über mehrere Runs.
Problemstellung: Fehlende definierte Exit‑Bedingungen führen zu inkonsistenten Entscheidungen und erschweren die Automatisierung der Stabilitätsbewertung.
Ziele:
- Überwachung der Stabilität über eine Zeitreihe von Runs
- Einführung eines reproduzierbaren Entscheidungsmechanismus für den Statuswechsel (z. B. WARN → PARTIAL‑BLOCK)
- Vermeidung von Reaktionen auf zufällige Schwankungen
Kontext & Hintergrund
Messwerte pro Run, getrennt nach pinned und unpinned Strata.
Gruppierung:
- pinned
- unpinned
Trace-Metadaten / zusätzliche Tags:
- policy_hash
- setup_fingerprint (policy_hash + runner_image + kernel + python + gate_version)
Domänenkontext:
- Kontinuierliche Stabilitätsüberwachung in CI-Umgebungen
- Bewertung temporaler Metriken in sequentiellen Testläufen
Outlier-Definition:
- Methode: Visuelle und metrische Auswertung von Warnraten und negativen Δt-Anteilen.
- Beschreibung: Messpunkte mit außergewöhnlich hohen warn_rate oder Δt<0 werden als potenzielle Instabilitäten betrachtet.
- Metrik: warn_rate, unknown_rate, Anteil Δt<0
Motivation:
- Vermeidung unkontrollierten Umgebungs-Drifts
- Reproduzierbare, deterministische Bewertungslogik
- Trennung zwischen stabiler Referenz (pinned) und Testbereich (unpinned)
Methode / Spezifikation
Übersicht:
- Die Exit-Regel beschreibt ein deterministisches Verfahren, das nach N=3 aufeinanderfolgenden Runs angewendet wird.
- Bewertet werden drei Kennzahlen für unpinned-Messungen.
Algorithmen / Verfahren:
- Berechne warn_rate, unknown_rate und Anteil Δt<0 pro Run.
- Erzeuge Zeitreihe über N=3 aufeinanderfolgende Runs.
- Vergleiche jede Metrik mit den Schwellen X, Y, Z.
- Wenn alle drei Werte unter den Schwellen liegen → Status bleibt WARN.
- Andernfalls → Einleitung Eskalationsprüfung.
Bootstrap-Übersicht
Bootstrap-Resampling kann zur Stabilitätsprüfung der Kennzahlen-Verteilung verwendet werden.
Zielgrößen:
- Varianz der warn_rate
- Varianz des Anteils Δt<0
Resampling-Setup
- unpinned
Stichprobeneinheit: Run
Resampling-Schema:
- Rolling window über die letzten 3 Runs
- Bootstrap über Metrikwerte innerhalb jedes Windows
Konfidenzintervalle:
- Niveau: 0.95
- Typ: percentile
- Ableitung: aus wiederholtem Bootstrap über Run-Mittelwerte
Abgeleitete Effektgrößen
Risk Difference (Differenz der Raten):
- Definition: Differenz der Proportion von Δt<0 zwischen zwei Runs oder Zuständen.
- Bootstrap: Berechnung des Konfidenzintervalls der Differenz durch Bootstrap über Stichproben der Einzelwerte.
Risk Ratio:
- Definition: Verhältnis der Warnhäufigkeiten (warn_rate) zwischen Runs.
- Bootstrap: Abschätzung eines 95%-Konfidenzintervalls für das Verhältnis durch resampling der Fallzahlen.
C-State-Kontrolle
Ziel: Sicherstellen, dass Unterschiede nicht durch Energiesteuerungszustände (C‑States) verursacht werden.
Vorgehen:
- Korrelieren von C‑State-Anteilen mit Δt<0 und warn_rate.
- Ausschluss signifikanter drifthafter Trends über Runs.
Input / Output
Input-Anforderungen
Hardware:
- konstante Runner-Instanz ohne dynamische Frequenzskalierung
Software:
- stabile Gate- und Python-Versionen
- identischer Kernel pro Testserie
Konfiguration:
- policy_hash fixiert pro Run-Serie
- setup_fingerprint validiert nach jedem Durchlauf
Erwartete Rohdaten
Felder pro Run:
- run_id
- stratum
- warn_rate
- unknown_rate
- delta_t_negative_share
- policy_hash
- setup_fingerprint
Formatbeispiele:
- {run_id:4, stratum:'unpinned', warn_rate:0.07, unknown_rate:0.01, delta_t_negative_share:0.03}
Trace-Daten:
- Format: CSV oder JSON mit aggregierten Run-Metriken
- Hinweis: Lauf-identische Fingerprints dienen der Konsistenzprüfung
Analyse-Ausgaben
Pro Gruppe / pro Governor:
- Zeitreihe der warn_rate
- Zeitreihe des Anteils Δt<0
- Stabilitätsindikatoren pro Run-Gruppe
Vergleichsausgaben:
-
pinned vs unpinned
- Δ: warn_rate_diff
- CI(Δ): [low, high]
- RR: warn_rate_ratio
- CI(RR): [low, high]
-
C-State-Korrelation: Korrelationskoeffizient zwischen aktivem C‑State und Metrikabweichungen
-
Trace-Muster: Erkennung stabiler Fingerprint-Sequenzen über Runs
Workflow / Nutzung
Analyse-Workflow:
- Daten aus drei jüngsten Runs sammeln.
- Schwellen X, Y, Z aus definierter Parameterdatei einlesen.
- Berechnungsmodul für Kennzahlen ausführen.
- Ergebnis mit Exit-Regel evaluieren.
- Statusentscheidung dokumentieren (WARN / Eskalation).
Trace-Template-Anforderungen
Ziel: Reproduzierbare Run-Struktur mit stabilen Fingerprint-Metadaten.
Erforderliche Tags & Metadaten:
- policy_hash
- setup_fingerprint
- run_id
trace-cmd-Setup:
- Run-Setup einfrieren bevor Serie startet.
- Nach jedem Lauf fingerprint prüfen.
Run-Design für Contributors:
- Mindestens drei konsekutive Runs mit identischem Setup.
- Pinned als Referenz immer miterheben.
Interpretation & erwartete Ergebnisse
Kernbefunde:
- Unpinned stabilisiert sich über mehrere Runs.
- Warn- und Unknown-Raten bleiben innerhalb definierter Schwellen.
- Δt<0 Anteil zeigt keine anhaltenden Ausreißer mehr.
Implikationen für Experimente:
- Die deterministische Exit-Regel kann für automatisierte Stabilitätsprüfungen eingesetzt werden.
- Pinned dient zuverlässig als Kontrollgruppe.
Planungsziel:
- Ziel: Entscheidung über Eskalation oder Fortführung basierend auf stabilen Metriken.
- Vorgehen:
- Analyse nach Run #6 zur finalen Regelvalidierung.
- Festlegung finaler Schwellenwerte X/Y/Z.
Limitationen & Fallstricke
Datenbezogene Limitationen:
- Kleine Stichprobenumfänge (N=3) erhöhen Varianzrisiko.
- Änderungen im Laufzeit-Environment können Fingerprint trotz stabiler Policy verändern.
Bootstrap-spezifische Limitationen:
- Bootstrap-Konfidenzintervalle instabil bei wenigen Runs.
- Schätzungen können bei extremer Schiefe unpräzise sein.
Kausalität & Generalisierbarkeit:
- Korrelation der Metriken belegt keine Kausalität.
- Regel gilt nur für getestete Systemtopologie.
Praktische Fallstricke:
- Zu enge Schwellen führen zu Fehlalarmen.
- Nichtbeachtung des pinned-Control-Stratums verzerrt Stabilitätseindruck.
Nächste Schritte & Erweiterungen
Geplante Experimente:
- Durchführung von Run #5 und #6 zur Validierung der Draft-Regel.
Analyseziele:
- Überprüfung der Schwellenrobustheit bei realen Fluktuationen.
Regression & Modellierung:
- Modellierung der Zeitreihenentwicklung der warn_rate zur Prognose künftiger Stabilität.
Community-Beiträge:
- Diskussion und Validierung der Exit-Regel im Gate‑Lab‑Forum.