From 82de3f68268ebc64259f25880b85b0008ab9021e Mon Sep 17 00:00:00 2001 From: BZLZHH Date: Sat, 26 Sep 2026 02:44:30 +0800 Subject: [PATCH] [Docs] (P12): the ring-1024 experiment - every deferred answer comes back (readfail 8,872 -> 0), so eviction was the whole cause and the residency budget is now the brake One-line experiment before writing the retention table: StreamLink's kReplyRing 8 -> 1024, nothing else changed, same load frame on the same device. ring = 8 (today) ring = 1024 readfail 8,872 0 taken 63 4,499 / 4,500 blocked (fell back) 4,435 0 by_op 2 9,071 3,443 wall 27.9 s 23.04 s frame-sent create 4,536, records 103,097 identical per op TWO CONCLUSIONS. First, eviction was the ONLY cause: with a buffer deep enough, every deferred answer was read back and not one create fell through to the blocking path. The wedge (want=310) and the useless budget (budget=4,451) were two faces of "eight slots is not enough". Second, what brakes now is the BUDGET, not the buffer: by_op 2 = 3,443 matches the number of times the budget forced an early read (3,395), i.e. every one of those is a real blocking wait. Its constant is 7, sized for the 8-slot pool, so against a 1,024-deep buffer it became the only throttle and the wall only moved 27.9 -> 23.0 s. WHAT IT MEANS FOR THE DESIGN. Once the answers are RETAINED until read, correctness no longer depends on how long one survives in a bounded buffer, so the budget must be sized to the RETENTION CAPACITY rather than to the pool - or be replaced by "retained means safe". by_op 2 = records/W then puts W=2 at ~2,268 waits and the wall at ~15 s, which is the goal's own success criterion. Experiment reverted (ring back to 8, probes deleted); 172 + 13 + 22 + 103 green. --- .../notes/p12/CREATE-WINDOW-MEASURED.md | 29 ++++++++++++++++++- 1 file changed, 28 insertions(+), 1 deletion(-) diff --git a/docs/Disaggregated/notes/p12/CREATE-WINDOW-MEASURED.md b/docs/Disaggregated/notes/p12/CREATE-WINDOW-MEASURED.md index 2228131d..59c88b8a 100644 --- a/docs/Disaggregated/notes/p12/CREATE-WINDOW-MEASURED.md +++ b/docs/Disaggregated/notes/p12/CREATE-WINDOW-MEASURED.md @@ -226,7 +226,34 @@ if (x.replySeq != seq) return ... MOBILEGL_ERR_PROTOCOL_MISMATCH; // 等的是 **两步都留在树里**：第 1 步是净收益；第 2 步是安全方向（只会让窗口退化成不延后＝pre-window 形状）， 而且它用的时钟 `ReplyPostings()` 正是保留方案要用的。 -## 10. 复算 +## 10. 第 0 步实验：把 `StreamLink` 的环从 8 放到 1024 —— 诊断确认 + +§9 的结论是「延后要成立必须保留」。在写保留表之前先做了一个**一行实验**把这句话证死：把 +`StreamLink::kReplyRing` 从 8 改成 1024（其余一切不动），同一个负载帧： + +| | 环 = 8（现状） | 环 = 1024（实验） | +|---|---|---| +| `readfail` | 8,872 | **0** | +| `taken` | 63 | **4,499 / 4,500** | +| `blocked`（回退阻塞路径） | 4,435 | **0** | +| `by_op 2` | 9,071 | **3,443** | +| 墙钟 | 27.9 s | **23.04 s** | +| `frame-sent` | create 4,536 / records 103,097 | 逐 op 相同 | + +**结论一：唯一的原因就是淘汰。** 环够深，延后的答案**每一个**都读回来了（4,499/4,500），一次都没有回退到 +阻塞路径。§8 那个 `want=310` 的楔子、§9 那个 `budget=4451` 的无效预算，都是「8 个位置不够」这一个事实的两种表现。 + +**结论二：现在刹车的是预算，不是缓冲。** `by_op 2 = 3,443` 恰好等于 `budget` 触发次数（3,395 量级）—— +也就是**每一条被预算强制提前取回的答案，都是一次真实的阻塞等待**。预算的常数是 7（按 8 槽池定的）， +而实验里缓冲有 1024 深，于是预算变成了唯一的节流阀，墙钟只从 27.9 s 降到 23.0 s。 + +**这对设计意味着什么**：保留表落地之后，正确性不再依赖「答案在缓冲里活多久」——**答案被持有到被读走为止**。 +于是预算不该再按 8 槽池定，而应当按**保留容量**定（或者干脆由「保留即安全」取代）。 +按 `by_op 2 ≈ records / W` 推算，W=2 时应是 ~2,268 次等待、墙钟 ~15 s——**正是 goal 里那条 15-16 s 的判据**。 + +实验状态已还原（环回到 8、探针全部删除），四个车道 172+13+22+103 全绿。 + +## 11. 复算 ~~~sh # 两臂的帧读数（handoff-2 §1 的读法）