[Docs] (Disaggregated): the cross-host eglMakeCurrent hang was the host's xray TUN proxy stalling its relay, not MobileGL; direct Wi-Fi runs pass and are bandwidth-bound

2026-11-07 01:53:24 +09:00 · 2026-09-28 22:57:20 -04:00
parent 429b4472bb
commit b4f0c53426
4 changed files with 33 additions and 25 deletions
@@ -26,18 +26,18 @@ Android 上的 server 应用自己开一个全屏窗口，把收到的渲染流
 | spawn+shm | 178 fps（+36%） | 89 fps（−12%） |
 | spawn+tcp localhost | 21–23 fps | 77 fps（−24%） |
 | tcp localhost + `SPIN_US=2000` | 63.6 fps（2.9×） | — |
-| tcp over Wi-Fi | hang，0 有效帧 | — |
+| tcp over Wi-Fi（WSL → 手机） | 17.4 fps（带宽约束） | 4.2 fps（RTT 约束） |

 - inproc / shm 重负载比 monolith 快（run-ahead 并行 + 探针更少）；轻负载只付固定握手成本。
 - tcp 慢的主因：present credit=1 串行等待 ~74% + futex 唤醒税；不是带宽。
- **跨主机 TCP 在 `eglMakeCurrent`（控制面 seq 3）100% 挂死**（源码 bug，疑控制面帧重组 / 双 reader 竞态）——验收 B 的直接阻塞项；修好后 Wi-Fi 吞吐 19–22 MiB/s 仍使 rd12 上限 ~40–45 fps。
+- 原先记录的「跨主机 TCP 在 `eglMakeCurrent` 挂死」**不是源码 bug**：WSL 流量被主机 v2rayN 的 `xray_tun` 终结后中继卡住。绕开后 rd12 / openra 都跑通；跨机测试前先跑 `tools/device_bench/disagg/tcp_path_check.sh`。
+- 直连 Wi-Fi 吞吐 14–20 MiB/s，所以 rd12 经 Wi-Fi 的上限 ~18–26 fps。

 ## 下一步

-1. 修跨主机控制面 hang（`RunSession` 控制泵 / `ControlInbox` 读状态机；脚本 `tools/device_bench/disagg/wifi_hang_repro.sh` 等）。
-2. 打验收 B（另一台机器经 TCP 入世界）与验收 A（FCL 同机 spawn、双后端、杀 server 报 device-lost）。
-3. 收尾：写 `MG_Remote/CONTRACT-P12.md`、修门脚本误导的一行输出、收官审查。
-4. 零代码 knob A/B：`PRESENT_CREDIT=2`、shm 臂 server `SPIN_US` 降到 20–35、`SERVER_AFFINITY`；代码级：client doorbell 换 futex/eventfd、applier 自适应 spin、sendmsg 跨 Flush 合批。
-5. 之后按 [`ROADMAP.md`](ROADMAP.md)：P8；P9 → P10 → P11。
+1. 打验收 B（另一台机器经 TCP 入世界；先过 `tcp_path_check.sh`）与验收 A（FCL 同机 spawn、双后端、杀 server 报 device-lost）。
+2. 收尾：写 `MG_Remote/CONTRACT-P12.md`、修门脚本误导的一行输出、收官审查。
+3. 零代码 knob A/B：`PRESENT_CREDIT=2`、shm 臂 server `SPIN_US` 降到 20–35、`SERVER_AFFINITY`；代码级：client doorbell 换 futex/eventfd、applier 自适应 spin、sendmsg 跨 Flush 合批。
+4. 之后按 [`ROADMAP.md`](ROADMAP.md)：P8；P9 → P10 → P11。

 **阻塞**：没有需要决策的事项。
@@ -27,7 +27,7 @@
  那一帧 **221.5 s → 182.8 s（−17%）**；设备定频+关深度空闲则是 **166.5 s（−25%）**。服务端日志会打印 `spin 2000 us` 自证。
  见 [`notes/p12/DEVICELOST-AND-UPLOAD-WAITS.md`](notes/p12/DEVICELOST-AND-UPLOAD-WAITS.md) §2.6–2.10。
 - **画面正确**：Vulkan 后端真机画面检查 36/36 通过，CTS 五块相对基线没有超过 0.5 个百分点的退步、没有新崩溃（P7）；server 自有窗口上屏两后端 SSIM 1.0（P12）。
