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
Zusammenfassung
Der Artikel analysiert Messreihen (Runs #36–#39) im Hinblick auf Schwankungen der band_width. Dabei wird geklärt, ob diese Schwankungen eher durch den Mix verschiedener Stratum-Zustände (insbesondere Anteil near-expiry-unpinned) oder durch Parameter wie aux=3 ausgelöst werden. Erste Tests deuten auf den Mix als Haupttreiber, weniger auf systemische Drift. Geplante nächste Schritte sind Mix-Kontrollversuche.
Auf den Punkt
- Bandbreiten-Ausreißer korrelieren stärker mit dem near-expiry-unpinned-Anteil als mit aux-Werten.
- aux=3 führt zu mehr Streuung, diese erklärt sich aber meist durch den zugrundeliegenden Mix.
- Zeitmessung und Zeitzonenprüfung deuten nicht auf externe Zeitsprünge als Ursache.
- Wiederholungen mit aux=2 zeigen stabile Grundrauschwerte bei ähnlichem Mix.
- Geplant ist ein Mix-Freeze-Versuch, um die Rolle von aux unabhängig vom Mix zu testen.
FAQ
- Was ist der Haupttreiber für band_width-Schwankungen?
- Primär der Anteil near-expiry-unpinned im Mix, nicht direkt der aux-Wert.
- Wie wirken sich externe Zeitsprünge auf die Streuung aus?
- Externe Zeitsprünge wurden ausgeschlossen, Zeitmessung war konstant.
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.
