[Docs] (P12): exit gate (b) passes - a WSL client replays the in-world trace over Wi-Fi TCP at ssim 0.999883; the load frame is bandwidth-bound, the steady state is latency-bound

docs/Disaggregated/notes/p12/CROSSHOST-ACCEPTANCE.md

@@ -0,0 +1,44 @@
+# P12 出口门 (b)：另一台机器经 TCP 在 Redmi 入世界
+
+> 2026-09-28。client = WSL 里的 `mobilegl_trace_replay`（Windows 主机上另一套系统），server = Redmi `2f7cbe2e`（Adreno 830）的 trace APK server（`930c29e9`，split 构建），
+> 控制面 TCP + 数据面 stream，DirectGLES，run-ahead 开。链路：手机 Wi-Fi（5 GHz 11ax，RSSI −36）↔ 主机以太网，经 `192.168.31.1`。
+> 驱动 [`tools/device_bench/disagg/crosshost_accept.sh`](../../../../tools/device_bench/disagg/crosshost_accept.sh)，汇总 `crosshost_report.py`，原始数据 `.trace-work/perf-compare/crosshost/`。
+> WSL 默认路由是主机 `xray_tun` 代理（会终结 TCP）；脚本加临时 /32 路由绕开它，并先跑 `tcp_path_check.sh`（用完删路由、停 server）。
+
+## 结论
+
+**门 (b) 通过。** 另一台机器上的 client 经 TCP 重放 Minecraft 世界内 trace（rd12），画面与设备上一致；P6.5 必测数已记录。
+client 是 trace 重放器，不是活的 Minecraft 实例（那是门 (a) 的 FCL 那一半）。
+
+| 检查 | 结果 |
+|---|---|
+| ssim（非 benchmark，重放到目标调用） | openra **1.000000**；rd12 **0.99988301**（与设备上四臂同值 0.999883） |
+| rd12 benchmark，251/251 帧、rc=0 | 三次（PRESENT_CREDIT 1/2/3）全部跑完 |
+| openra benchmark，128/128 帧、rc=0 | 三次全部跑完 |
+
+## 必测数
+
+| 项 | openra | rd12 |
+|---|---|---|
+| 稳态 fps（第 2 帧起的帧时中位数），credit 1 / 2 / 3 | 133.5 / 114.3 / 104.6 | 16.9 / 21.3 / 22.1 |
+| 首帧（加载帧）耗时 | 1.2–1.6 s | 51–53 s |
+| 加载帧 stage 字节 | 247 MB（整段） | 2,698 MB |
+| 稳态 stage 字节/帧（均值） | 1.81 MB | 1.52 MB |
+| 稳态实测吞吐 | 26–38 MB/s | 20.6–24.3 MB/s |
+| `wait_replies`（整段） | 1 | 324–350 |
+| 回包 RTT 均值 / p50 上界 / p99 上界 | 4.1–6.8 ms / 8.2 ms / 8.2 ms | 15.7–17.3 ms / 4.1–8.2 ms / 131 ms |
+| client 线程 CPU（整段） | 1.2–1.3 s | 6.2–7.2 s |
+
+- **加载帧受带宽约束，稳态不是。** server 侧实测：加载帧 2,696 MB 在 51 s 里读完（`P65ServerFrame`，**52.4 MB/s** 持续），稳态只有 20–24 MB/s，每帧平均 1.5 MB 的话带宽本可撑到 ~34 fps。
+  稳态帧时 ~90% 是 `transport_wait`（client 发送本身每帧 <0.5 ms，`credit_wait_ms=0`），所以剩下的是往返延迟而不是 present 信用。
+- **`PRESENT_CREDIT` 1 → 2：rd12 稳态 +26%（16.9 → 21.3）；2 → 3 只再 +4%。** openra 上 credit 越大反而略低，落在噪声内（单次）。
+- Wi-Fi 往返 RTT（`ping`）3.3–61 ms（均值 19），4.6–110 ms（均值 30）两次测量；手机省电状态影响大，逐次差别很大。
+- 第一次直连跑同一 rd12 是 235 s（加载帧 220 s），本轮 70 s：同样的 2.7 GB，**Wi-Fi 吞吐在不同时刻差 4 倍**。以上数字是这一时刻的，不是上限。
+- `toybox nc` 汇点测得 18–22 MiB/s，**低估了链路**：同一时刻 server 自己读到 52 MB/s。`netbench.sh` 测的是 nc 汇点，不是 Wi-Fi 上限（见下）。
+
+## 没做
+
+- 门 (a)：FCL 同机 spawn、双后端入世界、杀 server 报 device-lost。
+- 活的 Minecraft 在另一台机器上跑（这里是 trace 重放）。
+- loopback tcp 对 spawn 的逐线程 CPU 差（五臂对比给了 fps，没给逐线程 CPU）。
+- 每档只跑了一次，没有重复；credit 差别小于噪声的地方（openra）不下结论。

