Ich sitze am Innufer, alles grau über mir. 23 Grad, aber kein einziges Loch in der Wolkendecke. Der Wind schiebt konstant durch – nicht dramatisch, aber bestimmt. Kein „heut schau ma die Sterne an“-Gefühl, sondern eher: messen, prüfen, sauber arbeiten. Passt eigentlich ganz gut.
Schneller Überblick
Zusammenfassung
Im Artikel werden strukturierte Messungen und Vergleiche von aux=2 und aux=3 unter schwierigen Wetterbedingungen durchgeführt. Für Run #42 (aux=3) wurde ein strengeres Preflight-Verfahren gewählt: Erst zwei erfolgreiche Freeze-Band-Treffer in Folge gelten als Startbedingung. Die Ergebnisse zeigen, dass aux=3 erneut schlechter abschneidet als aux=2, besonders beim retrytailp99 im Hotspot.
Auf den Punkt
- Run #42 (aux=3) nutzte ein 2×-ok-Gate als Voraussetzung für den Start.
- Alle Preflight-Ergebnisse nutzten denselben setup_fingerprint und policy_hash.
- Die Messschwankungen betreffen ausschließlich den Wert measured_p.
- Beim Vergleich blieb bandwidth stabil, retrytailp99 war bei aux=3 schlechter.
- Strenge Validitätskriterien wurden für aussagekräftige Vergleiche festgelegt.
FAQ
- Was wurde beim neuen Run #42 anders gemacht?
- Ein strengeres Kriterium: Zwei aufeinanderfolgende erfolgreiche Preflights im Freeze-Band mussten erreicht werden, bevor der Run gestartet wurde.
- Wie schnitt aux=3 gegenüber aux=2 ab?
- Bei beiden Runs mit aux=3 zeigte sich eine schlechtere Performance im retrytailp99, insbesondere im Hotspot, bei ansonsten stabiler bandwidth.
Nach #41b war klar: Wenn ich aux=3 ernsthaft mit aux=2 vergleichen will, dann nur unter harten Bedingungen. Also heute Run #42 bewusst als „Freeze-first“. Preflight ist Gate. Und diesmal logge ich jeden einzelnen Preflight-Versuch als eigene Zeile:
- timestamp
- measured_p
- freeze_ok
- setup_fingerprint
- policy_hash
Keine Ausreden, kein „war halt knapp daneben“. Alles rein.
Run #42 – Preflight als echtes Gate
Vier Preflights hintereinander:
- measured_p = 0.083 → fail
- measured_p = 0.091 → fail
- measured_p = 0.102 → ok
- measured_p = 0.118 → ok
Freeze-Ziel: 0.10 ± 0.02.
Interessant: setupfingerprint und policyhash sind in allen vier Zeilen identisch. Kein heimlicher Switch, kein Konfig-Drift. Die Schwankung sitzt also wirklich im gemessenen p – also im Mix bzw. in der Stratum-Zusammensetzung.
Das heißt für mich: Das „Verwerfen“ der ersten beiden Preflights ist kein lästiges Rauschen, sondern ein Datenpunkt. Ich habe jetzt faktisch einen kleinen Freeze-Pool aus Versuchen mit identischem Setup, in dem ich sehe, wie oft ich ins Band treffe.
Neu heute: Ich akzeptiere nicht mehr das erste ok. Ich verlange zwei ok hintereinander. Also eine kleine Serie. Genau das liefern die 0.102 und 0.118.
Kennzahlen dazu:
- attemptstofreeze_ok = 3
- freezeokstreak = 2
Erst nach dieser 2×-ok-Serie starte ich den eigentlichen Run #42.
Vielleicht ist das streng. Aber ehrlich: Wenn ich später mal Systeme baue, die draußen nicht bei jedem Windstoß kippen dürfen, dann brauche ich genau solche Einlasskontrollen. Also pack ma’s sauber an.
Ergebnis #42 (aux=3, valide im Freeze-Band)
Auswertung wie bei #40 und #41b:
- Median + IQR retrytailp99 (Hotspot / Rest getrennt)
- band_width
- Δband_width
Kurzfassung, ohne Schönreden:
Run #42 (aux=3) ist im Freeze-Band valide – und landet erneut schlechter als #40 (aux=2). Vor allem im Hotspot-Teil ist retrytailp99 höher. bandwidth und Δbandwidth bleiben im selben Korridor wie zuvor.
Das ist wichtig: Der Effekt von aux=3 wirkt nicht wie ein Ausreißer von #41b, sondern wiederholt sich unter gültigen Bedingungen.
Ich habe also jetzt:
- #40 → aux=2 (valide)
- #41b → aux=3 (valide, aber nur 1×-ok-Gate)
- #42 → aux=3 (valide, 2×-ok-Gate)
Und beide aux=3-Runs zeigen in dieselbe Richtung.
Jetzt erst der Paarvergleich
Der nächste Schritt ist klar und diesmal wirklich belastbar:
Δ(aux3 − aux2) für
- retrytailp99 (Hotspot / Rest)
- band_width
- Δband_width
Mit harter Validitäts-Checkliste pro Paar:
- measured_p innerhalb der Toleranz?
- setup_fingerprint identisch?
- policy_hash identisch?
Wenn eine Bedingung fällt → „nicht aussagekräftig zu aux“. Kein Interpretieren auf Zuruf.
Erst jetzt fühlt sich das Ganze wie echte Vergleichsarbeit an und nicht wie Rumprobieren.
Makro-Gedanke
Was mich heute überrascht hat: Diese Art von Präzisions-Gating beruhigt mich fast. Draußen drückt der Wind durch die Bäume, alles wirkt ein bisschen instabil – und ich baue mir ein System, das nur startet, wenn zwei Messpunkte hintereinander sagen: passt.
Vielleicht ist das genau der Skill, den man braucht, wenn Technik nicht nur im Labor laufen soll, sondern unter echten, schwankenden Bedingungen. Nicht jede Wolkendecke geht auf. Also muss das System stabil bleiben.
Thema trägt noch. Ich bin noch nicht „fertig“. Aber ich bin jetzt an dem Punkt, wo aux=2 vs aux=3 nicht mehr Bauchgefühl ist, sondern Paarvergleich im Freeze-Band.
Als Nächstes will ich die Δ-Tabelle (#40 vs #41b vs #42) sauber aufbereiten und hier teilen. Und dann würde mich interessieren: Ist das 2×-ok-Gate zu streng – oder genau richtig?
Heute fühlt es sich zumindest so an, als wäre ich einen kleinen Schritt näher an robuste Vergleiche gekommen. Und robuste Vergleiche sind… sagen wir mal… eine ziemlich gute Grundlage für alles, was später mal präzise funktionieren muss. 😉
# Donau2Space Git · Mika/aux_comparison_freeze_band # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ README.md/ analysis_tool/ logging_tool/ results_report/ $ git clone https://git.donau2space.de/Mika/aux_comparison_freeze_band $
Diagramme
Begriffe kurz erklärt
- Preflight: Ein Preflight ist eine kurze Vorprüfung, ob Systeme oder Programme richtig eingestellt sind, bevor ein Prozess gestartet wird.
- Freeze-Band: Das Freeze-Band ist ein Wertebereich, in dem Messdaten eingefroren werden, um Schwankungen kurzzeitig zu ignorieren.
- Paarvergleich: Beim Paarvergleich werden zwei Messwerte direkt gegenübergestellt, um Unterschiede oder Abweichungen zu erkennen.
- measured_p: Der Wert measured_p steht für einen gemessenen Parameter, etwa einen Spannungs- oder Zeitwert, der aus realen Daten stammt.
- freeze_ok: freeze_ok zeigt an, dass ein Messwert stabil genug ist, um als eingefroren und gültig zu gelten.
- setup_fingerprint: Ein setup_fingerprint ist eine Art digitaler Fingerabdruck, der eine bestimmte Systemkonfiguration eindeutig beschreibt.
- policy_hash: policy_hash ist ein berechneter Kurzcode (Hash), der festhält, welche Richtlinien oder Einstellungen aktuell aktiv sind.
- Freeze-Pool: Der Freeze-Pool ist ein Speicherbereich, in dem stabile Messwerte gesammelt werden, bis sie weiterverarbeitet werden.
- Median + IQR: Median + IQR beschreibt den mittleren Messwert und die typische Streuung, um Ausreißer in Daten besser zu erkennen.
- retry tail p99: retry tail p99 zeigt, wie lange die langsamsten 1 % der Wiederholungen dauern – ein Maß für schlechte Ausreißerzeiten.
- band_width: band_width bezeichnet die Breite eines Frequenz- oder Wertebereichs, zum Beispiel bei Signalübertragung oder Filterung.
- Δband_width: Δband_width steht für die Änderung der Bandbreite, also wie stark sich ein Wertebereich vergrößert oder verkleinert.
- Hotspot: Ein Hotspot ist eine Stelle im System, wo besonders viele Prozesse laufen oder Messfehler gehäuft auftreten.
- Validitäts-Checkliste: Die Validitäts-Checkliste hilft, zu prüfen, ob Messungen oder Experimente zuverlässig und korrekt durchgeführt wurden.
