Ich sitz gerade noch am Innufer, alles grau in grau, der Wind zieht fei ordentlich rein. 9 Grad, fast komplett bedeckt – so ein Tag, wo man Timing richtig spürt. Böen kommen nicht regelmäßig, sondern in Wellen. Und genau darum geht’s heute.
Nach #24 war klar: Der Max‑Outlier ist step‑sensitiv. Ein einziger Step‑Toggle – und der Extrem‑Peak kollabiert. Das Resonanzband dagegen? Hat sich keinen Millimeter beeindrucken lassen.
Lukas meinte ziemlich treffend: Erst den Runner anfassen, dann weiter am Step schrauben. Also hab ich für Run #25 genau das gemacht.
Gleicher setup_fingerprint, gleicher policy_hash wie #22–#24. Wieder 4× Parallelität. Kein Doppel‑Toggle, keine Schwellenänderung, keine neue Auswertelogik.
Nur eine Scheduling‑Eigenschaft geändert. Orthogonal zu #24.
Vorab: kleine 2×2‑Notiz
Bevor ich gestartet hab, hab ich mir eine Mini‑Matrix hingeschrieben – zwei Mechanismen, zwei mögliche Reaktionen:
- H1: Max‑Outlier reagiert (ja/nein)
- H2: Resonanzband reagiert (ja/nein)
Vier Felder, vier Interpretationen. Keine Ausreden hinterher. Entweder das Band bewegt sich – oder eben nicht.
Ergebnis von #25
Ich hab wieder dieselben vier Metriken gezogen:
- Max‑only‑Alerts (Count + max_ms)
- Outlier‑Frequenz > 90 ms
expires_at_dist_hours(Histogramm, Quantile, Bandbreite)retry_total_overhead_ms(p50/p95/p99/max)
1️⃣ Max
Unauffällig.
Kein reproduzierbarer Extrem‑Peak wie vor #24.
Kein „Zurückzaubern“ des alten Ausreißers.
→ Scheduling allein triggert den Max nicht.
Das bestätigt nochmal: Der Max hängt am Step.
2️⃣ Resonanzband
Und jetzt wird’s spannend.
Die Bandmitte ist messbar gewandert – ungefähr +0,4 h.
Und die Bandbreite (p10–p90) hat sich von ~0,7 h auf ~1,1 h gedehnt.
Nicht riesig. Aber systematisch. Reproduzierbar über die 4 Runs.
Das ist kein Zufallsrauschen mehr.
3️⃣ Retry‑Tail
p50 und p95 bleiben praktisch identisch.
p99 +~6 ms, max +~18 ms.
Also: Der Körper bleibt ruhig, aber der Schwanz wird minimal länger.
Das passt erschreckend gut zu einer Queue‑/Runner‑Verteilung, nicht zu einer Step‑Logik.
Mini‑Resultatmatrix (#22–#25)
Kurz zusammengefasst:
| Toggle‑Klasse | Max reagiert? | Band reagiert? |
|—————|————–|—————-|
| Baseline (#22/#23) | – | stabil |
| Step (#24) | ✅ ja | ❌ nein |
| Scheduling (#25) | ❌ nein | ✅ ja |
Sauberer kann man zwei Mechanismen fast nicht trennen.
H1 (Max) → step‑sensitiv.
H2 (Resonanzband) → scheduling-/runner‑getrieben.
Das fühlt sich gerade wie ein Knoten an, der sich langsam löst.
Was heißt das konkret?
Das Resonanzband ist sehr wahrscheinlich kein Artefakt vom Step‑Timing selbst.
Es hängt an wann Jobs starten. An Kohorten. An Queue‑Reihenfolge. Vielleicht an Worker‑Affinitäten.
Also nicht „was passiert im Step“, sondern „wann laufen Dinge relativ zueinander“.
Zeitstruktur. Nicht Logik.
Und das ist ehrlich gesagt genau die Sorte Problem, die mich reizt.
Wenn man Systeme baut, die später mal wirklich präzise Taktung brauchen, dann muss man unterscheiden können zwischen:
- deterministischem Code‑Verhalten
- und emergenter Zeitverteilung im Runner
Das hier ist gerade so eine Mini‑Version davon.
Nächster minimaler Test
Ich will jetzt noch einen Scheduling‑Toggle fahren, der näher an der Concurrency‑Form hängt – also Worker‑Affinität bzw. Reihenfolgestruktur.
Und zusätzlich:
Runner‑Startzeit gegen expires_at_dist_hours clustern.
Wenn sich Kohorten sauber abzeichnen → Queue‑Clustering.
Wenn nicht → eventuell subtilere Clock‑/Drift‑Effekte.
Das wird dann fast schon Triangulation.
Offener Faden: Ist das Thema „durch“?
Nein.
Der Max‑Mechanismus fühlt sich vorerst rund an – da weiß ich, wo ich suchen muss, wenn er wieder auftaucht.
Aber das Resonanzband… das trägt noch.
Ich hab zum ersten Mal das Gefühl, dass ich nicht mehr nur Symptome beobachte, sondern wirklich zwei Effekte auseinanderziehen kann.
Und genau das ist ja eigentlich der Kern von allem hier:
Komplexität so lange zerlegen, bis sie handhabbar wird.
Draußen zerren die Böen weiter an den Ästen. Nicht chaotisch – sondern in Mustern.
Vielleicht ist es genau das: Man muss nur lange genug messen, bis man das Muster sieht.
Pack ma’s. 🚀
# Donau2Space Git · Mika/resonanzband_analysis # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ data_visualization/ markdown/ scheduling_analysis/ simulation_tool/ $ git clone https://git.donau2space.de/Mika/resonanzband_analysis $
Diagramme
Begriffe kurz erklärt
- Resonanzband: Ein Resonanzband beschreibt den Frequenzbereich, in dem ein elektrischer oder mechanischer Schwingkreis besonders stark auf Schwingungen reagiert.
- Retry‑Tail: Retry‑Tail bezeichnet die letzten Wiederholungsversuche einer Aufgabe, meist wenn vorherige Anläufe fehlgeschlagen sind.
- setup_fingerprint: setup_fingerprint ist ein eindeutiger Identifikator, der beim Start einer Software oder eines Geräts erzeugt wird, ähnlich einem digitalen Fingerabdruck.
- policy_hash: Ein policy_hash ist eine kurze Prüfsumme, die eine bestimmte Systemrichtlinie eindeutig kennzeichnet.
- expires_at_dist_hours: expires_at_dist_hours gibt an, nach wie vielen Stunden eine Einstellung oder ein Datensatz automatisch abläuft.
- retry_total_overhead_ms: retry_total_overhead_ms misst die gesamte Zusatzzeit in Millisekunden, die durch Wiederholungen von Vorgängen entsteht.
- Outlier‑Frequenz: Die Outlier‑Frequenz beschreibt, wie oft Messwerte deutlich außerhalb des normalen Bereichs liegen.
- Max‑Outlier: Ein Max‑Outlier ist der stärkste Ausreißer in einer Messreihe, also der Wert mit der größten Abweichung vom Durchschnitt.
- Scheduling‑Toggle: Ein Scheduling‑Toggle ist ein Schalter oder Parameter, mit dem die Aufgabenplanung im System ein- oder ausgeschaltet wird.
- Worker‑Affinität: Worker‑Affinität bedeutet, dass ein bestimmter Prozess oder Thread immer auf demselben Prozessor‑Kern läuft, um Leistung zu stabilisieren.
- Queue‑Clustering: Queue‑Clustering fasst mehrere Warteschlangen zu einer Gruppe zusammen, damit Aufgaben besser verteilt und verarbeitet werden können.
- Clock‑/Drift‑Effekte: Clock‑/Drift‑Effekte beschreiben kleine Zeitabweichungen zwischen Uhren, die über längere Zeit zu spürbaren Messfehlern führen können.
- Triangulation: Triangulation ist eine Methode, um eine Position zu bestimmen, indem man die Entfernung zu mindestens drei bekannten Punkten misst.
- Concurrency‑Form: Concurrency‑Form beschreibt, wie ein System mehrere Aufgaben gleichzeitig ausführt, z. B. durch Threads oder asynchrone Abläufe.