docs/Disaggregated/notes/p12/README.md

@@ -8,7 +8,7 @@
 - 形状：server APK 自建 `ANativeWindow`（`MobileGLDisplayActivity` 的 SurfaceView，进程内 TCP server，会话串行）把渲染流**上屏**；离屏路径保留、同一时刻一条活跃；client 以 `WindowKind::ServerOwned`（控制修订 3）**完全无头**接入，几何由 server 回传；失窗 → `Fatal{ServerWindowLost}` → 干净 device-lost。
 - 进展：15 个 `(P12)` 提交 + 审查轮修复（10 个问题，ID-P12-5..11）已并入 `feat/disaggregated`；主机门绿（ID-P12-14）、G1 成立（ID-P12-15）；审查后在 `1fb18d9e` 上完成 P12 定向 CTest 46/46 和 Redmi 真机七项复测。当前分支 `0fe01588` 后续提交只改了文档、文档检查范围和基准脚本说明文字，未改 P12 实现。
 - **2026-09-25 追加（会话交接 §4/§5.1）**：**device-lost 的 DECLINED 回复容忍**与**纹理上传的等待粒度**已落地，各有自己的 red-once 门（前者就是进世界后 `Fatal{ProtocolCorruption, "Fence.reply"}` 那条崩溃；后者让单条纯上传的回包等待 1 → 0）。真机端到端（进世界不崩、那一帧墙钟）与 G1 本机复核仍待做，见 [`DEVICELOST-AND-UPLOAD-WAITS.md`](DEVICELOST-AND-UPLOAD-WAITS.md)。
-- 未完成：出口门 (a) FCL 同机 spawn + 杀 server 的 device-lost、(b) 跨机 TCP 入世界 + P6.5 必测数；`CONTRACT-P12.md`；阶段表行里的其余条目（`unix:` 监听、DirectGLES 去全局、freezer、多 context、FCL 开关接线、D8 白名单）。
+- 出口门 (b) 已于 2026-09-28 通过（[`CROSSHOST-ACCEPTANCE.md`](CROSSHOST-ACCEPTANCE.md)）。未完成：出口门 (a) FCL 同机 spawn + 杀 server 的 device-lost；`CONTRACT-P12.md`；阶段表行里的其余条目（`unix:` 监听、DirectGLES 去全局、freezer、多 context、FCL 开关接线、D8 白名单）。
 
 ## 阶段表行（原 `ROADMAP.md`）
 
