From f01e13fd22302dc95978469a365453ef3eaafc7e Mon Sep 17 00:00:00 2001
From: Wanderingss <1624155937@qq.com>
Date: Tue, 22 Sep 2026 06:53:09 +0800
Subject: [PATCH] =?UTF-8?q?=E5=BC=95=E7=94=A8=E6=9B=B4=E6=96=B0=EF=BC=9AST?=
 =?UTF-8?q?M32=E4=BE=A7=E6=96=87=E6=A1=A3=E5=90=88=E5=B9=B6=E5=90=8E?=
 =?UTF-8?q?=EF=BC=8C=E6=A0=B9=E5=9B=A0=E5=BC=95=E7=94=A8=E6=94=B9=E6=8C=87?=
 =?UTF-8?q?=E9=93=BE=E8=B7=AF=E5=BB=B6=E8=BF=9F=E6=B5=8B=E8=AF=95=E8=AF=B4?=
 =?UTF-8?q?=E6=98=8E.md=20=C2=A77.3?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 README.md           | 2 +-
 remo_disp_server.py | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/README.md b/README.md
index 95afc99..a34a80d 100644
--- a/README.md
+++ b/README.md
@@ -169,7 +169,7 @@ AA 03 00 04 00 00 00 00 00
 
 **现象**：拉取一帧 LCDMEM（3209B）原本中位 **68.8ms**，其中约 52ms 卡在帧尾那 137B 小段上。
 
-**根因**（已在 DTU 侧台架确证，见 STM32F4-Base 仓库 `docs/测试说明/链路时延实测数据分析.md` §3.3）：
+**根因**（已在 DTU 侧台架确证，见 STM32F4-Base 仓库 `docs/测试说明/链路延迟测试说明.md` §7.3）：
 DTU 侧 CH395F 的 MSS=1024、发送 FIFO=1024B，因此每次 1024B 写恰好是**满 MSS 段**（立即发送）；
 而 3209B = 3×1024 + **137B**，最后这段是**次 MSS 段** → 芯片按 Nagle 规则扣住它，等前一数据被 ACK。
 Windows 默认**延迟确认**把该 ACK 推迟 40~200ms，整帧因此被拖住。
diff --git a/remo_disp_server.py b/remo_disp_server.py
index 5c26309..b87019b 100644
--- a/remo_disp_server.py
+++ b/remo_disp_server.py
@@ -206,7 +206,7 @@ def _send(cmd: int, data: bytes = b"") -> bool:
 # 延迟确认（Delayed ACK）抑制：LCDMEM 整帧被拖慢 40~200ms 的根因与解法
 # =============================================================================
 # 机理（2026-09-22 台架实测确证，见 STM32F4-Base 仓库
-#   docs/测试说明/链路时延实测数据分析.md §3.3）：
+#   docs/测试说明/链路延迟测试说明.md §7.3）：
 #   CH395F 的 MSS=1024、发送 FIFO=1024B，因此 MCU 每次 1024B 写恰好是一个
 #   “满 MSS 段”（Nagle 允许立即发送）；而 LCDMEM 应答 3209B = 3×1024 + 137B，
 #   最后 137B 是“次 MSS 段” → 芯片按 Nagle 规则把它扣住，等前一数据被 ACK。