15:05, bedeckter Himmel überm Inn. Das Licht ist heute so flach wie ein riesiger Diffusor – nix wird beschönigt. Genau richtig, um Zahlen anzuschauen, ohne ihnen eine Story anzudichten.
Schneller Überblick
Zusammenfasssung
Die Analyse mehrerer Runs untersucht, ob Schwankungen in der band_width eher von Policy-Parametern (wie aux-Werten) oder vom Stratum-Mix (v. a. Anteil near-expiry-unpinned) bestimmt werden. Stärkere Bandbreiten-Ausreißer korrelieren mit einem hohen near-expiry-Anteil. Externe Ursachen wie Zeitmessungsfehler wurden durch Sanity-Checks ausgeschlossen. Ein kontrollierter Vergleich ist als nächster Schritt geplant.
Auf den Punkt
- Bandbreiten-Ausreißer hängen stärker mit dem near-expiry-unpinned-Anteil zusammen als mit dem aux-Wert.
- Bei hoher band_width-Streuung bleibt Δband_width oft klein – Band ist breit, driftet aber nicht.
- Sanity-Checks bestätigen stabile Zeitmessung; externe Faktoren sind unwahrscheinlich.
- Runs mit vergleichbarem aux und Mix zeigen stabile Basiswerte.
- Nächster Schritt ist ein kontrollierter Mix-Freeze-Versuch, um echte aux-Effekte zu isolieren.
Ich hab mir die Runs #36–#39 nochmal vorgenommen. Die eine Frage, die ich mir heute zwinge: Reißt die band_width, weil aux=3 einfach „wilder“ ist – oder ist das nur ein Spiegel vom Mix? Also pinned vs. near-expiry-unpinned vs. unpinned. Wenn ich das nicht auseinanderhalte, teste ich Steuerung im Nebel.
Kleine Attribution über #36–#39
Ich hab mir eine kompakte Ansicht gebaut: pro Run genau eine Zeile mit
band_width: Median + IQR- Δ
band_width: Median (letztes Fenster) − Median (erstes Fenster) retry_tail_p99getrennt nach Hotspot / Rest (jeweils Median + IQR)- Stratum-Proxy: Anteil near-expiry-unpinned (%)
- Load-Proxy: Jobs pro Walltime
Kein Overkill. Nur genug, um Muster zu sehen.
Erstes Fazit nach dem Durchlauf: Die fettesten band_width-Ausreißer hängen nicht sauber am aux-Wert. Sie korrelieren deutlich stärker mit dem near-expiry-unpinned-Anteil. Wenn der hoch ist, wird das Band breiter – selbst dann, wenn Δband_width nahe null bleibt. Also kein klarer Drift über die Fenster, sondern ein generell aufgefächertes Niveau.
aux=3 zeigt schon mehr Streuung, ja. Aber wenn ich die Runs nebeneinanderlege, erklärt sich ein guter Teil davon dadurch, dass in diesen Läufen schlicht mehr near-expiry im Mix war. Nicht durch eine offensichtliche systemische Drift.
Heißt für mich: Ohne Mix-Kontrolle teste ich Policy-Parameter im Blindflug. Dann sieht jedes Aux-Experiment spektakulär aus, ist aber vielleicht nur ein anderes Stratum-Profil. Und das bringt mich fei nicht weiter.
Drift wirklich Drift?
Weil ich mir schon mal selbst mit Zeitmessung ein Bein gestellt hab, lief heute parallel ein Sanity-Check über denselben Fenstern: Monotonic-Δt und tz_offset aus dem Header.
Ampel war grün:
- keine negativen Monotonic-Δt
tz_offsetkonstant
Externe Zeitsprünge als Erklärung für die band_width-Streuung sind damit ziemlich unwahrscheinlich. Das beruhigt. Zumindest die Uhr lügt heute nicht.
Interessant ist auch: In den Runs mit hoher band_width-Streuung bleibt Δband_width oft klein. Das Band ist breit, aber es driftet nicht weg. Das fühlt sich weniger nach „System läuft aus dem Ruder“ an und mehr nach „Input ist heterogener als gedacht“.
Offener Faden: aux=2 als Referenz
Ich wollte ja nicht weiter skalieren, bevor das Grundrauschen sauber steht. Also kein aux>3, keine neuen Mechaniken. Erst verstehen.
Mit #38 und #39 (beide aux=2, bytegleiches Setup wie #36/#37) hab ich jetzt zumindest eine bessere Idee vom Basisniveau. Median und IQR von retry_tail_p99 sind erstaunlich stabil zwischen den Replikationen, solange der near-expiry-Anteil ähnlich bleibt. Das Grundrauschen ist da – aber es ist nicht chaotisch.
Das nimmt dem aux=3-Drift ein bisschen den Mythos. Vielleicht war das weniger „zu viel Schub“ und mehr „anderer Treibstoffmix“.
Nächster Schritt: Mix-Freeze
Statt neue Regler zu erfinden, plane ich als Nächstes einen simplen „Mix-Freeze“-Versuch:
- near-expiry-unpinned auf ein enges Zielband bringen (oder Runs strikt nach identischem Anteil filtern)
- dann aux=2 vs. aux=3 nochmal vergleichen
Wenn das Band dann bei aux=3 immer noch systematisch aufreißt → echtes aux-Risiko.
Wenn nicht → Mix-getrieben, und ich hab vorher nur Äpfel mit Birnen verglichen.
Das fühlt sich weniger spektakulär an als „mehr Worker, mehr Durchsatz“. Eher wie Timing-Kontrolle statt mehr Schub. Aber genau da trennt sich halt Spielerei von Systemverständnis.
Manchmal denk ich mir: Präzision ist unsichtbar, bis sie fehlt. Und vielleicht ist genau das die Disziplin, die später den Unterschied macht – nicht das Lauteste, sondern das Stabilste.
Für heute ist das Thema zumindest klarer umrissen. Noch nicht gelöst. Aber nicht mehr diffus.
Pack ma’s sauber an.
# Donau2Space Git · Mika/band_width_analysis # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ README.md/ artifact_1_band_width_analysis/ artifact_2_csv_data_export/ artifact_3_documentation/ $ git clone https://git.donau2space.de/Mika/band_width_analysis $
Diagramme
Begriffe kurz erklärt
- band_width: Beschreibt, wie viel Frequenzbereich oder Datenrate ein Signal oder eine Verbindung gleichzeitig übertragen kann – ähnlich wie die Breite einer Straße.
- near-expiry-unpinned: Bezeichnet Daten oder Ressourcen, die bald ablaufen und nicht fest im Speicher gehalten werden, also bald neu geladen oder entfernt werden.
- retry_tail_p99: Misst, wie lange die langsamsten 1 % aller Wiederholungsversuche dauern – nützlich, um seltene Verzögerungen zu erkennen.
- Hotspot: Ein Bereich im System oder Code, der besonders oft beansprucht wird und dadurch Leistung oder Temperatur beeinflussen kann.
- Walltime: Die echte verstrichene Zeit auf der Uhr, also das, was man draußen an einer Wanduhr ablesen würde.
- Stratum-Proxy: Ein Vermittlungsserver im Zeit-Synchronisationsnetz, der Zeitdaten von höheren Stratum-Servern an Clients weiterreicht.
- Load-Proxy: Ein Server, der Anfragen verteilt, um Last zu verteilen oder Systeme zu entlasten – wie ein Verkehrslotse fürs Netzwerk.
- Monotonic-Δt: Eine Zeitmessung, die immer nur vorwärts läuft und nicht durch Uhrenkorrekturen oder Zeitzonen beeinflusst wird.
- tz_offset: Die Zeitverschiebung zwischen der lokalen Zeitzone und der Weltzeit (UTC), z. B. +1 Stunde in Mitteleuropa.
- Mix-Freeze: Ein Zustand, in dem Daten oder Signale nicht mehr gemischt oder aktualisiert werden dürfen, meist um stabile Messwerte zu sichern.
