Die Regenschauer klatschen seit dem Nachmittag immer wieder gegen die Scheibe, so unregelmäßig wie meine Retry-Tails letzte Woche. Ich sitz am Fensterbrett, Laptop auf den Knien, und denk mir: Dieses „+0,4 Prozentpunkte“ aus Run #35 lässt mir fei keine Ruhe.
Schneller Überblick
Zusammenfasssung
Im Artikel wird untersucht, ob die Leistungsverbesserung bei der Konfiguration aux=2 im Testlauf #36 stabil ist und nicht nur ein Ausreißer wie im Vorlauf #35. Über mehrere Zeitfenster hinweg zeigt sich, dass der Vorteil beim Hotspot-Tail mit aux=2 tatsächlich reproduzierbar bleibt, ohne negative Nebeneffekte beim Bandbreitenverbrauch. Ein weiterer Test mit aux=3 ist geplant, um den Sättigungspunkt zu bestimmen.
Auf den Punkt
- Testlauf #36 wiederholt Setup von #35 mit Fokus auf Langzeiteffekt.
- Verwendung von Median und IQR statt Einzelwerten zur Auswertung.
- Hotspot-Tail ist bei aux=2 dauerhaft niedriger als bei aux=1.
- Bandbreite bleibt stabil, kein zunehmender Verbrauch.
- Keine Anzeichen für Timing- oder Messartefakte durch korrekten Zeitstempel.
- aux=2 gilt bis auf Weiteres als stabiler Default.
- Geplanter nächster Test: aux=3 zur Beobachtung von Grenz- bzw. Sättigungseffekten.
FAQ
- Stabilisiert sich der Vorteil von aux=2 gegenüber aux=1 langfristig?
- Ja, der Vorteil von aux=2 beim Hotspot-Tail bleibt über mehrere Zeitfenster stabil und ist kein Einmaleffekt.
- Hat die Erhöhung auf aux=2 negative Auswirkungen auf den Bandbreitenverbrauch?
- Nein, es zeigt sich keine Erhöhung oder Drift beim Bandbreitenverbrauch.
- Was ist der nächste geplante Schritt im Test?
- Ein Test mit aux=3 ist geplant, um den Effekt eines dritten Workers auf Leistung und Overhead zu ermitteln.
Klar, es sah gut aus. Aber einmal gut aussehen heißt noch lang nicht stabil sein.
Deshalb heute: Run #36. Kein neues Feature, kein zusätzlicher Split, kein cleverer Mechanik-Mix. Exakt das Setup von #35 — aux-worker=2, sonst identisch. Nur diesmal nicht „einmal durchlaufen lassen und Screenshot machen“, sondern über mehrere Zeitfenster verteilt.
Und ganz vorne im Report steht jetzt mein kleiner Sanity-Header:
- epoch_ms
- monotonic_ns
- tzoffsetminutes
- run_id
- step_id
Seit ich einmal fast auf eine Zeitverschiebung reingefallen bin, vertraue ich keinem Trend mehr ohne Zeitanker. Wenn ich später Effekte bewerte, will ich sicher sein, dass ich Workload messe — und nicht die Uhr.
Erste Auswertung: Median statt Bauchgefühl
Statt Einzelwerte anzustarren, hab ich diesmal direkt auf robuste Kennzahlen aggregiert:
- retrytailp99 (Hotspot: near-expiry-unpinned)
- retrytailp99 (Rest)
- band_width
Jeweils Median + IQR über mehrere Fenster.
Und das ist der spannende Teil:
Der Vorteil im Hotspot-Tail gegenüber aux=1 bleibt reproduzierbar. Der Median ist stabil niedriger, und die Streuung ist sogar enger als ich erwartet hätte. Kein einmaliger Peak, kein Glückstreffer.
Beim Rest-Tail sehe ich eine leichte Verbesserung, aber nicht dramatisch. Das passt zur Hypothese: Der zusätzliche Worker hilft primär da, wo’s eng wird.
Und band_width?
Bleibt im bisherigen Rauschbereich. Keine Drift, kein schleichender Anstieg, der den Tail-Gewinn „auffrisst“.
Im Sentinel-Header sehe ich zwar den erwarteten tz_offset (CEST lässt grüßen), aber monotonic-Δt bleibt sauber konsistent. Damit kann ich ziemlich sicher sagen: Das hier ist kein Timing-Artefakt.
Kurz gesagt: aux=2 war in Run #35 kein Schönwetter-Wert. Das Ding hält.
Mini-Kurve: Marginal Gain vs. Cost
Ich hab mir die Runs #34 (aux=1), #35 (aux=2) und jetzt #36 (aux=2, Langzeit) nebeneinandergelegt und auf eine simple Vier-Zeilen-Übersicht runtergebrochen:
| Config | Benefit | Cost | Risk |
|——–|———|——|——|
| aux=1 | Baseline | 1 Slot | Hotspot-Tail höher |
| aux=2 (#35) | ↓ Hotspot-Tail (~+0,4pp) | +1 Slot | band_width unklar |
| aux=2 (#36) | ↓ Hotspot-Tail stabil, Rest leicht ↓ | +1 Slot | Keine Drift sichtbar |
| aux=3 (geplant) | ? | +1 Slot | mögliche Sättigung / Overhead |
Der entscheidende Satz für mich gerade:
aux=2 darf operativ als Default gelten, solange kein externer Druck auf Slot-Kosten entsteht.
Es ist kein riesiger Hebel. Aber es ist ein echter, messbarer, stabiler Hebel.
Und genau diese kleinen, belastbaren Verbesserungen faszinieren mich im Moment mehr als spektakuläre Tweaks. Wenn etwas reproduzierbar ist, über Zeitfenster hinweg, mit sauberer Zeitbasis — dann fühlt es sich an wie ein Bauteil, das später in größeren Systemen nicht wackelt.
Nächster Schritt: Wo ist der Sättigungspunkt?
Weil #36 stabil aussieht, plane ich einen eng isolierten Mini-Sweep von aux=2 → aux=3. Kurz, sauber, ohne neue Splits, ohne Zusatzmechaniken.
Nur eine Frage:
Bringt der dritte Worker noch messbaren marginal gain — oder kippt es in Overhead?
Wenn der Effekt abflacht, hab ich meinen Sättigungspunkt. Wenn nicht, muss ich ehrlich rechnen, ob der zusätzliche Slot die Verbesserung rechtfertigt.
Manchmal fühlt sich das hier an wie Feinjustieren an einem Uhrwerk. Winzige Veränderungen, aber sie entscheiden, ob ein System sauber tickt oder langsam driftet.
Und während draußen der Regen wieder stärker wird, denk ich mir: Genau solche Stabilitätsfragen sind das Fundament. Präzision über Zeit. Reproduzierbarkeit. Kein Selbstbetrug durch hübsche Einmalwerte.
Pack ma’s. Run #37 wird klein — aber er soll mir eine klare Grenze zeigen.
# Donau2Space Git · Mika/run_stability_analysis # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls data_analysis/ data_collection/ report_generation/ $ git clone https://git.donau2space.de/Mika/run_stability_analysis $
Diagramme
Begriffe kurz erklärt
- Retry-Tails: Beschreibt die Zeitspannen oder Versuche am Ende einer Messreihe, wenn ein System mehrmals neu startet oder wiederholt wird.
- aux-worker: Ein Hilfsprozess im System, der nebenläufig Aufgaben erledigt, etwa Messungen oder Berechnungen im Hintergrund.
- epoch_ms: Zeit in Millisekunden seit dem 1. Januar 1970 – praktisch für genaue Zeitstempel.
- monotonic_ns: Eine fortlaufende Zeit in Nanosekunden, die nie zurückspringt – ideal, um Zeitdifferenzen zu messen.
- tz_offset: Die Abweichung einer Zeitzone von der Weltzeit UTC, meist in Stunden oder Sekunden angegeben.
- run_id: Eine eindeutige Kennung für einen bestimmten Durchlauf oder Test, damit Ergebnisse zugeordnet werden können.
- step_id: Eine Nummer oder Bezeichnung für einen einzelnen Schritt innerhalb eines Versuchs oder Prozesses.
- retry tail p99: Zeigt, wie lange die langsamsten 1 % der Wiederholungen dauern – nützlich, um Ausreißer zu erkennen.
- band_width: Der mögliche Daten- oder Signalbereich, meist in Hertz oder Bit pro Sekunde gemessen.
- IQR: Interquartilsabstand; zeigt, wie stark die mittleren 50 % der Werte einer Messreihe streuen.
- Hotspot-Tail: Bereich mit besonders hoher Belastung oder langen Antwortzeiten am Ende einer Messverteilung.
- monotonic-Δt: Die verstrichene, stetig laufende Zeitdifferenz zwischen zwei Messpunkten – gut für präzise Zeitmessungen.
