TP25: Gehweg-Messung -- was eine WLAN-Uebergabe wirklich kostet

Die "~4 Sekunden je Wechsel" aus der Nachtmessung waren als Obergrenze markiert,
und die Vorsicht war berechtigt: 5 Pings/s auf das Telefon zeigen bei -48 bis
-55 dBm Uebergabekosten von 0 bis 2,6 s, meist unter einer halben Sekunde. Fast
Transition funktioniert. Der Zaehlerstand nach einer Neuanmeldung hatte die
Luecke vorgetaeuscht.

Der wahre Befund ist schlimmer und liegt woanders: bei -69 bis -77 dBm ist das
Telefon 6 bis 45 s nicht erreichbar, zweimal ueber 20 s am Stueck. Die Trennlinie
laeuft sauber entlang der Signalstaerke, nicht entlang der Wechsel -- es ist kein
Roaming-Problem, es ist ein Dead Spot.

Ehrlich dazu: ueber den ganzen Weg gingen 44 % der Pings verloren, und das ist
nicht alles Funk -- ein iPhone mit gesperrtem Display beantwortet ICMP verzoegert
oder gar nicht (RTT-Median 3,7 ms, Maximum 8,2 s). Power-Save haengt aber am
Display, nicht am Ort; dass alle langen Luecken in der schwachen Zone liegen und
alle kurzen in der starken, erklaert es nicht. Fuer eine exakte Zahl braucht es
ein waches Telefon.

tp6-monitor-core.sh bekommt eine Reconnect-Schleife: die SSH-Sitzung ist mitten
in der Messung weggebrochen und die Funkdaten endeten 2,5 Minuten vor dem
Ping-Mitschnitt -- ausgerechnet im interessanten Teil.

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

docs/tp25-wlan-roaming-messung-20260820.md

@@ -97,26 +97,59 @@ bisher an lokalen Ursachen geprüft wurde.
 
 ---
 
-## 5. Was die Lücke kostet — und was daran noch ungemessen ist
+## 5. Was die Lücke kostet — GEMESSEN am 2026-08-21
 
-Bei **jedem** beobachteten Wechsel steht in den Zählern des Managers für **rund 4 Sekunden** kein
-Durchsatz, danach folgen ~10 Sekunden mit halber PHY-Rate.
+**Methode:** `docs/tp25-walk-messung.sh` — 5 Pings/s **auf das Telefon** (`10.40.10.196`) plus
+Funk-Sampler im 1-s-Takt, während Christoph den Weg abgeht, den er beim Telefonieren wirklich geht.
+Kein Call, keine Last. 22 Minuten, 6.590 Pings, 10 AP-/Bandwechsel.
+Rohdaten: `docs/messdaten/tp25-gehweg-20260821/`.
 
-⚠️ **Diese 4 Sekunden sind eine Obergrenze, kein Beweis.** Nach einer Neuanmeldung beginnen die Zähler
-der Registration-Table bei null; ein Teil der Lücke kann Zähler-Artefakt statt echter Funkstille sein.
-Auch der Rücksprung von `uptime` auf `00:00:00` beweist **nicht**, dass keine Fast Transition stattfand —
-auch eine FT erzeugt am Zielradio einen neuen Eintrag.
+### 5.1 Das Ergebnis trennt sauber nach Signalstärke
 
-**Der saubere Test, der das entscheidet** (eine Zeile, read-only, beim nächsten Spaziergang mitlaufen
-lassen — vom Core, damit der Weg kurz ist):
+| Zeit | Wechsel | Signal | echter Paketverlust |
+|---|---|---|---|
+| 14:52:27 | ap2/5 → ap1/5 | −48 dBm | **2,6 s** |
+| 14:53:57 | ap1/5 → ap2/5 | −51 dBm | **keine messbare Lücke** |
+| 15:03:45 | ap2/5 → ap1/5 | −55 dBm | **0,2 s** |
+| 15:06:59 | ap1/5 → ap2/5 | −53 dBm | **2,0 s** |
+| 15:07:47 | ap2/2,4 → ap2/5 | −76 dBm | 0,4 s |
+| 15:07:07 | ap2/5 → ap2/2,4 | −76 dBm | **6,4 s** |
+| 15:08:17 | ap2/5 → ap2/2,4 | −69 dBm | **20,0 s** |
+| 15:08:30/33 | ap2 5↔2,4 (zweimal) | −77 dBm | **44,6 s** |
+| 15:09:28 | ap2/2,4 → ap2/5 | −76 dBm | **20,0 s** |
 
-```bash
-ping -i 0.2 10.40.10.196
-```
+🔴 **Die Trennlinie ist nicht der Wechsel, sondern das Signal.** Bei **−48 bis −55 dBm** kosten
+Übergaben **0 bis 2,6 s**, meist unter einer halben Sekunde — **Fast Transition funktioniert also.**
+Bei **−69 bis −77 dBm** kostet jeder Wechsel **6 bis 45 s**. Dort wechselt das Telefon nicht, es
+verliert die Verbindung.
 
-Ein Wechsel zeigt sich dann als **echter Paketverlust über N×200 ms**. Fällt dabei nichts aus, ist die
-Übergabe schnell und die 4 Sekunden waren Buchhaltung. Fallen 20 Pakete aus, ist es real — und dann ist
-es die Ursache für die Aussetzer im Call.
+### 5.2 Korrektur des Vorbefunds
+
+Die „~4 Sekunden je Wechsel" aus §4 waren als Obergrenze markiert — zu Recht: bei gutem Signal sind es
+**0,2 s**. Der Zählerstand nach einer Neuanmeldung hat die Lücke vorgetäuscht. **Was bleibt, ist der
+schlimmere Befund:** in der schwachen Zone ist das Gerät zweimal **über 20 Sekunden** nicht erreichbar.
+Ein Call ist da nicht gestört, er ist tot.
+
+### 5.3 Was diese Messung NICHT kann
+
+Über den ganzen Weg gingen **44 % der Pings** verloren — das ist nicht alles Funk. Ein iPhone mit
+gesperrtem Display beantwortet ICMP verzögert oder gar nicht; die RTT-Verteilung zeigt es (Median
+**3,7 ms**, 95. Perzentil **124 ms**, Maximum **8,2 s** = Aufwachen aus dem Ruhezustand).
+
+**Warum die Zuordnung oben trotzdem trägt:** Power-Save hängt am Displayzustand, nicht am Ort. Dass
+**alle** langen Lücken bei −69…−77 dBm liegen und **alle** kurzen bei −48…−55, lässt sich damit nicht
+erklären. Für eine Zahl auf zwei Stellen bräuchte es ein waches Telefon — am einfachsten mit laufendem
+Call, oder indem die Klick-Konsole **auf dem iPhone** offen bleibt (sie hält per Wake Lock das Display
+an und pollt alle 3 s).
+
+⚠️ **Werkzeug-Fund:** die SSH-Sitzung des Samplers ist um 15:09:57 weggebrochen
+(`Can't assign requested address`), die Funkdaten enden 2,5 Minuten vor dem Ping-Mitschnitt.
+`tp6-monitor-core.sh` hat deshalb jetzt eine Reconnect-Schleife und schreibt `RECONNECT` in die CSV.
+
+### 5.4 Die offene Frage an Christoph
+
+Die teure Zone liegt zeitlich bei **15:07–15:09**. **Wo warst du da?** Das ist der Dead Spot, und mit
+dem Raumnamen wird aus dem Befund eine Maßnahme.
 
 ---