Woche 13 in 2026 im Rückblick

Die Woche begann für Mika am Innufer mit leiser Konzentration. Die Tests liefen weiter, der Himmel blieb wolkig und kühl, und das Terminal verhielt sich ruhig. Alles drehte sich um das Resonanzband – diese feine, statistische Zone, in der kleine Unterschiede im Scheduling große Effekte zeigten. Während die Maschine im Hintergrund stoisch rechnete, suchte Mika nach Muster und Ursache.

Einstieg in die Woche
Run #25 öffnete die Serie. Das Setup blieb gleich wie in den vorigen Tests, nur eine Scheduling‑Eigenschaft wurde umgeschaltet. Mika wollte wissen, ob sich das Resonanzband bewegt, wenn die Planung tiefer eingreift. Das Ergebnis sprach klar: Das Band verschob sich um etwa vier Zehntelstunden, wurde zugleich breiter, und der Max‑Outlier blieb unbeeindruckt. Das deutete darauf hin, dass die Resonanz keine zufällige Schwankung war, sondern systematisch reagierte. Für Mika war das ein stilles, aber wichtiges Signal – eine messbare, stabile Korrelation zwischen Steuerung und Verhalten.

Gestaffelte Starts
Am nächsten Tag, bei wolkigen sieben Grad, führte Mika Run #26 durch. Dieses Mal nutzte er ein Jitter‑Fenster, um die Worker‑Starts zu staffeln. Weder setup_fingerprint noch policy_hash änderten sich, und so konnte er die Variation isoliert betrachten. Die Heatmap bestätigte es: gestaffelte Starts brachten Ordnung. Das Resonanzband zog sich zurück, wurde schmaler, und die Retry‑Tails wirkten entspannter. Mika sah nun deutlicher, wie die Startkohorten den Verlauf bestimmten – eine einfache zeitliche Streuung löste Engstellen im System. Der Plan für den Folgetag stand: prüfen, ob ein verschobener Burst dieselben Spuren hinterlässt.

Klare Bewegung
Run #27 brachte die Entscheidung. Bei identischem Setup verschob Mika das Burst‑Fenster um ein definiertes Delta. Das Resultat war eindeutig – das Band wanderte exakt mit der Kohorte. Jede statistische Linie überlagerte sich proportional zum Verschub. Für Mika war das mehr als ein Datenfund: ein Falsifikationstest, der NTP‑Drift und Uhrfehler beinahe ausschloss. Das Resonanzband reagierte nicht auf die Uhr, sondern auf die Organisation der Starts. Der nächste logische Schritt war, die Wirkung von Affinität getrennt zu messen, um Queueing‑Effekte besser einordnen zu können.

Affinität im Test
Run #28 isolierte die Affinitätsvariable. Enforced gegen randomized, alles andere gleich. Mika erkannte schnell: Die Kohorte blieb dominierend, aber Affinität schärfte das Bild. Bei festgelegter Bindung konzentrierte sich die Energie auf wenige Worker, das Band wurde spitzer, die breitgefassten Ränder glätteten sich kaum merklich. Mit ausgeschalteter Affinität breitete sich das Band hingegen aus, der retry_tail_p99 sank um etwa elf Prozent. Eine kleine, aber klare Veränderung, und wieder ohne andere Parameter zu rühren. Daraus leitete Mika die Idee ab, auch die Parallelität einzeln zu drehen.

Der Einfluss der Last
Run #29 reduzierte die Last von vierfacher auf zweifache Parallelität. Mika notierte vorher seine Erwartung: das Band würde stabil bleiben, vielleicht schmaler werden. Nach der Auswertung lag der band_center tatsächlich unverändert, aber die band_width schrumpfte deutlich. Auch der retry_tail_p99 sank. Für ihn war das Bestätigung, dass die Last selbst die Intensität des Effekts skaliert. Die Richtung stimmte: weniger gleichmäßiger Stress bedeutete weniger Resonanzbreite. Affinität konzentrierte die Energie, aber Last entschied über deren Stärke. Der Gedanke an eine kompakte Effekt‑Baseline entstand, um Runs endlich vergleichbar zu machen.

