From 5ad8370b3775aa63c6a408532da1c1b943582062 Mon Sep 17 00:00:00 2001
From: BZLZHH <admin@bzlzhh.top>
Date: Fri, 25 Sep 2026 22:36:51 +0800
Subject: [PATCH] [Docs] (P12): the first-use confirmation measured on the
 device - 43,232 waits to 25,176, 221.5 s to 134.4 s, op 47 gone and every
 other row identical

---
 .../notes/p12/DEVICELOST-AND-UPLOAD-WAITS.md  | 25 +++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/docs/Disaggregated/notes/p12/DEVICELOST-AND-UPLOAD-WAITS.md b/docs/Disaggregated/notes/p12/DEVICELOST-AND-UPLOAD-WAITS.md
index a7674a9f..50d86bda 100644
--- a/docs/Disaggregated/notes/p12/DEVICELOST-AND-UPLOAD-WAITS.md
+++ b/docs/Disaggregated/notes/p12/DEVICELOST-AND-UPLOAD-WAITS.md
@@ -194,6 +194,31 @@ params probe: first=1 same-again=1 changed=2 (deltas 1/0)
 所以设备上那 18,056 条 `SetTextureParams` 是**真实的状态变化**，不是重复；`ResourceRespecify`/`ResourceCreate` 同理（respecify 的 `unchanged` memcmp 去重早就在了，`TextureEmit.h:838/858/865`）。
 **结论：客户端侧没有"少发记录"的空间**——剩下的唯一杠杆是「同样多的记录，更少的往返」，也就是把等待批起来（同一条 row 每 K 条等一次）或把单次往返的成本降下来（数据面 stream 的 syscall/wake 路径），
 不是继续找冗余。顺带确认：`TCP_NODELAY` 已经在 `SocketTransport.cpp:100` 设了，5 ms 不是 Nagle 造成的。
+### 2.11 首次使用确认落地后的真机 A/B：那一帧 221.5 s → 134.4 s
+
+按「确认推迟到该对象首次被使用」实现（提交 `b6270960`）：发射端在发送参数前查发布闩，未发布就先补一次**阻塞的** create
+（`HealUnpublishedRecord`，即把原来"被拒后才跑"的那段抽出来前移）；对象一旦确认，参数记录全部 fire-and-forget，
+调用方读到的是 accept-by-construction（与 B 的 `resource_subdata` 同形）。wire 端读**同一个闩**决定要不要开回复槽，
+所以两半不会对"是否欠一次等待"给出不同答案。
+
+同一台设备（GSI，出厂省电策略、服务端 spin 默认 50 µs、Wi-Fi LAN），同一份工作量：
+
+| | 那一帧 waits | `by_op` | staged | 墙钟 |
+|---|---|---|---|---|
+| 改动前（frame 12） | **43,232** | `2=4536, 3=20633, 5=6, 9=1, `**`47=18056`** | 101,421,396 B | 221.5 s |
+| 改动后（frame 25） | **25,176** | `2=4536, 3=20633, 5=6, 9=1` | 101,421,396 B | **134.4 s（−39%）** |
+
+**`47`（`SetTextureParams`）整条从等待里消失，其余每一行一个不差**，staged 字节也完全相同——所以这 87 秒是"少买了 18,056 次往返"，
+不是别的什么变了；帧内 `rtt_mean` 5,040 → 5,176 µs（单次成本没动），正是"次数变了、单价没变"的形状。
+
+**为什么不需要周期性金丝雀**：确实"服务端是否持有这个 handle"客户端本来就知道——`MGPipeHandleIsPublished` 在 create **被接受**时才置位，
+而 applier 跨 make-current 保留纹理记录（`PipeFill.cpp:3756-3759`，这条注释直接否掉了"在 applier_reset 清闩"的做法：那会让每次 make-current 都无谓重发）。
+所以确认只在**首次使用**付一次（那一次 create 本来就要发），之后每条记录都不必再问。兜底仍是老路径：
+create 被拒 → 闩不置位 → 下一条参数记录照样阻塞取真答案 → 原来那段 one-retry 自愈照跑。
+
+**下一个 20,633**：`ResourceRespecify` 仍逐条等（在 frame 25 里占 20,633/25,176 = 82%）。它与 params 同形（答案只用于 `NoteRespecified` 与自愈），
+"对象已确认"这个前提同样成立——按同一条规则处理，估算落在 **~4.5k waits ≈ 24 s** 量级（create 那 4,536 是确认本身，应当保留）。
+
 ## 3. 剩余（下一轮的直接入口）
 
 1. **把记录数压下来（新的头号项）**。§2.5 的真机数字说：那一帧剩下的 43,232 次等待全在「必须等」的三条 row 上，