TP6 gemessen: Fall B, aber nicht hoerbar -- und der laute Befund liegt bei TP25

Die TP6-Praemisse ist ausgefuehrt: drei Messreihen von einem kabelgebundenen
Client in VLAN10, zwei davon mit laufendem Telegram-Videocall an zwei Orten.

Ergebnis (Runbook §5): unter Dauer-Upload steigt die Latenz von 13 auf 40--60 ms,
im Download auf 36--41 ms. Das sind +28 bis +47 ms und damit ueber der Schwelle
von 30 ms, die §3 VOR der Messung festgelegt hat -- formal Fall B, CAKE ist
begruendet. Die Einschraenkung gehoert zur Zahl: durch alle sechs Lastphasen lief
ein Videocall, und es wurde kein einziger Problem-Button gedrueckt. Messbar ja,
wahrnehmbar nein. waveform sagt zeitgleich Grade A -- kein Widerspruch, sondern
ein kuerzerer Test, dessen Upload-Verteilung zweigipflig ist (25. Perzentil
14,5 ms, 75. Perzentil 47,5 ms).

Erstmals dokumentiert: die tatsaechliche Linerate. Upload 9,6 Mbit, Download
54,6 Mbit. Die im Repo kolportierten "~10 Mbit" galten immer nur dem Upload.

Der lautere Befund ist ein Nebenprodukt: der Core-Sampler hat 2,5 Stunden lang
das iPhone mitgeschrieben. Sticky Client (ein Weg durchs ganze Haus, dreimal
direkt an ap1 vorbei, eine einzige Uebergabe -- und die erst oben bei -73 dBm)
und Band-Ping-Pong (zwoelf Wechsel in neun Minuten am selben Ort). Je Wechsel bis
zu 4 s ohne Durchsatz -- als Obergrenze notiert, denn die Zaehler starten nach
einer Neuanmeldung bei null; der saubere Test per ping auf das Telefon steht aus.
Das passiert TROTZ aktivem 802.11k/v und FT, live geprueft: damit ist die
Merkregel ref_ft_is_not_roaming historisch. Der Bandabstand von 8--10 dB ist
dabei normale Physik; das Problem ist, dass 5 GHz an den Telefonier-Orten bei
-75 bis -80 dBm landet.

Zwei Messfehler bleiben dokumentiert, weil sie die Methode betreffen und beide
denselben Typ haben -- die Anzeige war gruen, die Wirkung fehlte:
speed.cloudflare.com/__down antwortet ohne User-Agent mit 403 und einem Byte
(saubere Ping-Reihe ueber tote Flows), und ein Call lief 5,5 Minuten ohne
Treiber (Marker geschrieben, nichts gemessen).

Status nachgezogen -- Header inklusive: TP6 von "Praemisse pruefen" auf
"gemessen, Fall B, nachrangig", TP25 auf kritischen Pfad. Rohdaten liegen unter
docs/messdaten/tp6-20260820/, damit die Zahlen nachpruefbar bleiben.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/teilprojekte.md

@@ -64,7 +64,15 @@ ab jetzt bei jeder Änderung mitgezogen, nicht nur die TP-Abschnitte.)*
 
 </details>
 
