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/tp6-praemisse-messrunbook.md

@@ -1,6 +1,6 @@
 # TP6 — Prämissen-Messung: hat dieses Netz überhaupt ein Bufferbloat-Problem?
 
-> **Stand 2026-08-19 · vorbereitet, nicht ausgeführt.** Dieses Runbook ändert **nichts** am Netz.
+> **Stand 2026-08-21 · AUSGEFÜHRT, Ergebnis in §5.** Dieses Runbook ändert **nichts** am Netz.
 > Es misst, und es sagt vorher, was das Ergebnis bedeutet.
 >
 > **Der Deliverable dieses Runbooks ist eine Entscheidung, keine Queue.**
@@ -184,7 +184,88 @@ umgedreht wurde sie beim handgebauten Core-Aufbau in TP21.1.
 
 ---
 
-## 5. Abnahme dieses Runbooks
+## 5. Ergebnis der Messung (2026-08-20/21)
+
+> **Ausgeführt.** Drei Messreihen von einem kabelgebundenen Client in VLAN10 (MacBook, `en5`,
+> 10.40.10.183, am Dock an `crs326-branch`). Vorbedingungen vor jeder Reihe geprüft: WARP
+> `Disconnected`, Wi-Fi aus, genau eine 10.40er-Adresse, WAN im Leerlauf (114 kbit rx / 97 kbit tx).
+
+### 5.1 Die Linerate — erstmals dokumentiert
+
+| Richtung | gemessen | Beleg |
+|---|---|---|
+| **Upload** | **9,6 Mbit** (1.199.317 B/s) | 10-s-Vollast-Probe |
+| **Download** | **54,6 Mbit** sustained | `vlan100` rx über die gesamte Sättigungsphase |
+
+Die im Repo kolportierten „~10 Mbit" stimmen für den Upload. Für den Download gab es bisher **gar
+keine** Zahl.
+
+### 5.2 Die drei Messreihen
+
+Alle Werte ms, `min/avg/max`, 24 Pings gegen 1.1.1.1.
+
+| | idle bzw. C0 | Upload-Last | Download-Last | danach (C1) |
+|---|---|---|---|---|
+| **Durchlauf 1** — ohne Call | 10,4 / **12,9** / 53,6 | 32,5 / **60,4** / 115,2 | 11,1 / **41,3** / 67,3 | — |
+| **Ort 1 (Küche)** — mit Videocall | 10,2 / **13,2** / 22,3 | 30,2 / **42,8** / 66,6 | 16,1 / **37,1** / 43,7 | 10,4 / 13,4 / 23,7 |
+| **Ort 2 (Terrasse)** — mit Videocall | 10,4 / **12,8** / 18,9 | 29,7 / **40,4** / 63,5 | 15,4 / **36,3** / 49,6 | 10,3 / 13,0 / 18,5 |
+| Referenz **2026-06-16** | 12 | **17,5** / max 26 | *nie gemessen* | — |
+
+**Core-CPU:** unter Upload-Last ~10 % — die CPU ist nicht der Engpass. Unter Download-Last dagegen
+**33,6 % avg / 41 % max** bei 55 Mbit; für die Bufferbloat-Frage irrelevant, für die offene
+Inter-VLAN-Frage (§4.2) ein Datenpunkt.
+
+### 5.3 waveform als Gegenprobe: Grade A — und warum das kein Widerspruch ist
+
+| | unloaded | ↓ aktiv | ↑ aktiv |
+|---|---|---|---|
+| Median | 15,8 ms | 33,4 ms | 36,0 ms |
+| 95. Perzentil | 20,7 ms | 41,2 ms | **57,0 ms** |
+| Jitter | **2,0 ms** | 3,8 ms | **15,3 ms** |
+
+Der Grade kommt aus dem **Median**. Die Verteilung des Upload-Tests ist aber zweigipflig — 25. Perzentil
+**14,5 ms**, 75. Perzentil **47,5 ms** —, also stammt ein Teil der Messpunkte aus der Zeit, *bevor* der
+Puffer voll war. Genau das erwartet man bei einem kurz anrampenden Test. Die Ping-Reihe hält die
+Sättigung 55 s bei 10,3 Mbit angebotener Last auf einer 9,6-Mbit-Leitung und misst deshalb den
+**eingeschwungenen** Zustand. Beide Messungen zeigen dasselbe Verhalten an verschiedenen Punkten der
+Kurve; der Jitter-Sprung von 2 auf 15,3 ms bestätigt die Richtung.
+
+### 5.4 Die Entscheidung: Fall B — aber „messbar, nicht hörbar"
+
+Gegen die Tabelle aus §3: der Anstieg über idle beträgt in der **Senderichtung +28 bis +47 ms** und
+liegt damit über der Schwelle von ≲30 ms. **Formal ist das Fall B: CAKE ist begründet.**
+
+🔴 **Die Einschränkung gehört zur Zahl:** durch alle sechs Lastphasen an zwei Orten lief ein
+Telegram-Videocall, und es wurde **kein einziger Problem-Button gedrückt** — weder von Christoph noch
+nach Gelis Rückmeldung. Der Anstieg ist messbar, war aber in dem Anwendungsfall, für den TP6 überhaupt
+existiert, **nicht wahrnehmbar**. Wer daraus eine Queue baut, baut sie gegen ein reales, aber leises
+Problem: den Fall „jemand lädt dauerhaft hoch, während telefoniert wird".
+
+**Was dagegen laut war, hat mit TP6 nichts zu tun:** die WLAN-Übergaben. Siehe
+[`tp25-wlan-roaming-messung-20260820.md`](tp25-wlan-roaming-messung-20260820.md).
+
+### 5.5 Zwei Messfehler, die dokumentiert bleiben, weil sie die Methode betreffen
+
+1. **Die erste Download-Reihe war eine Nicht-Messung.** `speed.cloudflare.com/__down` beantwortet ein
+   `curl` mit Default-User-Agent mit **403 und einem Byte**; die drei Flows waren sofort tot, die
+   Ping-Reihe zeigte saubere 12,1 ms — und das hätte als „kein Bufferbloat im Download" im Runbook
+   gestanden. Aufgefallen ist es **nur am Core-Sampler**: 164 kbit statt 50 Mbit auf `vlan100`.
+   → Skript schickt jetzt User-Agent + Referer.
+2. **Ein Call lief 5,5 Minuten ohne Treiber.** Der Start-Klick schrieb einen Marker, aber es lief keine
+   Sättigung und kein Sampler; „kein einziges Problem" war deshalb kein Ergebnis, sondern die Abwesenheit
+   einer Messung. → Der Treiber meldet sich jetzt im 5-s-Takt, die Konsole warnt sichtbar, wenn keiner läuft.
+
+Beide sind derselbe Fehlertyp: **die Anzeige war grün, die Wirkung fehlte** (`feedback_abnahme_wirkung_nicht_anzeige`).
+
+### 5.6 Rohdaten
+
+`docs/messdaten/tp6-20260820/` — Sampler-CSVs (Core: CPU, WAN-Rate, Client-Funkwerte im 2-s-Takt),
+Marker, Ping-Reihen und der durchgehende Latenz-Mitschnitt. Auswertung mit
+`python3 docs/tp6-auswertung.py --sampler <csv> --markers <csv>`.
+
+---
+
+## 6. Abnahme dieses Runbooks
 
 1. Beide Messreihen (Up **und** Down, idle **und** Last) liegen als Zahlen vor, nicht als Eindruck.
 2. Die Entscheidung ist gegen die Tabelle aus §3 gefallen — **nicht** gegen ein Bauchgefühl.