- **五臂传输对比（2026-09-28，未定频交错 A/B）**：重负载（rd12）下 inproc ≈ spawn+shm 比 monolith **快约 1/3**（run-ahead 流水线并行 + applier 路径探针更少），轻负载（openra）下 split 只付固定开销；**tcp localhost 慢 ~8 倍，瓶颈是 present credit=1 的串行等待（~74%）+ futex 唤醒税**，`MOBILEGL_IPC_SPIN_US=2000` 单项实测 21.7→63.6 fps；**跨主机 TCP 在 `eglMakeCurrent` 处 100% hang**（字节级证据链，P12 验收 B 的阻塞项），且实测 Wi-Fi 吞吐 19–22 MiB/s 使重负载 Wi-Fi 臂上限 ~40–45 fps。全文 [`notes/perf-five-arm-20260928`](notes/perf-five-arm-20260928/README.md)。
+- **五臂传输对比（2026-09-28，未定频交错 A/B）**：重负载（rd12）下 inproc ≈ spawn+shm 比 monolith **快约 1/3**（run-ahead 流水线并行 + applier 路径探针更少），轻负载（openra）下 split 只付固定开销；**tcp localhost 慢 ~8 倍，瓶颈是 present credit=1 的串行等待（~74%）+ futex 唤醒税**，`MOBILEGL_IPC_SPIN_US=2000` 单项实测 21.7→63.6 fps；跨主机 TCP 的「`eglMakeCurrent` hang」**是测试环境造成的**（主机 v2rayN `xray_tun` 终结 TCP 后中继卡住，不是源码 bug）；绕开后 WSL → 手机经 Wi-Fi 跑通：rd12 17.4 fps、openra 4.2 fps。直连 Wi-Fi 吞吐 14–20 MiB/s，所以 rd12 上限 ~18–26 fps；RTT 4.6–110 ms。P6.5 / P12 的 WSL → 手机链路数也都经过 xray。全文 [`notes/perf-five-arm-20260928`](notes/perf-five-arm-20260928/README.md)。

 ## 按阶段

@@ -48,4 +48,4 @@
 | 14 | P6.5 | 跨机 TCP 102/102；断线约 5 s 检测到 | [`notes/p65`](notes/p65/README.md) |
 | 15 | P7 | 真机画面 36/36；server 内存无界增长收住（主机 825 → 546 MiB） | [`notes/p7`](notes/p7/README.md) |
 | 16 | P12 | 审查后真机复测：Espryt SSIM 1.0；Magma 1.0 / 0.999999511；P12 定向 CTest 46/46；纹理上传回包等待 1→0（主机机制门，真机墙钟待测）；FCL 与跨机 TCP 收官门仍待完成 | [`notes/p12`](notes/p12/README.md) |
-| 17 | 五臂传输测量（2026-09-28，非阶段） | inproc/shm 重负载比 monolith 快 ~1/3；tcp localhost 瓶颈是 credit=1 + 唤醒税（SPIN_US=2000 → 2.9×）；跨主机 TCP hang 证据链 | [`notes/perf-five-arm-20260928`](notes/perf-five-arm-20260928/README.md) |
+| 17 | 五臂传输测量（2026-09-28，非阶段） | inproc/shm 重负载比 monolith 快 ~1/3；tcp localhost 瓶颈是 credit=1 + 唤醒税（SPIN_US=2000 → 2.9×）；跨主机 hang 实为主机 xray TUN 代理造成；直连 Wi-Fi rd12 17.4 fps（带宽约束） | [`notes/perf-five-arm-20260928`](notes/perf-five-arm-20260928/README.md) |
@@ -1,6 +1,6 @@
 # 路线图（索引）

-> **2026-09-28**：P0 到 P7 已完成；当前阶段 **P12**（server 自己开窗口上屏）审查后主机定向测试和真机七项复测已通过，FCL 与跨机 TCP 两项验收仍待完成（跨机 TCP 被控制面 hang 阻塞，见 [五臂性能对比](notes/perf-five-arm-20260928/README.md)）。每个阶段的计划、验收结果、实测与报告在 `notes/<阶段>/`（点阶段名进入）。
+> **2026-09-28**：P0 到 P7 已完成；当前阶段 **P12**（server 自己开窗口上屏）审查后主机定向测试和真机七项复测已通过，FCL 与跨机 TCP 两项验收仍待完成（原先的跨机 hang 是主机 TUN 代理造成的，已排除，见 [五臂性能对比](notes/perf-five-arm-20260928/README.md)）。每个阶段的计划、验收结果、实测与报告在 `notes/<阶段>/`（点阶段名进入）。

 ## 目标

@@ -32,7 +32,7 @@ client（跑应用的一方）与 server（跑驱动的一方）可以在**不
 | [Ph](notes/p7/README.md) | server 能安全地接受外来连接：令牌、限额、坏数据不致崩溃 | 必需项 ✅（随 P7） |
 | [P3b / P4b](notes/p34b/README.md) | GLES 后端的深化与收尾 | 大部分 ✅，余项并行 |
 | [P7](notes/p7/README.md) | Vulkan 后端完整迁移；真机画面检查 36/36 通过 | ✅ 09-23 |
-| [**P12**](notes/p12/README.md) | **server 自己开窗口上屏，client 不需要窗口** | **进行中**：审查后主机定向测试和真机七项复测通过；FCL / 跨机 TCP 验收待完成；跨主机 hang 为阻塞项 |
+| [**P12**](notes/p12/README.md) | **server 自己开窗口上屏，client 不需要窗口** | **进行中**：审查后主机定向测试和真机七项复测通过；FCL / 跨机 TCP 验收待完成 |
 | [P8](notes/p8/README.md) | 把剩余的仿真路径挪到正确的一侧，补齐协议 | 待排 |
 | [P9](notes/p9/README.md) | 反向通道异步化（回读、写回不再同步等待） | 待排 |
 | [P10](notes/p10/README.md) | 同步对象、查询与帧节奏 | 待排 |
