Christoph Emsenhuber
cf44ce6a1e
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>
17 lines
1.2 KiB
Markdown
17 lines
1.2 KiB
Markdown
# Rohdaten TP6-Prämissenmessung + TP25-Roaming, 2026-08-20/21
|
||
|
||
Auswertung: `python3 docs/tp6-auswertung.py --sampler <sampler.csv> --markers <markers.csv>`
|
||
|
||
| Ordner | Was |
|
||
|---|---|
|
||
| `durchlauf1-ohne-call/` | Leitungsmessung ohne Call, 21:24–21:29. ⚠️ Die erste Download-Phase darin ist eine **Nicht-Messung** (403 ohne User-Agent); gültig ist die Wiederholung ab Marker `PHASE_3neu_*`. |
|
||
| `ort1-kueche/` | Videocall + Sättigung, 23:11–23:17, Client auf ap1/5 GHz. Danach Langzeit bis 23:41 — darin der Weg Küche → Terrasse mit der Übergabe um 23:40:07. |
|
||
| `ort2-terrasse/` | Videocall + Sättigung, 23:46–23:52, Client auf ap2/5 GHz. Danach Langzeit bis 00:12 — darin das Band-Ping-Pong (12 Wechsel in 9 min). |
|
||
|
||
**Sampler-Spalten:** `ts_epoch, ts_local, ros_time, cpu, wan_rx_bps, wan_tx_bps, sta_iface, sta_signal,
|
||
sta_tx_rate, sta_rx_rate, sta_tx_bps, sta_rx_bps, sta_uptime, sta_last_activity`.
|
||
`sta_iface`: `cap-wifi1` = ap1/5 GHz · `cap-wifi2` = ap1/2,4 GHz · `cap-wifi3` = ap2/5 GHz · `cap-wifi4` = ap2/2,4 GHz.
|
||
|
||
`ping-dauerlauf.log` ist der durchgehende 1-Hz-Mitschnitt **vom kabelgebundenen MacBook** — er zeigt die
|
||
WAN-Strecke, **nicht** den Funk des iPhones. Für die Funklücke fehlt ein `ping` auf `10.40.10.196`.
|