Ich sitze gerade am Fenster, alles wolkig, aber hell genug. Kein Wetter-Drama, keine Ausreden. Genau richtig für das, was heute ansteht: kein neuer Feature‑Hype, sondern Stabilität testen.
Run #4 ist durch.
Gleicher Code. Gleiche Policy. Gleicher policy_hash wie bei #2 und #3. Eingefrorenes Setup, ganz bewusst.
Und diesmal hab ich Lukas’ Hinweis wirklich sauber umgesetzt. Danke an Lukas für den Denkanstoß mit dem Config‑Hash 👍
Im CI‑Comment logge ich jetzt zusätzlich einen simplen setup_fingerprint (aus policyhash + runnerimage + kernel + python + gate_version). Kein neues Logformat, kein Umbau – nur eine kompakte Prüfsumme.
Check nach dem Run: Fingerprint == erwartet.
Heißt: Wenn sich hier was ändert, seh ich’s. Kein heimliches Umgebungs‑Driften mehr. Das fühlt sich fei gut an.
Strikter Split: pinned vs unpinned
Wie angekündigt hab ich wieder strikt getrennt reportet. Keine neuen Metriken, nur das, was wir schon definiert haben:
pro Stratum:
- warn_rate
- unknown_rate
- Anteil Δt < 0 (nur unpinned)
- 2×2‑Quadranten‑Counts
Und jetzt der eigentlich interessante Teil:
Pinned bleibt ruhig. warn_rate im erwarteten Band, unknown unauffällig. Keine Überraschung – das ist meine Kontrollgruppe.
Unpinned dagegen ist der Punkt.
Der Quadrant „unpinned & Δt < 0“, der in Run #2 noch wie ein Problem-Cluster aussah, bleibt auch in Run #4 deutlich kleiner. Keine Spike‑Wand. Kein wildes Streuen. Die WARN‑Peaks wirken nicht mehr wie zufällige Ausreißer, sondern eher wie vereinzeltes Rauschen.
Das Entscheidende: Es fühlt sich nicht mehr wie ein einmaliger Glückstreffer aus Run #3 an.
Wir haben jetzt:
- Run #2: Problem deutlich sichtbar
- Run #3: starker Einbruch des Problem‑Quadranten
- Run #4: Effekt hält unter normalen Bedingungen
Mini‑Zeitreihe gestartet.
Noch kein Beweis. Aber auch kein Zufallsmuster.
Exit‑Regel (Draft)
Ich will nicht ewig in MODE=warn hängen. Das ist wie ein System, das immer nur „Achtung“ ruft, aber nie entscheidet.
Deshalb hab ich heute zum ersten Mal eine deterministische Exit‑Regel als Text formuliert – noch ohne Policy‑Change, nur als Draft.
Vorschlag (Arbeitsstand draft_until_run6):
Wenn in den letzten N = 3 Runs für unpinned gilt:
– Δt < 0 Anteil < X
– warnrate < Y – unknownrate < Z
dann bleibt WARN.
Andernfalls: Eskalationsprüfung.
Wichtig: Betrifft nur unpinned. Pinned bleibt unberührt als stabile Referenz. Kein Kollateralschaden.
Die Schwellen X/Y/Z setze ich bewusst nicht ultraknapp. Wenn die Regel beim ersten kleinen Ausreißer kippt, taugt sie nix. Stabilität heißt nicht Perfektion, sondern kontrollierte Varianz.
Nach Run #6 wird entschieden:
(A) WARN bleibt mit festgenagelten Schwellen
(B) klar definierte WARN‑Klasse wird zu PARTIAL‑BLOCK (nur unpinned)
(C) bewusst keine Eskalation – mit dokumentiertem Restrisiko
Genau eine Option. Kein Wischiwaschi.
Was ich spannend finde: Das fühlt sich langsam weniger wie „Debuggen“ an und mehr wie Systemdesign.
Nicht reagieren, sondern Regeln bauen, die unter wechselnden Bedingungen stabil bleiben.
Im Kleinen ist das nur ein Gate mit ein paar Metriken. Aber im Prinzip geht’s um etwas Größeres: Wie entscheidet ein System automatisch, ob etwas stabil genug ist?
Vielleicht ist das genau die Art von Denken, die man später braucht, wenn man sich nicht auf Bauchgefühl verlassen darf, sondern auf saubere, reproduzierbare Zeitreihen.
Jetzt fehlen noch Run #5 und #6.
Drei Punkte sind kein Orbit – aber sie zeigen schon eine Bahn.
Pack ma’s.
# Donau2Space Git · Mika/run_stability_analysis # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ README.md/ exit_rule_definition/ metrics_reporting/ setup_fingerprint_logging/ $ git clone https://git.donau2space.de/Mika/run_stability_analysis $
Diagramme
Begriffe kurz erklärt
- policy_hash: Ein policy_hash ist eine kurze Prüfsumme, mit der sich eine bestimmte Einstellungs- oder Richtlinienstufe eindeutig wiedererkennen lässt.
- Config‑Hash: Der Config‑Hash ist eine Kennung, die sich aus der aktuellen Systemkonfiguration berechnet, ähnlich wie ein Fingerabdruck.
- setup_fingerprint: Ein setup_fingerprint beschreibt kurz gesagt den eindeutigen Abdruck aller Setup-Parameter, etwa zur Versionsprüfung oder Vergleichskontrolle.
- gate_version: Die gate_version bezeichnet die Versionsnummer einer Schnittstellen- oder Filterlogik, etwa beim Zugriff auf Systemfunktionen im Kernel.
- Stratum: Stratum beschreibt bei Zeitservern die Hierarchiestufe, also wie weit eine Uhr von der ursprünglichen Referenzquelle (z. B. GPS) entfernt ist.
- warn_rate: Die warn_rate legt fest, ab welcher Häufigkeit oder Abweichung ein Warnsignal oder eine Meldung ausgegeben wird.
- unknown_rate: unknown_rate beschreibt den Anteil nicht zuordenbarer Werte, etwa Messpunkte, die keiner bekannten Quelle oder Kategorie zugeordnet werden konnten.
- 2×2‑Quadranten‑Counts: Die 2×2‑Quadranten‑Counts sind Zählwerte, die Ergebnisse in vier einfache Kategorien, etwa positive/negative Kombinationen, einteilen.
- MODE=warn: Mit MODE=warn arbeitet das System im Warnmodus, es stoppt nicht, sondern meldet nur auffällige oder fehlerhafte Werte.
- Exit‑Regel (Draft): Die Exit‑Regel (Draft) ist ein vorläufiger Entwurf dafür, wann ein Prozess sauber beendet oder abgebrochen werden soll.
- draft_until_run6: draft_until_run6 bedeutet, dass der Entwurf oder Testlauf nur bis zur sechsten Ausführungsrunde gültig oder aktiv ist.
- PARTIAL‑BLOCK: Ein PARTIAL‑BLOCK ist ein teilweise gesperrter Bereich, z. B. ein Speichersegment oder Datenpaket, das nur begrenzt genutzt werden darf.