@@ -73,7 +73,7 @@ Android 上的 server 自建窗口（自己的 SurfaceView）把 IPC 渲染流**
 | 主机门 | ✅ unit 2605/2605，spawn / tcp 与三条 Magma 双进程车道全绿；剩余红全部归容器的 CMake/CTest 版本 | ID-P12-14 |
 | 真机七项检查（Redmi `2f7cbe2e`） | ✅ 审查轮之前（`29b7b284`）及审查后（`1fb18d9e`）；审查后详细结果见上方复测补记 | PLAN-P12 §2、ID-P12-13 |
 | 出口门 (a) | ❌ FCL 同机 spawn、双后端入世界、**杀 server** 产生干净 device-lost（本轮的驱动是 trace_replay，device-lost 由按 HOME 触发） | PLAN-P12 §3 |
-| 出口门 (b) | ❌ **另一台机器**的 client 经 TCP 在 Redmi 入世界，并记录 P6.5 必测数（本轮 client 是 `adb forward` 环路） | PLAN-P12 §3 |
+| 出口门 (b) | ✅ 2026-09-28：WSL 里的 client 经 Wi-Fi TCP 重放 Minecraft 世界内 trace，rd12 ssim 0.999883、openra 1.0，251/251 与 128/128 帧，必测数已记录；client 是 trace 重放器，不是活的 Minecraft | [`CROSSHOST-ACCEPTANCE.md`](CROSSHOST-ACCEPTANCE.md) |
 
 ### 4. 在跑
 
@@ -81,7 +81,7 @@ Android 上的 server 自建窗口（自己的 SurfaceView）把 IPC 渲染流**
 
 ### 5. 下一步
 
-1. **出口门**：先 (b) 跨机 TCP 入世界 + P6.5 必测数，再 (a) FCL + 杀 server。
+1. **出口门**：(b) 已过（[`CROSSHOST-ACCEPTANCE.md`](CROSSHOST-ACCEPTANCE.md)）；剩 (a) FCL + 杀 server。
 2. **收尾**：写 `MG_Remote/CONTRACT-P12.md`；修 `notes/p12/gate.sh` 的 G1 符号比较（与基准不同源，会印出误导的 `added=N removed=N`）；按惯例做一次收官审查。
 3. **阶段表行里的余项**（交接时在树上核过，均未做）：in-process server 的 `unix:` 监听、DirectGLES `g_Display` / `g_Surface` / `g_Context` 去全局、cached-app freezer、多 context、FCL env 与 plugin 开关表接线、D8 窗口种类白名单。
 4. 其后按 [`ROADMAP.md`](../../ROADMAP.md)：monolith 跑道 P8；IPC 跑道 P9 → P10 → P11；P6.5 残余（39 例 device 矩阵 + 必测数）与 P3b/P4b 余项并行；`CONTRACT-P7.md` §12 的记录债按阶段认领。

docs/Disaggregated/notes/perf-five-arm-20260928/README.md

@@ -22,7 +22,7 @@
 | spawn+shm | 178.3 | 5.61 | 5.26 | **快 36%**；与 inproc 打平（历史门 8 同结论） |
 | spawn+tcp localhost | 21.0–23.1 | 43.3–48.3 | 45–49 | **比 shm 慢 ~8 倍** |
 | spawn+tcp localhost + `SPIN_US=2000` | 63.6 | 15.7 | — | 单 knob A/B，**2.9×** |
-| tcp over Wi-Fi（WSL → 手机，绕开 xray） | 17.4 | 57.4 | — | 单次；251/251 帧、rc=0；Wi-Fi RTT 4.6–110 ms（均值 30） |
+| tcp over Wi-Fi（WSL → 手机，绕开 xray） | 稳态 16.9–22.1（credit 1–3） | — | 43.6–63.7 | 三次；251/251 帧；含 51–53 s 加载帧的整段均值 13.3–16.5；详见 [`p12/CROSSHOST-ACCEPTANCE.md`](../p12/CROSSHOST-ACCEPTANCE.md) |
 
 ### openra（轻负载，128 帧；28 draws/帧、199 记录/帧）
 
