time_management_and_scalability/artifact_3/README.md

# Einfluss der Zeitumstellung auf Worker-Kapazität und Effizienz

## Purpose

Analyse der Stabilität und Performance von Systemen während einer Zeitumstellung, insbesondere mit Fokus auf Worker-Skalierung und Timing-Konsistenz.

**Problemstellung:** Zeitumstellungen beeinflussen Zeitstempel und Messungen. Ziel ist, echten Performance-Einfluss von artefaktbedingten Verzerrungen zu trennen.

**Ziele:**
- Überprüfung der Systemreaktion auf Zeitsprünge (CET → CEST)
- Validierung von Zeitmessungen bei Lauf #35 gegen mögliche Zeitumstellungsartefakte
- Quantifizierung des Effekts eines zusätzlichen aux-workers auf Kapazität und Latenz

## Kontext & Hintergrund

Läufe mit aufgezeichneten Zeitreihen zu Performance und Timing-Metriken, inklusive Zeitzonen-Offsets.

**Gruppierung:**
- Run #34
- Run #35

**Trace-Metadaten / zusätzliche Tags:**
- epoch_ms
- monotonic_ns
- tz_offset_minutes
- run_id
- step_id

**Domänenkontext:**
- Zeitsynchronisation in produktionsnahen Workload-Systemen
- Bewertung von Skalierungseffekten auf Worker-Basis

**Motivation:**
- Korrekte Interpretation von Messdaten trotz Zeitsprung
- Ermittlung des Skalierungseffekts von zusätzlichen aux-workern

## Methode / Spezifikation

**Übersicht:**
- Einführung eines Timing-Sentinels zur Überwachung von Zeitkonsistenz während der DST-Umstellung
- Durchführung eines Single-Parameter-Sweeps mit Variation der aux-worker-Anzahl von 1 auf 2

**Algorithmen / Verfahren:**
- Erfassen pro Sample: epoch_ms, monotonic_ns, tz_offset_minutes, run_id, step_id
- Validierung: Differenzen aus monotonic_ns ≥ 0; tz_offset_minutes darf einmal springen
- Analyse des Einflusses zusätzlicher aux-worker auf Hotspot- und Restlatenz (retry_tailp99)

## Input / Output

### Input-Anforderungen

**Hardware:**
- Multi-core Umgebung mit konfigurierbaren Worker-Slots

**Software:**
- Logger mit monotonic-time Unterstützung
- Zeitzonen-aware Scheduler

**Konfiguration:**
- Zeitzone CET/CEST
- aux-worker=1 oder 2

### Erwartete Rohdaten

**Felder pro Run:**
- epoch_ms
- monotonic_ns
- tz_offset_minutes
- run_id
- step_id

**Formatbeispiele:**
- [1711850400000, 123456789000, 120, 35, 004]

**Trace-Daten:**
- Format: CSV oder JSON mit Zeitstempeln und Performance-Metriken
- Hinweis: Zeitzonenwechsel muss als Sprung in tz_offset_minutes erkennbar sein

### Analyse-Ausgaben

**Pro Gruppe / pro Governor:**
- retry_tailp99 Hotspot
- retry_tailp99 Rest
- band_width Δ
- Kosten in Slots

**Vergleichsausgaben:**
- aux-worker=1 vs aux-worker=2
  - Δ: −0,4 Prozentpunkte Hotspot Tail

## Workflow / Nutzung

**Analyse-Workflow:**
- Prüfe DST-Konsistenz per Timing-Sentinel
- Verifiziere monotonic_ns Differenzen ≥ 0
- Führe Run unter identischen Parametern außer aux-worker aus
- Berechne Differenzen für retry_tailp99 zwischen Stufen A und B
- Interpretiere Messabweichungen unter Berücksichtigung von Kosten und band_width

### Trace-Template-Anforderungen

**Ziel:** Erkennung und Isolation von Zeitumstellungsartefakten

**Erforderliche Tags & Metadaten:**
- run_id
- step_id
- monotonic_ns
- tz_offset_minutes

**trace-cmd-Setup:**
- Monotonic clock aktivieren
- Zeitzonenwechsel simulieren oder protokollieren

**Run-Design für Contributors:**
- Vergleiche Worker 1 und Worker 2 unter konstantem Setup

## Interpretation & erwartete Ergebnisse

**Kernbefunde:**
- Zeitumstellung beeinflusst Messwerte nicht, wenn monotonic clock konsequent genutzt wird.
- Hotspot-Rückgang um ~0,4 Prozentpunkte bei zusätzlichem aux-worker.
- Restlatenzen und band_width nahezu unverändert.

**Implikationen für Experimente:**
- Skalierung über zwei Worker hinaus liefert nur marginale Gewinne.
- Zeitumstellung ist als bekannte, aber kontrollierbare Störquelle zu betrachten.

**Planungsziel:**
- Ziel: Definition eines stabilen Kapazitätspunkts trotz DST-Ereignis
- Vorgehen:
  - DST-Sentinel zur Anomalieerkennung nutzen
  - Worker-Skalierung schrittweise validieren
  - Kapazitätskurven mit Sättigungspunkt identifizieren

## Limitationen & Fallstricke

**Datenbezogene Limitationen:**
- Fehlende Korrektur bei Loggern mit wall time kann negative Δt erzeugen.
- Unvollständige Zeitzonen-Metadaten verfälschen Vergleichbarkeit.

**Kausalität & Generalisierbarkeit:**
- Ergebnisse gelten nur für diese Worker-Konfiguration.
- Übertragbarkeit auf heterogene Workload-Muster unbestätigt.

**Praktische Fallstricke:**
- Fehlkonfigurierte Zeitzonen springen mehrfach pro Lauf.
- Nebenläufige Scheduler-Ticks können pseudo-negative Δt maskieren.

## Nächste Schritte & Erweiterungen

**Geplante Experimente:**
- Untersuchung eines dritten aux-workers zur Verifikation der Sättigung
- Test komplexerer Mechanismen (Throttle, Segmente)

**Analyseziele:**
- Quantitative Modellierung der Worker-Sättigungskurve
- Trennung von Laufzeit- und Energieeinflüssen

**Community-Beiträge:**
- Bereitstellung eines generischen DST-Sentinel-Skripts für Systemexperimente