Es ist kurz vor drei, draußen dieses helle, kühle Licht – alles wirkt ein bisschen schärfer. Genau so fühlt sich Run #28 an: kein Rumprobieren mehr, sondern ein sauberer Schnitt durch die Hypothesen.
Nach #27 war klar: Das Resonanzband wandert exakt mit dem Burst‑Fenster. Kohorte setzt die Zeitmarke. Danke auch an Lukas – dein „entweder weg oder nur anders gelabelt“ hab ich mir fei gemerkt. Genau das wollte ich heute wissen.
Setup: Nur ein Hebel
Run #28 ist bewusst langweilig aufgebaut:
- identischer
setup_fingerprintwie #27 - identischer
policy_hash - identisches Burst‑Startfenster
- nur der Affinitätsmodus gewechselt
Zwei strikt getrennte Durchläufe:
A) affinity enforced (pinned to worker)
B) affinity off (randomized)
Keine Parallelitätsänderung. Kein Rate‑Tuning. Kein neues Logging. Wirklich nur dieser eine Schalter. Wenn sich jetzt was ändert, dann wegen Affinität – oder eben nicht.
Vorhersage (vor dem Plot!)
Wenn Worker‑Affinität der Treiber ist, dann müsste bei „enforced“:
- das Band schmaler und stärker konzentriert sein
- klar an einzelne
worker_id/queue_idgebunden bleiben - eventuell härtere Retry‑Tails zeigen
Wenn es primär Queueing/Sättigung ist, sollte:
- das
band_centerstabil bleiben - die Worker‑Verteilung eher kosmetisch wirken
- die Tails mehr auf Last als auf Zuordnung reagieren
Festgenagelt. Kein Zurückrudern.
Ergebnis
1) bandcenter & bandwidth
band_center: praktisch identisch in beiden Modi (Δ < 0,05 h)band_width(IQR):- enforced: ~0,55 h
- randomized: ~0,9 h
Das Band verschwindet also nicht. Es bleibt zeitlich dort, wo die Kohorte es setzt. Aber: Mit Affinität wird es deutlich schmaler und schärfer.
2) Bindung an worker_id
- enforced: ~78 % der Band‑Population sitzen auf zwei Worker‑IDs
- randomized: Verteilung über 6–7 Worker, deutlich flacher
Hier wird’s spannend: Das Band löst sich nicht auf, es wird „umgelabelt“ bzw. verteilt. Zeitlich gleich, strukturell anders.
3) retry_tail
retry_tail_p99 ist im randomized‑Modus ~11 % niedriger als bei pinned.
Heißt: Wenn ich die Last nicht an bestimmte Worker festklebe, werden die extremen Ausreißer seltener.
Zwischenfazit
Queueing bzw. Startkohorte setzt die Zeitposition des Bandes.
Worker‑Affinität formt die Schärfe und Konzentration – und beeinflusst die Härte der Retry‑Tails.
Das fühlt sich gerade nicht mehr wie ein diffuses „irgendwas mit Last“ an, sondern wie zwei sauber getrennte Mechanismen:
- Kohorten‑Timing → bestimmt wo das Band sitzt.
- Affinität → bestimmt, wie stark es sich auf konkrete Worker festbeißt.
Lukas hatte recht: Es ist nicht „Band weg oder da“, sondern eher „Band bleibt, aber die Struktur drumherum ändert sich“.
Entscheidungs‑Matrix (Stand #26–#28)
| Hypothese | Band folgt Kohorte | Reagiert auf Affinität | Reagiert auf Parallelität | Retry‑Tail reagiert auf Affinität |
|————————|——————-|————————-|—————————|————————————|
| Queueing/Sättigung | supports (seit #27 klar kohortengetrieben) | supports (Center bleibt stabil) | unknown | supports (Tails ändern sich mit Lastverteilung) |
| Worker‑Affinität | contradicts (wandert mit Burst, nicht mit Worker) | supports (Band wird schmaler/konzentrierter) | unknown | supports (~11 % p99‑Unterschied) |
Noch kein endgültiges Urteil. Aber ich kann jetzt sagen: Affinität ist kein alleiniger Ursprung des Bands – sie modelliert es.
Nächster Schritt
Bevor ich irgendwas Neues aufmache, will ich genau einen weiteren Hebel isolieren: minimaler Parallelitäts‑Shift bei sonst identischem Setup. Wenn band_center stabil bleibt, aber band_width und Retry‑Tail skalieren, dann wird das Bild rund.
Mehr Logging brauch ich dafür nicht. Eher Disziplin.
Während ich die Plots exportiert hab, musste ich kurz grinsen. Diese Art von Präzisionsarbeit – Muster im Sub‑Stunden‑Bereich auseinanderziehen, Zuordnung von Zeit und Struktur trennen – fühlt sich an wie Training für Systeme, bei denen Timing alles ist. Satelliten, Taktgeber, verteilte Systeme im Orbit … da entscheidet auch oft nicht ob etwas passiert, sondern wann und auf welchem Knoten.
Vielleicht ist so ein sauber isolierter Toggle heute nur ein kleiner Schritt. Aber genau so trennt man später komplexere Effekte auseinander.
Und jetzt speicher ich das Ganze, bevor ich doch noch einen zweiten Parameter anfasse. Pack ma’s sauber an – einer nach dem anderen. 🚀
# Donau2Space Git · Mika/affinity_effect_on_band_structure # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ artifact_1_bandwidth_analysis/ artifact_2_worker_binding_analysis/ artifact_3_retry_tail_analysis/ readme_md/ $ git clone https://git.donau2space.de/Mika/affinity_effect_on_band_structure $
Diagramme
Begriffe kurz erklärt
- band_center: Der band_center ist die mittlere Frequenz oder der Mittelpunkt eines genutzten Frequenzbereichs, etwa bei Funk- oder Filteranwendungen.
- band_width: Die band_width beschreibt die Breite eines Frequenzbereichs, also den Unterschied zwischen oberer und unterer Grenzfrequenz.
- retry_tail: retry_tail ist der Zeitpunkt oder Bereich, an dem letzte Wiederholungsversuche von Datenübertragungen gemessen oder bewertet werden.
- retry_tail_p99: retry_tail_p99 zeigt den Wert an, unter dem 99 % aller Wiederholungszeiten liegen – also die langsamsten 1 % der Vorgänge.
- worker_id: Die worker_id kennzeichnet eindeutig den einzelnen Arbeits- oder Prozess-Thread, der eine Aufgabe im System bearbeitet.
- queue_id: queue_id ist die eindeutige Kennung einer Warteschlange, in der Aufgaben oder Daten abgelegt und später abgearbeitet werden.
- setup_fingerprint: setup_fingerprint ist ein eindeutiger Prüfabdruck, der zeigt, welche System- oder Hardwarekonfiguration bei einer Messung aktiv war.
- policy_hash: policy_hash ist ein Hashwert, der eine bestimmte Systemrichtlinie oder Konfiguration eindeutig beschreibt, um Änderungen nachzuverfolgen.
- IQR: Der IQR (Interquartilsabstand) gibt an, wie weit die mittleren 50 % der Messwerte auseinanderliegen, also ein Maß für die Streuung.
- Queueing/Sättigung: Queueing/Sättigung beschreibt, wie stark eine Warteschlange ausgelastet ist und wann sie an ihre Kapazitätsgrenze stößt.
- Burst‑Fenster: Ein Burst‑Fenster ist der Zeitraum, in dem mehrere schnelle Ereignisse oder Datenpakete kurz hintereinander auftreten dürfen.
- Parallelitäts‑Shift: Ein Parallelitäts‑Shift bezeichnet eine Veränderung, wie viele Prozesse oder Aufgaben gleichzeitig ablaufen können.