-**Nächster Schritt (Stand 2026-08-18): die TP6-Prämisse messen, nicht CAKE bauen.**
+**Nächster Schritt (Stand 2026-08-21): TP25 — die WLAN-Übergaben, nicht CAKE.**
+> 📌 **Die TP6-Prämisse ist am 2026-08-20/21 gemessen** (Runbook §5): formal Fall B (+28…+47 ms unter
+> Dauer-Upload), aber im Videocall **nicht wahrnehmbar** — kein einziger Problem-Klick über sechs
+> Lastphasen. Laut war stattdessen der Funk: **Sticky Client + Band-Ping-Pong, zwölf Wechsel in neun
+> Minuten**, je Wechsel bis zu 4 s ohne Durchsatz →
+> [`tp25-wlan-roaming-messung-20260820.md`](tp25-wlan-roaming-messung-20260820.md). Deshalb steht jetzt
+> **TP25 vor TP6**; TP6 bleibt offen und begründet, aber nachrangig.
+>
+> *Vorherige Fassung (Stand 2026-08-18, erledigt):*
 TP6 wird hier seit Monaten als „DAS Ziel" geführt, aber `docs/call-quality-diagnosis.md` hat den
 Bufferbloat 2026-06-16 bereits gemessen (**A/A+**, „CAKE wäre marginal, nicht deployt"). Die Messung
 stammt aus der FritzBox-Ära, der Edge ist seither getauscht — also **einmal gegen den heutigen Edge
@@ -405,7 +413,25 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 - **(b) Live-Torch als Ad-hoc-Observability:** DNS ist bei direktem 1.1.1.1 blind, **Flows nicht** (NATen über ap1). `torch` auf `vlan30`/`vlan50` gefiltert auf die Geräte-IP zeigt Ziel-IPs live (Versuni → AWS `eu-west-1` IoT erkennbar). Voraussetzung: Gerät aktiv. Merkregel: Airfryer nur online wenn er kocht → Capture ans Einschalten koppeln.
 - **Abh.:** UNTRUSTED-Move des Airfryers (Kandidat, s. VLAN50) + TP5-Deny-by-default. Kein Blocker.
 
-### TP6 — QoS/CAKE + Call-Quality-A/B-Test ▸ 🟠 **PRÄMISSE PRÜFEN, BEVOR gebaut wird**
+### TP6 — QoS/CAKE + Call-Quality-A/B-Test ▸ 🟡 **GEMESSEN 2026-08-20/21 — Fall B, aber „messbar, nicht hörbar"**
+> ✅ **Die Prämisse ist geprüft. Ergebnis + Rohdaten: [`tp6-praemisse-messrunbook.md`](tp6-praemisse-messrunbook.md) §5.**
+>
+> | | idle / C0 | Upload-Last | Download-Last |
+> |---|---|---|---|
+> | Durchlauf 1 (ohne Call) | 12,9 ms | **60,4 ms** | 41,3 ms |
+> | Ort 1 Küche (mit Call) | 13,2 ms | **42,8 ms** | 37,1 ms |
+> | Ort 2 Terrasse (mit Call) | 12,8 ms | **40,4 ms** | 36,3 ms |
+> | Referenz 2026-06-16 | 12 ms | 17,5 ms | *nie gemessen* |
+>
+> **Linerate erstmals dokumentiert: Upload 9,6 Mbit · Download 54,6 Mbit.**
+> Der Anstieg liegt in der Senderichtung bei **+28 bis +47 ms** und damit über der §3-Schwelle von
+> ≲30 ms → **formal Fall B, CAKE ist begründet.** 🔴 **Aber:** durch alle sechs Lastphasen lief ein
+> Telegram-Videocall, und es wurde **kein einziger Problem-Button gedrückt**. Messbar ja, wahrnehmbar
+> nein. waveform gibt zeitgleich **Grade A** — kein Widerspruch, sondern ein kürzerer Test (Erklärung
+> in §5.3). **Empfehlung: TP6 bleibt offen und begründet, hat aber niedrigere Priorität als TP25** —
+> was die Calls tatsächlich zerreißt, sind die WLAN-Übergaben, und die repariert keine Queue.
+> Wenn gebaut wird: **erst `/queue` ins GC-Template + ComplianceRule** (§4.1), dann die Queue, dann
+> dieselbe Messung als A/B-Nachweis.
 > 📋 **Eigene Session, Einstieg: `docs/handoff-tp6-session.md`** (Übergabe 2026-08-19),
 > Arbeitsplan: `docs/tp6-praemisse-messrunbook.md`. Abbruchkriterium steht **vor** der Messung fest.
 - 🔴 **Der Widerspruch, der zuerst aufzulösen ist:** dieser TP wird seit Monaten als „DAS Ziel" geführt —
@@ -418,10 +444,11 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 - ⚖️ **Was das relativiert:** die Messung stammt aus der **FritzBox-Ära**. Seither ist der Edge komplett
   getauscht (Arris im Bridge-Mode, NAT und Queuing liegen auf `crs326-core`). Die Leitung ist dieselbe,
   das Pufferverhalten des neuen Edge ist **ungemessen**.
-- ➡️ **Erster Schritt ist deshalb keine Konfiguration, sondern eine halbe Stunde Messen:**
-  Bufferbloat-Test gegen den heutigen Edge. Kommt wieder A/A+ heraus, ist TP6 **erledigt statt offen**
-  und der kritische Pfad ist leer. Kommt es schlechter heraus, ist die Ursache neu und CAKE ist die
-  Antwort darauf — dann aber mit einer Zahl als Begründung.
+- ✅ **ERLEDIGT 2026-08-20/21 — gemessen statt vermutet** (die frühere Fassung dieser Zeile verlangte
+  genau das): der Bufferbloat-Test gegen den heutigen Edge ist gefahren, dreimal, davon zweimal mit
+  laufendem Videocall an verschiedenen Orten. Es ist **schlechter geworden als 2026-06-16** (60,4 statt
+  17,5 ms avg unter derselben Sättigung), die Ursache ist damit neu und liegt **nicht** an der Core-CPU
+  (~10 % unter Upload-Last). Zahlen und Einordnung: Runbook §5.
 - 🔎 **Fasttrack ist auf dem Core faktisch tot — und das ist kein Entwurf, sondern ein Unfall**
   (Befund 2026-08-18): die Regel `defconf: accept est,rel,untracked` steht **vor**
   `defconf: fasttrack`, also wird Fasttrack nie erreicht. Live: **32.979.171 Pakete** auf der
@@ -1187,7 +1214,24 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 - **Abh.:** keine harten. **TP15 ✅** (die zu versorgende Hardware steht und hat DC-Eingänge). Verwandt: **TP18** (Garage-Nodes brauchen je Site eine Stromversorgung), **TP11** (USV-Zustand ins Monitoring). **Kein Blocker für TP5/TP6.**
 - **Historie:** war bis 2026-08-16 Unterpunkt von TP15 („🔋 DC-USV: MeanWell LRS-150-48 + DDR-120-48 + LiFePO4 20Ah (~€190), 48V-Bus; CRS326 DC-input passt"). Vollständige Recherche inkl. Schaltbild, Effizienzvergleich und Gerätetabelle: `docs/hw-refresh-requirements.md §9` (+ §10 D/E/F für die offenen Fragen).
 
-### TP25 — WLAN-Stabilisierung ▸ ⏳ **Funkparameter + Drift-Erkennung durch; offen nur noch Messarbeit** — Sammel-TP für Christophs Beobachtungen 1–6
+### TP25 — WLAN-Stabilisierung ▸ 🔴 **JETZT KRITISCHER PFAD (2026-08-21) — Roaming gemessen, Befund liegt vor** — Sammel-TP für Christophs Beobachtungen 1–6
+> 🆕 **Messung 2026-08-20/21: [`tp25-wlan-roaming-messung-20260820.md`](tp25-wlan-roaming-messung-20260820.md)**
+> (Nebenprodukt der TP6-Messreihen, Core-Sampler im 2-s-Takt über 2,5 h, teils mit laufendem Videocall).
+> Drei Befunde:
+> **(A)** Der Bandabstand 2,4 ↔ 5 GHz beträgt **8–10 dB** — physikalisch normal (6,7 dB allein
+> Freiraumdämpfung), **keine** Konfigurationsursache. Das Problem ist der Absolutwert: 5 GHz liegt an
+> den Telefonier-Orten bei **−75 bis −80 dBm**.
+> **(B)** **Sticky Client:** ein Weg Küche → Kinderzimmer → Schlafzimmer → Terrasse, dreimal direkt an
+> ap1 vorbei (−43 dBm), **eine einzige Übergabe** — und die erst oben bei −73 dBm.
+> **(C)** **Band-Ping-Pong: 12 Wechsel in 9 Minuten** am selben Ort, immer ap2 5↔2,4 GHz. Je Wechsel
+> bis zu **4 s ohne Durchsatz** (⚠️ Obergrenze, s. Doku §5 — der saubere Test `ping -i 0.2 10.40.10.196`
+> während eines Spaziergangs steht aus).
+> **Und das passiert TROTZ aktivem 802.11k/v und FT** — live geprüft: `st-main` mit `rrm=yes`/`wnm=yes`,
+> `ft-over-ds=yes`. Die Merkregel `ref_ft_is_not_roaming` („11k/v fehlen") ist damit **historisch**.
+> **Reihenfolge der Maßnahmen** (Doku §6, respektiert die User-Randbedingung „kein neuer AP, solange
+> nicht alles aus den vorhandenen rausgeholt ist"): erst die Lücke messen → 5 GHz auf **20 MHz** statt
+> 20/40 (+3 dB Link-Budget, für 1,2 Mbit Call irrelevant an Durchsatz) → **Fund E** (`signal-range`-Boden
+> am Manager) → **2,4 GHz NICHT vorschnell drosseln** (dort hängen ~20 IoT-Geräte) → dritter AP zuletzt.
 > **Restliste (Stand 2026-08-18):** Fund A–D ✅ · Drift-Luecke ✅ (mit TP28, 92/92) ·
 > **offen: Fund E** (`access-list` mit `signal-range`-Boden — ⚠️ gehoert jetzt auf den **Manager**,
 > nicht mehr auf die APs) · **Fund F** (5:05-Takt bei IoT-Trennungen, am Manager nachmessen —