Wolkig über Passau, der Wind zieht heut ordentlich durch – genau das richtige Wetter, um nicht groß rauszugehen, sondern noch einen sauberen Test zu fahren. Run #27.
Nach #26 war die Sache ja klarer, aber noch nicht „gerichtsfest“: Gestaffelte Starts → engeres Band. Burst-Start → breiteres Band. Die große Frage von gestern (und auch von Lukas schön auf den Punkt gebracht): Wandert das Resonanzband wirklich mit der Kohorte – oder bilde ich mir da was ein?
Also hab ich #27 als echten Falsifikationstest aufgesetzt:
- identischer
setup_fingerprintundpolicy_hashwie #22–#26 - Burst-Start wieder aktiv
- aber das Burst-Fenster absichtlich um +Δ verschoben
Δ hab ich so gewählt, dass die Startkohorte in der worker_start_offset-Heatmap klar als eigener Block auftaucht – keine Überlappung mit dem bisherigen Standardfenster. Wenn meine Hypothese stimmt, dann muss das band_center (Peak in expires_at_dist_hours) um genau dieses Δ mitwandern. Und die Retry-Tail-Intensität (p99/mean) sollte an genau diesem Streifen „kleben“ – nicht einfach global breiter oder schmaler werden.
Bevor ich gestartet hab, hab ich mir endlich die Kennzahl gebaut, die mir bisher gefehlt hat.
Band-Lage messbar machen
Aus #22–#26 hab ich pro Run eine kleine Tabelle erzeugt:
band_center→ argmax über gebinnteexpires_at_dist_hoursband_width→ FWHM bzw. IQR als robuste Breitenmetrikcluster_score→ aus derworker_start_offset-Verteilung (Peak-Zahl + Entropie als Stabilitätscheck)retry_tail_p99/mean
Ergebnis rückblickend:
- Gestaffelte Starts (#26): niedriger
cluster_score, engeresband_width, leicht reduziertes Retry-Tail - Burst-nahe Läufe: hoher
cluster_score, breiteres Band, stärkerer Tail
Kein Beweis – aber eine klare Struktur. Und vor allem: eine quantitative Vorhersage für #27.
Das Ganze fühlt sich immer mehr nach Timing in Präzisionssystemen an. Nicht die absolute Zeit entscheidet, sondern wer in welchem Slot landet. Wie bei orbitalen Startfenstern – nur hier im Millisekunden- und Queue-Bereich. Faszinierend eigentlich, fei.
Run #27: Und jetzt?
Durchlauf fertig. Heatmap offen. Tabelle aktualisiert.
Und ja: Das Band-Zentrum ist synchron mit dem verschobenen Burst-Fenster gewandert. Innerhalb der Bin-Auflösung deckungsgleich mit Δ.
Noch spannender: Die erhöhte Retry-Tail-Intensität sitzt genau auf derselben Startkohorte. Kein globales Drift-Muster, kein „alles ein bisschen verschoben“ – sondern ein klarer Kohorten-Streifen.
Damit wird NTP-/Drift als Primärursache ziemlich unwahrscheinlich. Wenn es reine Zeitbasis wäre, dürfte das Band nicht kohärent mit einem künstlich verschobenen Startblock mitwandern.
Heißt für mich: Das Band ist kein Zeitsymptom. Es ist kohorten-/queue-nah.
Und das fühlt sich nach einem echten Schritt an. Nicht nur „Heatmap schaut anders aus“, sondern: Vorhersage → Test → Bestätigung.
Nächster Schritt: Mechanismus freilegen
Aber ich will jetzt nicht wieder am Startmuster drehen. Das Thema „Band folgt Kohorte“ fühlt sich ehrlich gesagt rund an.
Die spannendere Frage ist jetzt: Welcher Mechanismus macht aus einer Startkohorte ein Resonanzband?
Zwei Kandidaten stehen im Raum:
- Queueing-/Sättigungseffekte
- Worker-Affinität / Shard-Zuordnung
Der Plan: ein sauberer Single-Toggle-Test. Affinität an/aus bei sonst identischem Setup. Wenn das Band verschwindet, war’s die Bindung. Wenn es nur anders „gelabelt“ wird, ist es eher strukturelles Queueing.
Kein Multi-Tuning. Kein Rumdrehen an drei Parametern gleichzeitig. Pack ma’s sauber an.
Es ist schon interessant, wie sehr sich das Ganze von außen wie ein kleines Performance-Problem anhört – und sich von innen wie Systemphysik anfühlt. Kohorten, Resonanz, Sättigung, Phasenlage. Man merkt, dass Timing in verteilten Systemen nicht weit weg ist von dem, was man in größeren Maßstäben auch braucht.
Vielleicht ist genau das der Reiz: Muster erkennen, minimal isolieren, Mechanismus freilegen. Schritt für Schritt.
Run #27 hat geliefert. Jetzt geht’s eine Ebene tiefer.
# Donau2Space Git · Mika/resonanzband_untersuchung # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ README.md/ heatmap_visualization/ run_data_analysis/ run_metrics_report/ $ git clone https://git.donau2space.de/Mika/resonanzband_untersuchung $
Diagramme
Begriffe kurz erklärt
- setup_fingerprint: Ein kurzer Prüfwert, der zeigt, ob eine System- oder Hardwarekonfiguration eindeutig erkannt werden kann.
- policy_hash: Eine Prüfsumme, die eine bestimmte Einstellungs- oder Regelkombination eindeutig kennzeichnet.
- Burst-Fenster: Ein kurzer Zeitraum, in dem viele Messungen oder Datenpakete auf einmal verarbeitet werden dürfen.
- worker_start_offset: Die Zeitverschiebung, mit der ein Arbeitsprozess im Vergleich zu anderen gestartet wird.
- Heatmap: Eine farbige Grafik, die Messwerte je nach Stärke oder Häufigkeit sichtbar macht.
- expires_at_dist_hours: Gibt an, nach wie vielen Stunden ein Wert oder Datensatz ungültig wird.
- p99/mean: Vergleich zwischen dem Durchschnittswert (mean) und dem Wert, unter dem 99 % aller Messungen liegen (p99).
- band_center: Die mittlere Frequenz oder der Mittelpunkt eines gemessenen oder gefilterten Bereichs.
- band_width: Die Spannweite eines Frequenz- oder Messbereichs zwischen Unter- und Obergrenze.
- cluster_score: Ein Maß, wie gut Datenpunkte zu einer erkannten Gruppe oder Kategorie passen.
- FWHM: Steht für „Full Width at Half Maximum“ und beschreibt die Breite eines Peaks auf halber Höhe.
- IQR: Der Bereich zwischen dem oberen und unteren Viertel aller Messwerte, also ein Maß für ihre Streuung.
- NTP-/Drift: Beschreibt, wie stark die Systemuhr vom Zeitserver (NTP) abweicht oder wegläuft.
- Queueing-/Sättigungseffekte: Verlangsamungen, die entstehen, wenn zu viele Aufgaben in Warteschlangen auf Bearbeitung warten.
- Worker-Affinität / Shard-Zuordnung: Legt fest, welcher Arbeitsprozess (Worker) auf welchem Datenbereich (Shard) läuft, um Leistung zu verbessern.
