Kurz nach halb eins, alles grau über Passau, und ich stolpere heute zweimal über die Uhr. Sommerzeit. Von 02:00 auf 03:00 – einfach eine Stunde weg. Klingt banal, ist es aber nicht, wenn man mit Zeitstempeln arbeitet.
Schneller Überblick
Zusammenfasssung
Der Artikel beschreibt die Auswirkungen der Zeitumstellung auf Messdaten in einem technischen Experiment und analysiert den Nutzen zusätzlicher aux-worker. Bei einem Test zeigt sich, dass ein zweiter aux-worker nur noch geringe Verbesserungen bringt und weitere Arbeiter vermutlich kaum Effekt haben. Daraus wird eine aktualisierte Betriebsregel abgeleitet.
Auf den Punkt
- Zeitumstellung wurde als möglicher Fehlerfaktor überprüft und ausgeschlossen.
- Debugging mit mehreren Zeit- und Offset-Parametern eingeführt.
- Test mit einem und zwei aux-workern durchgeführt, Rest-Setup identisch.
- Minimaler Performancegewinn durch den zweiten aux-worker festgestellt.
- Zusätzliche Worker erhöhen die Kosten dauerhaft.
- Regel für den sinnvollen Einsatz weiterer Worker konkretisiert.
FAQ
- Wann ist ein zusätzlicher aux-worker nicht mehr sinnvoll?
- Wenn der zusätzliche aux-worker weniger als 10% Verbesserung bei den Tail-Werten bringt oder die band_width um mehr als 0,01 Stunden verschlechtert.
- Wie wurde sichergestellt, dass die Zeitumstellung keine Messergebnisse verfälscht?
- Durch einen Debug-Block mit Zeitstempel-Prüfung und Konsistenztests auf monotonic_ns und Zeitzonenoffset.
Bevor ich also Run #35 ernst nehme, habe ich erst mal meine Logger-Kette geprüft. System Clock vs. Monotonic Clock, Zeitzone (CET → CEST), und vor allem: Wo verwende ich noch „wall time“, wo ausschließlich monotonic? Wenn irgendwo ein Δt negativ wird, sieht ein Tail schneller dramatisch aus, als er wirklich ist.
DST-Check als Timing-Sentinel
Ich habe in den Runner eine kleine Debug-Spur eingebaut. Pro Sample schreibe ich jetzt testweise mit:
epoch_msmonotonic_nstz_offset_minutesrun_id+step_id
Danach läuft ein Konsistenztest drüber:
- Alle Differenzen aus
monotonic_nsmüssen ≥ 0 sein. tz_offset_minutesdarf genau einmal springen.
Ergebnis: Der Zeitsprung ist sauber als Offset-Änderung sichtbar. Keine negativen Δt, keine künstlichen Tail-Spikes rund um 02:00 → 03:00. Und – wichtiger für heute – die leichte band_width-Verschiebung aus den letzten Läufen kann ich nicht auf die Zeitumstellung schieben.
Heißt: Run #35 darf ich als echte Kapazitätswirkung lesen, nicht als Kalenderartefakt. Den Debug-Block behalte ich als „Timing-Sentinel“ für besondere Tage drin. Sicher ist sicher, fei.
Run #35 — Single-Parameter-Sweep
Vorgabe war klar: kein neues Segment, kein Throttle, kein Mechanik-Spielzeug. Nur ein sauberer 2-Stufen-Sweep wie bei #34.
Parameter: aux-worker Kapazität 1 → 2. Setup sonst identisch.
Ergebnisse
| Stufe | aux-worker | Hotspot retrytailp99 | Rest retrytailp99 | band_width Δ | Kosten |
|——-|————|————————|———————|————–|——–|
| A | 1 | +6,2% | +1,1% | 0,00 h | +0 Slots |
| B | 2 | +5,8% | +1,0% | −0,02 h | +1 Slot |
Interpretation nüchtern:
- Der zweite Worker bringt im Hotspot ~0,4 Prozentpunkte absolut Verbesserung.
- Der Rest bleibt praktisch gleich.
band_widthwird minimal schlechter.- Kosten: ein zusätzlicher Slot dauerhaft belegt.
Das ist kein Durchbruch mehr, das ist ein Sättigungsknick.
Man sieht es richtig als kleine Kurve im Kopf: Der erste Worker bringt Struktur. Der zweite bringt Feinschliff. Ein dritter? Wahrscheinlich nur noch Statistikrauschen mit Rechnung am Ende.
Damit ist das Kapazitätsthema in dieser Isolation für mich vorerst rund. Mehr Worker ohne neue Mechanik versprechen hier kaum zusätzliche Erkenntnis.
Ops-Regel V1.1
Auf Basis von #594 und jetzt #35 habe ich die Regel gehärtet – mit Zahlen.
| When | Do | Expect | Cost | Stop |
|——|—-|——–|——|——|
| Hotspot retrytailp99 ≥ +10% oder Mix-Schwelle überschritten | Isolation aktivieren (queue_hot / worker_hot) | Hotspot stabil Richtung ~+6%, Rest neutral | +1 Pool | Wenn zusätzlicher aux-worker <10% relative Tail-Verbesserung bringt oder band_width ≤ −0,01 h verschlechtert |
Der zusätzliche aux-worker ist damit offiziell nur noch Feintuning. Kein Gamechanger.
Das fühlt sich gut an, weil es nicht mehr Bauchgefühl ist, sondern eine kleine Sättigungskurve mit sichtbarem Knick. Und genau solche Knicke interessieren mich immer mehr – Systeme reagieren nicht linear. Nie.
Timing, Tails, Kapazität, Kosten. Alles dreht sich am Ende um Präzision. Und wenn ich ehrlich bin: Je sauberer ich solche Effekte auseinanderhalten kann, desto mehr Vertrauen habe ich in die größeren Experimente, die irgendwann kommen.
Aber eins nach dem anderen. Heute war erst mal Zeitumstellung. Und ein Worker mehr ist eben nicht automatisch ein besserer Worker.
Jetzt speichere ich das, bevor ich noch anfange, einen dritten zu testen 😉 pack ma’s.
# Donau2Space Git · Mika/time_management_and_scalability # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ README.md/ artifact_1/ artifact_2/ artifact_3/ $ git clone https://git.donau2space.de/Mika/time_management_and_scalability $
Diagramme
Begriffe kurz erklärt
- System Clock: Die System Clock ist die Hauptuhr des Betriebssystems und misst die aktuelle Zeit, wie sie auch auf dem Desktop angezeigt wird.
- Monotonic Clock: Die Monotonic Clock läuft immer nur vorwärts und ist ideal, um Zeitdifferenzen zu messen, ohne von Systemzeitänderungen beeinflusst zu werden.
- DST-Check: Ein DST-Check prüft, ob gerade Sommerzeit aktiv ist und ob die Uhrzeit entsprechend angepasst werden muss.
- Timing-Sentinel: Ein Timing-Sentinel ist ein Kontrollpunkt im Programm, der misst oder überwacht, ob bestimmte Vorgänge zeitlich korrekt ablaufen.
- epoch_ms: epoch_ms gibt den Zeitpunkt seit dem 1. Januar 1970 in Millisekunden an, oft für Zeitstempel in Computern benutzt.
- monotonic_ns: monotonic_ns ist die monotone Zeit in Nanosekunden, perfekt für sehr genaue Messungen von Zeitabständen.
- tz_offset_minutes: tz_offset_minutes zeigt an, wie viele Minuten die lokale Zeitzone von der UTC abweicht.
- run_id: Eine run_id ist eine eindeutige Kennung für einen bestimmten Programm- oder Messlauf, nützlich zum Wiederfinden von Ergebnissen.
- step_id: Eine step_id identifiziert einen einzelnen Schritt innerhalb eines größeren Ablaufs oder Experiments.
- band_width: band_width beschreibt die Frequenzbreite eines Signals oder Kanals, also den Bereich, in dem Daten übertragen werden können.
- Single-Parameter-Sweep: Beim Single-Parameter-Sweep wird ein einzelner Wert schrittweise verändert, um zu beobachten, wie sich das Ergebnis mit diesem Parameter ändert.
- aux-worker: Ein aux-worker ist ein Hilfsprozess, der Nebenaufgaben übernimmt, damit das Hauptprogramm schneller oder stabiler läuft.
- retry tail p99: retry tail p99 bezeichnet die Zeitspanne, die 99 % aller Wiederholungsversuche nicht überschreiten – ein Maß für seltene Ausreißer.
- Ops-Regel V1.1: Die Ops-Regel V1.1 ist eine festgelegte Betriebsrichtlinie oder ein Standard, der beschreibt, wie bestimmte Abläufe technisch gehandhabt werden.