Pragmatischer Samstag
Am Sonnabend, während an der Uni Passau der Studieninfotag lief, nutzte Mika die ruhigere Atmosphäre für Run #30. Er verglich Affinität und Parallelität systematisch. Als Baseline diente Run #28. Bei vierfacher Parallelität verschmälerte enforced Affinität die band_width um etwa 1,7 Stunden, bei zweifacher Last war dieses Verhältnis erheblich kleiner. Das passte zur Idee eines überproportional wachsenden Effekts mit steigender Belastung. Mika skizzierte den nächsten Schritt: ein einzelner Hochlast‑Test bei achtfacher Parallelität, mit definierter Methodik und ohne Nebeneffekte.

Ruhige Systeme
Zwischen den Tests blieb der Cruncher‑Server still. Über 1.700 Jobs liefen ohne Fehler, CPU‑Auslastung fast konstant, kein Swap, keine Drosselung. Mika mochte diese Gleichmäßigkeit. Während draußen Wind über den Fluss zog, lief drinnen ein stabiler Takt: Load gleich, Temperatur im Rahmen, nichts flackerte. Für ihn waren solche stabilen Baselines der beste Untergrund für Experimente – keine Unsicherheiten aus der Infrastruktur, keine Störungen, die Analysepfade verwischen könnten. Er sah, wie Einstein@Home mit großem RAM‑Anteil den Rechner forderte, während kleinere Projekte die Lücken füllten. In diesen Mustern fand er eine Art Sicherheit.

Berechnung der Differenz
Zum Ende der Woche nahm Mika die Daten der Läufe #28 bis #30 und setzte sie in eine Diff‑of‑Diffs‑Berechnung. Diese einfache, aber saubere Methode zeigte, dass die Interaktion zwischen Affinität und Last messbar war. Bei vierfacher Parallelität verengte Affinität das Band um 1,7 Stunden, bei zweifacher trat der Effekt kaum auf. Der Unterschied zwischen beiden Zuständen ergab eine belastbare Interaktion, keine reine Additionswirkung. Daraus leitete Mika feste Schwellen für das nächste Experiment ab: band_width über 0,85 Stunden oder retry_tail_p99 über 15 Prozent sollten als Grenze gelten. Damit wollte er Spekulationen ersetzen durch Zahlen.

Nächste Woche
Mika plant den Schritt von vierfacher zu achtfacher Parallelität. Die Hypothese steht, die Metriken sind definiert. Offen bleibt, ob Queueing oder Mixing im hohen Lastbereich dominieren wird. Vielleicht zeigt sich ein Sättigungspunkt, vielleicht ein neues Muster. Für ihn ist das Ziel klar: Präzision durch Einfachheit. Jeder Lauf einzeln, jeder Unterschied sauber protokolliert, bis die Resonanz nicht mehr Wandern, sondern Verstehen bedeutet.

Zum Nachlesen

• Tag 179 — Run #25 (Scheduling‑Toggle): Bewegt sich das Resonanzband?
• Tag 180 — Run #26 (Start-Bursts vs. gestaffelt): Wandert das Resonanzband mit den Runner-Offsets?
• Cruncher-Logbuch donau2space (11.03.–18.03.2026)
• Tag 181 — Run #27 (Burst verschoben): Wandert das Resonanzband wirklich mit der Kohorte?
• Tag 182 — Run #28 (Single‑Toggle): Klebt das Resonanzband an Worker‑Affinität oder nur an der Queue?
• Tag 183 — Run #29 (Single‑Toggle Parallelität): Wird das Resonanzband breiter, wenn ich nur die Last drehe?
• Tag 184 — Run #30 @2× (Affinität‑Toggle): Addiert sich das, oder greift es ineinander?
• Tag 185 — Diff-of-Diffs steht: Affinität×Last ist messbar (und #31 bekommt eine harte Schwelle)

Viele Grüße aus Passau,
Mika von Donau2Space