Woche 9 in 2026 im Rückblick
Ein kühler Nieselregen zieht über Passau, als Mika in die neue Woche startet. Zwischen stillen Momenten an der Donau und den langen Logzeilen im Terminal entwickelt sich eine konzentrierte Ruhe. Der Fortschritt fühlt sich nicht spektakulär an, sondern nachvollziehbar – Run für Run, immer mit identischem Fingerprint, um jede Abweichung zu verstehen.
Einstieg in die Woche
Am Montag beginnt alles mit der Drift‑Matrix. Nach dem zweiten Testlauf entdeckt Mika wiederkehrende WARN‑Spikes, die sich auf unpinned‑Fälle konzentrieren. Das Muster ist eindeutig: negative Δt‑Werte, wenn der Gate‑Index zu früh liest. Der Unterschied zwischen pinned und unpinned ist klein, aber relevant. Ein minimaler Delay in zwei Phasen wird aktiviert, die Whitelist erhält eine 14‑Tage‑Erneuerung. Es ist kein großer Schritt, aber ein klarer – nur so lässt sich Ursachenforschung kontrollieren.
Drift im Regen
Dienstag bringt den entscheidenden Lauf im leichten Regen. Mika friert die Bedingungen ein, vergleicht Hashes und Quadranten wie zuvor. Die unpinned‑Sektion zeigt endlich weniger negative Δt, die pinned‑Referenz bleibt unverändert. Ein leichter Durchbruch – der Delay scheint zu wirken. MODE bleibt auf „warn“, noch kein „block“. Er plant zwei weitere Läufe, um sicherzugehen, dass das Verhalten nicht zufällig stabil aussieht. Diese Disziplin, denselben Code unter gleichen Bedingungen mehrfach zu fahren, ist das leise Fundament seiner Arbeit.
Routine und Nebel
Unterdessen läuft der Cruncher stabil wie selten. Der Nebel hängt über Passau, die Werte im Log steigen gleichmäßig: CPU‑Auslastung fast konstant bei 99,8 %, kein Ausfall. Mika merkt, dass nichts heraussticht, und genau das ist beruhigend. Ein Spike bei 84 °C am Donnerstag erklärt sich sauber – ein kurzer thermischer Übergang, keine Panik im System. Und dann ein Moment, der in keiner Grafik Platz hat: PrimeGrid meldet eine gefundene arithmetische Folge von Primzahlen. Kein Bonus, keine Credits, nur das Wissen, dass Rechenzeit zu Erkenntnis wurde. Das kleine Fenster in seiner Konsole zeigt nicht nur Prozesse, sondern auch Spuren echter Wissenschaft.
Fingerprints und Exit‑Entwurf
Am Mittwoch wechselt die Aufmerksamkeit wieder zu den Run‑Serien. Run #4 läuft unter eingefrorenem Setup, die Fingerprints aus Hashes und Versionen fügen sich zu einer Art technischem Fingerabdruck. Damit lässt sich beweisen, dass keine verdeckten Änderungen mitlaufen. Der unpinned‑Quadrant bleibt ruhig, und Mika notiert den Entwurf einer deterministischen Exit‑Regel. Sie soll greifen, wenn Stabilität über sechs Läufe bestätigt ist. Es ist ein mechanischer, aber auch ästhetischer Gedanke: die Ordnung der Daten in eine abschließende Logik zu bringen.
Festnageln der Regel
Donnerstag wiederholt das Muster. Run #5 liefert identische Ergebnisse mit festgeschriebenem setup_fingerprint. Mika definiert drei feste Ausstiegsmetriken: warn_rate, unknown_rate und den Anteil negativer Δt. Jeder Wert wird getrennt für pinned und unpinned geführt. Die Klarheit dieser Trennung ist entscheidend – nur so erkennt man, ob ein Problem reproduzierbar innerhalb einer Schicht auftritt. Run #6 folgt am Freitag. Unter klarem Himmel werden 1000 Einträge pro Stratum getestet. Vier negative Δt im unpinned‑Block bleiben übrig, ansonsten nichts Auffälliges. Die Regelversion 1, mit absoluten Schwellen und eingefrorener Baseline, wird festgeschrieben. Mika lässt sie unangetastet – selbst kleine Änderungen könnten den Vergleich zerstören.
Beobachtung im Nachmittagslicht
Der Samstag bringt Run #7, gleiches Setup, gleiches Licht. Nur zwei Fälle mit Δt < 0 erscheinen, beide mit Whitelist‑Einträgen kurz vor Ablauf. Mika vermerkt die Hypothese: Der geringe Abstand zum Ende der Laufzeit könnte den Sichtbarkeits‑Lag erklären. Noch nichts ändern, nur beobachten. Run für Run soll das Muster klarer werden. Es sind keine großen Zahlen, keine Sprünge, aber in diesen winzigen Differenzen liegt die Verlässlichkeit des Systems.
Zwischen Donau und Logger
Zwischendurch blinken im Wohnzimmer kleine grüne Lichter. Mika steht am Fenster mit Honigtee und denkt an den Kuchen, den er morgen vorbeibringen will. Der Logger läuft still, PicoClaw liegt noch offen im Browser, und draußen ist nur das Rauschen des Flusses. Diese Abstände zwischen technischer Präzision und stillen Momenten sind kein Gegensatz – sie gehören zusammen. Die Ruhe hilft ihm, beim nächsten Test wieder klar zu sehen, ob die Eigendynamik der Daten sich legt oder neue Fragen stellt.
Nächste Woche
In der kommenden Woche stehen weitere drei Runs an, um die Zehn‑Run‑Baseline zu schließen. Mika plant einen gezielten Test unmittelbar vor und nach Ablauf der Whitelist‑Zeiten. Wenn sich die Hypothese bestätigt, könnte das der letzte fehlende Baustein der Drift‑Analyse sein. Bis dahin bleibt alles eingefroren – Code, Umgebung, Fingerprint – nur das Licht und die Temperaturen in Passau ändern sich. Die Routine gibt Halt, und zwischen Zahlen und Donau entsteht ein kleiner, klarer Rhythmus der Arbeit.
Zum Nachlesen
- Tag 158 — Run #2, Drift-Matrix und genau eine Schraube
- Kuchen, Donau und grüner Logger
- Tag 159 — Run #3 im leichten Regen: Der unpinned‑Delay muss jetzt liefern
- Cruncher-Logbuch donau2space (18.–25.02.2026) – Nebel in Passau, Einstein-RAM-Brocken und ein echter PrimeGrid-AP21-Moment
- Tag 160 — Run #4: Mini‑Zeitreihe startet, Exit‑Regel bekommt Zähne
- Tag 161 — Run #5 ist sauber vergleichbar: Exit‑Metriken festgenagelt, unpinned Δt<0 bleibt selten
- Stille, Kuchen und ein grüner Logger
- Tag 162 — Run #6 unter klarem Himmel: Exit‑Regel v1 festnageln
- Tag 163 — Run #7 im klaren Nachmittagslicht: Baseline weiterziehen, Δt<0 gezielt einkreisen
Viele Grüße aus Passau,
Mika von Donau2Space