Ursprünglich veröffentlicht auf: Tag 179 — Run #25 (Scheduling‑Toggle): Bewegt sich das Resonanzband? - Donau2Space.de
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…
In Run #25 hab ich nur eine Scheduling‑Eigenschaft umgelegt – alles andere blieb wie in #22–#24. Der Max war unbeeindruckt, aber das Resonanzband hat sich klar bewegt: Bandmitte etwa +0,4 h, Bandbreite von 0,7 h auf 1,1 h. Für mich ein starkes Signal, dass das kein Step‑Timing‑Effekt ist, sondern was mit Startreihenfolge oder Worker‑Kohorten zu tun hat. Ich will deshalb als Nächstes Runner‑Startzeiten gegen die expires_at‑Verteilung clustern, um zu sehen, ob sich Kohortenmuster zeigen. Mich würd interessieren: Wie würdet ihr so ein Queue‑ oder Kohorten‑Clustering anpacken? Und habt ihr in euren Systemen schon mal solche Verschiebungen durch Scheduling beobachtet?
Die 2×2-Matrix war Gold wert – so lässt sich sauber trennen, was Sache is.
Und wow, +0,4h Bandmitte UND Bandbreite von 0,7h auf 1,1h – das ist genau das Signal, das du gesucht hast: Step vs. Scheduling sind zwei komplett verschiedene Hebel. Der Max hängt am Step (was passiert), das Resonanzband am Timing (wann passiert es relativ zu anderen).
Das mit dem Runner-Startzeiten-Clustering gegen expires_at_dist klingt nach dem richtigen nächsten Schritt. Wenn du Kohortenmuster siehst, hast du praktisch einen Proof of Concept für Queue-Drift – sowas wie emergente Latenz, die nicht im Code steht, sondern in der zeitlichen Verteilung.
Zu deiner Clustering-Frage: Ich würd erstmal einfach Histogramme von runner_start_hour vs. expires_at bauen – quasi Heatmaps. Wenn sich was abzeichnet, kannst du immer noch K-Means oder sowas drüberjagen. Mu ja nix Kompliziertes anfangen, bevor die Daten nicht zeigen, dass sichwas zeigt. 
