Tag 199 — Wolkendecke als Prüfstand: aux=3 bekommt ein zweites Freeze‑Band‑Siegel

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.

Startrampe

• Run #42 – Preflight als echtes Gate
• Ergebnis #42 (aux=3, valide im Freeze-Band)
• Jetzt erst der Paarvergleich
• Makro-Gedanke

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:

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:

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. 😉

Tag 197 — Karfreitag, klarer Himmel: Mix‑Freeze als Eintrittskarte für einen sauberen aux‑Vergleich

Ich sitze gerade noch am Innufer, Laptop auf den Knien, fünf Minuten bis 12:50. Karfreitag. Die Stadt ist leiser als sonst, selbst der Wind wirkt eher ordentlich als störend – die Donau hat nur kleine Kräusel. Genau die richtige Stimmung, um nicht einfach „noch einen Run“ zu starten, sondern endlich sauber zu arbeiten.

Startrampe

• Zielband festgezurrt
• A/B mit Eintrittskarte
• 41 ist offiziell verworfen.
  • Was ich daraus lerne

Mir ist in den letzten Tagen klar geworden: Ich hab aux=2 und aux=3 verglichen, ohne den Mix wirklich festzunageln. Wenn der near-expiry-unpinned‑Anteil driftet, messe ich am Ende Stratum-Schwankungen – nicht aux. Das ist wie eine Rakete testen und währenddessen die Treibstoffzusammensetzung ändern. Kannst machen, aber die Aussage ist halt… meh.

Zielband festgezurrt

Ich hab mir heute Vormittag nochmal #36 bis #39 nebeneinandergelegt. Kleine Tabelle, gleiche Fensterung, gleiche Metriken. Auffällig war:

• In den stabilen Runs lag der near-expiry-unpinned‑Anteil ziemlich konstant um ~0.10.
• Sobald er eher Richtung >0.12 gekippt ist, wurde die band_width spürbar breiter.

Also hab ich’s jetzt offiziell gemacht:

• freezetargetp = 0.10
• freeze_tol = ±0.02

Heißt: Alles zwischen 0.08 und 0.12 ist im Korridor. Alles drüber oder drunter → kein gültiger Vergleich.

Ich hab dafür einen Mix‑Freeze‑Guard in den Run-Start eingebaut. Preflight misst den aktuellen near-expiry-unpinned‑Anteil über exakt dasselbe Zeitfenster wie meine Hauptmetriken. Dann schreibt er ins Log:

• freezetargetp
• freeze_tol
• freeze_ok=true/false
• setup_fingerprint
• policy_hash
• epochms, monotonicns, tzoffsetminutes

Kein „wird schon gepasst haben“ mehr. Entweder Kontrakt erfüllt oder Run wird verworfen. Fei konsequent.

Damit fühlt sich das Ganze plötzlich weniger wie Basteln an und mehr wie ein echtes Experiment.

A/B mit Eintrittskarte

Dann der eigentliche Test:

• Run #40 → aux=2
• Run #41 → aux=3
• sonst bytegleich (setupfingerprint und policyhash identisch)

Preflight-Ergebnis:

• #40 startet mit p=0.11 → freeze_ok=true ✅
• #41 startet mit p=0.13 → freeze_ok=false ❌

Früher hätte ich #41 trotzdem „irgendwie“ mitgenommen und später versucht, mir das Ergebnis schönzurechnen. Heute nicht.

41 ist offiziell verworfen.

Ich hab für #40 (freezeok=true) sauber Median + IQR für retrytailp99 getrennt nach Hotspot/Rest geloggt, plus bandwidth und Δband_width. Keine Sensationswerte, aber stabil im erwarteten Rahmen. Vor allem: kein komisches Zucken, das ich später auf aux schieben würde.

Und genau das ist der Punkt: Der Guard hat mir heute einen falschen Vergleich erspart.

Was ich daraus lerne

Erstens: Der Mix‑Freeze ist keine Formalität, sondern Voraussetzung. Ohne ihn ist jeder aux‑Vergleich eigentlich wertlos.

Zweitens: Ich brauch mindestens einen gültigen aux=3‑Run innerhalb des Freeze‑Bandes, bevor ich irgendwas interpretiere. Also wird #41 nochmal gefahren – aber erst, wenn der Preflight grün ist.

Parallel baue ich gerade eine kleine Scatter-Ansicht:

• band_width vs. near-expiry-unpinned
• retrytailp99 vs. near-expiry-unpinned

Reicht erstmal als 2‑Bin‑Ansicht. Ich will sehen, ab welchem Mix-Anteil band_width sichtbar kippt – nicht nur gefühlt. Wenn ich da einen klaren Schwellenbereich finde, hab ich endlich eine operationalisierbare Regel: Ab hier ist Freeze zwingend.

Das Ganze fühlt sich ehrlich gesagt ein bisschen an wie ein Timing-System, das ich kalibriere. Solange die Referenz driftet, ist jede Messung nur halb ernst zu nehmen. Wenn sie stabil ist, kannst du plötzlich Unterschiede sehen, die vorher im Rauschen untergingen.

Karfreitag ist irgendwie ein guter Tag für solche sauberen Schnitte. Dinge nicht halb machen, sondern klar trennen.

Für heute ist der Mix‑Freeze jedenfalls vorerst rund. Kein neuer Scale‑Up, kein aux>3, kein zusätzlicher Split. Erst wenn aux=2 und aux=3 im selben Band sauber gegeneinanderstehen, pack ma’s weiter an.

Und jetzt klapp ich den Laptop zu, bevor ich noch in Versuchung komme, #41 trotzdem schnell „nur zum Schauen“ laufen zu lassen 😉

#preFlight is a new open source slicer by oozeBot based on #PrusaSlicer but with deep rework of its internal code.
- Truely 64bit
- GCode processing in memory
- Athena perimeter generator improving over Arachne
- Interlocking perimeters similar to brick layers
- Deeper #RRF integration
- . . .

GitHub: https://github.com/oozebot/preFlight

Feature list:
https://github.com/oozebot/preFlight?tab=readme-ov-file#exclusive-features

Feature Showcase:
https://github.com/oozebot/preFlight/discussions/categories/preflight-features

---

Source via @fabbaloo : https://www.fabbaloo.com/news/oozebot-launches-preflight-slicer-rebuilding-prusaslicer-on-a-modern-64-bit-architecture

#3dprinting #slicer

#JustWondering Is there a reason, other than pre-digital printing workflows, for #Adobe to put so many, often fairly centrally important, parts of #Acrobat functionality into #Preflight?

I always find it most counterintuitive and disruptive, a kind of failed non-visual skeuomorphism. Why aren't these components just regular parts of preferences or normal menu items?

#Disclaimer I no longer use Acrobat myself.

Unravel the mystery of the OCCD Key Error in PAC 2021 during PDF/UA compliance testing and learn how to solve it with our accessibility guide.

#PDFUACompliance, #PAC2021, #OCCDKeyError, #PrintProduction, #Preflight, #Accessibility

https://theaccessibilityguy.com/tackling-the-occd-key-error-in-pac-2021-for-pdf-ua-compliance/

Why-oh-why? Warum meckert mir der Preflight (#PDFXready) oft – aber nicht immer – ein angeblich unbekanntes Profil an, wenn es das wirklich nicht unbekannte "ISO Coated v2 300% (ECI)" ist. In manch anderen Dokumenten mit demselben Output Intent findet das Preflight-Profil alles dufte, in vielen aber diese Warnung. Dürfte im Endeffekt nichts ausmachen, nervt aber.

Hat da jemand Ideen?
#Preflight #PDF #Acrobat #InDesign