@@ -6,6 +6,10 @@
 > 原始数据在 `.trace-work/perf-compare/`（`summary.json` / `REPORT.md` / 逐轮目录 / `profile/` / `wifi/`）。
 > 每臂均验证 logcat 臂标志（transport marker、`spawn ARMED`、`run-ahead ARMED`），全部 0 lockstep、0 Fatal；
 > 每负载另跑一轮非 benchmark 的 ssim 门（openra 四臂 1.000000，rd12 四臂 0.999883，字节级一致）。
+> **更正（2026-09-28 晚）**：原文的「跨主机控制面 hang（源码 bug）」是**测试环境造成的**：
+> WSL 的默认路由走主机上 v2rayN 的 `xray_tun`（TUN 模式，`172.18.0.1/30`）。xray 在本地终结了 TCP、再从 `192.168.31.183` 重新发起，然后在中继时卡住。
+> 这样绕过它之后跑通：`ip route replace 192.168.21.181/32 via 192.168.31.1 dev eth0`（root，临时路由，用完已删）。
+> 见结论 4 与 Wi-Fi 两行。

 ## 结果

@@ -18,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 | — | — | — | 跨主机控制面 hang，0 有效帧（见下） |
+| tcp over Wi-Fi（WSL → 手机，绕开 xray） | 17.4 | 57.4 | — | 单次；251/251 帧、rc=0；Wi-Fi RTT 4.6–110 ms（均值 30） |

 ### openra（轻负载，128 帧；28 draws/帧、199 记录/帧）

@@ -29,6 +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 × 同步点主导 |

 ## 结论

@@ -53,17 +58,21 @@
 3. **shm/inproc 已贴近它们的实际上限：apply 线程 CPU。** 帧时 5.6ms 中 3.5ms 是真实 apply 工作；
   剩下可削的是握手开销——apply 线程 6,963 次/帧 doorbell 等待、自旋占其 CPU ~35%（1.8ms/帧），
   离跨核 cache-line ping-pong 上限（估 2–5M 记录/s，实际 1.24M waits/s）还有 2–4 倍余量；park 率仅 0.05%。
-4. **Wi-Fi 臂被两个独立问题卡住。**
-   - **跨主机控制面 hang（源码 bug，P12 验收 B 的直接阻塞项）**：WSL client → 手机 server 在
-     `eglMakeCurrent`（控制面 seq 3）100% 复现挂死。字节级证据链：client 字节已被手机内核 ACK、
-     `/proc/net/tcp` 接收队列已空，但 session child 的控制 fd `ppoll` 永远无 POLLIN（strace 现场：
-     主线程 ppoll 100ms 超时循环、io 线程 recv 阻塞、apply 线程 futex parked）。
-     同机 TCP（连本机 wlan0 IP）完全正常 → 特异于跨主机到达时序，疑为控制面帧重组/双 reader 竞态
-     （本地 loopback 时窗口太小不出现）。已排除：丢包/PMTU/冷启动预算/LOG_FORWARD/run-ahead/token。
-     复现与取证脚本：`tools/device_bench/disagg/wifi_hang_repro.sh`、`phone_strace.sh`、`fdprobe.sh`。
-   - **带宽硬约束（即使修好 hang）**：实测 Wi-Fi TCP 吞吐 19–22 MiB/s（链路 5GHz 11ax、
-     Tx 648–1441Mbps、RTT avg 0.78ms），rd12 满速需 ~49MB/s → **Wi-Fi 臂上限 ~40–45 fps**；
-     轻负载则转为 RTT × 同步点主导。要满速必须减流量（压缩/去重）或提 credit 深度摊 RTT。
+4. **Wi-Fi 臂：没有源码 hang；带宽和 RTT 才是约束。**
+
+   | 项 | 原结论 | 实为 | 证据 |
+   |---|---|---|---|
+   | 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 |
+
+   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。
+   **P6.5（09-22）与 P12（09-26）里 WSL → 手机的链路数也都经过 xray**（`xray_tun` 自 09-21 起在线）：通过 / 失败的结论不受影响，但其中的链路 RTT / 吞吐需要带这个前提来读。

 ## 优化建议（按优先级）

@@ -81,8 +90,7 @@ knob 级（零代码）：
 6. applier 的 WaitForWork 改自适应 spin（连续空转才降预算），与 #3 同向但更精细。
 7. sendmsg 跨 Flush 合批（收益上限 ~18% twait，排在后面）。
 8. appliedSeq/progress 合批参数**不动**（A/B 反证 ≤5%）。
-9. 修跨主机控制面 hang（方向：RunSession 控制泵 / ControlInbox 的读状态机与双 reader 交错；
-   证据见 `.trace-work/perf-compare/wifi/`）。
+9. ~~修跨主机控制面 hang~~：不是源码问题（见结论 4）。跨机测试前先查路由：`ip route get <手机 IP>` 必须走物理网卡，不能走 TUN。

 ## 方法与读法陷阱（复测必读）