@@ -33,7 +33,7 @@
 | spawn+shm | 88.8 | 11.27 | −12%，纯跨进程固定成本 |
 | spawn+tcp localhost | 76.9 | 13.00 | −24% |
 | spawn+tcp 同机 wlan0 IP（Wi-Fi 替代拓扑，不过空口） | 74.2–76.3 | 13.1–13.5 | ≈ tcp localhost，符合预期 |
-| tcp over Wi-Fi（WSL → 手机，绕开 xray） | 4.2 | 239.3 | 单次；128/128 帧；被 RTT × 同步点主导 |
+| tcp over Wi-Fi（WSL → 手机，绕开 xray） | 稳态 104.6–133.5（credit 1–3） | 7.6–9.6（中位） | 三次；128/128 帧。早先记的 4.2 fps 是均值被首帧拉低的读法，不是稳态 |
 
 ## 结论
 
@@ -65,13 +65,12 @@
    | seq 3 挂死 | 控制面帧重组 / 双 reader 竞态 | 主机 `xray_tun` 终结 TCP 后中继卡住 | 同一对二进制：经 xray 挂死 13/13，每次前送日志都停在同一字节（1093 B）；绕开后 openra 与 rd12 都 rc=0 |
    | 「client 字节已被 ACK」 | 手机内核 ACK | xray 本地 ACK | client 侧 `ss` 的 RTT 0.07–0.3 ms、PMTU 9000；手机看到的对端是 `192.168.31.183` |
    | 「server 卡在 MakeCurrent」 | apply 线程卡死 | server 已空闲 | 手机本地 `mgl.server.log` 走完了整个 backend 初始化，只有**前送**的日志停在第 7 条扩展；控制 / 数据两个 socket 的收发队列都是 0 |
-   | Wi-Fi RTT | avg 0.78 ms | 4.6–110 ms（均值 30，省电模式） | 绕开 xray 后 `ping` 20 次 |
-   | Wi-Fi 吞吐 | 19–22 MiB/s | 14.3–19.9 MiB/s（3 次） | 绕开 xray 后 `nb.py` 128 MiB，链路 11ax 5.8 GHz 1441 Mbps |
+   | Wi-Fi RTT | avg 0.78 ms | 3.3–110 ms，两次均值 19 / 30 | 绕开 xray 后两次 `ping` |
+   | Wi-Fi 吞吐 | 19–22 MiB/s 是上限 | **`toybox nc` 汇点低估了**：同期 server 自己读到 52.4 MB/s 持续 51 s（2,696 MB）；同一 rd12 加载帧第一次跑 235 s、之后 52 s，吞吐随时刻差 4 倍 | server 侧 `P65ServerFrame`；`nc` 18–22 MiB/s |
 
-   rd12 满速需要 ~49 MB/s。按中位 816 KB/帧算，**Wi-Fi 臂上限只有 ~18–26 fps**（原文的 40–45 算错了）。
-   实测 17.4 fps ≈ 14.2 MB/s，已经贴着带宽。
-   openra 每帧都有同步点：239 ms/帧 ≈ 8 × 平均 RTT。
-   要提速，得减流量（压缩 / 去重）并加深 credit 来摊薄 RTT。
+   **原来的两个 Wi-Fi 上限结论都撤回**：rd12 经 Wi-Fi 稳态 17–22 fps（每帧均值 1.5 MB、20–24 MB/s），低于实测 52 MB/s，所以稳态不是带宽约束，而是往返延迟；
+   openra 稳态 105–133 fps，并没有被 RTT 卡住。加载帧（2.7 GB）才是带宽约束。
+   `PRESENT_CREDIT` 1 → 2 让 rd12 稳态 +26%，2 → 3 只再 +4%。
    **P6.5（09-22）与 P12（09-26）里 WSL → 手机的链路数也都经过 xray**（`xray_tun` 自 09-21 起在线）：通过 / 失败的结论不受影响，但其中的链路 RTT / 吞吐需要带这个前提来读。
 
 ## 优化建议（按优先级）