From c9d00147df07f670250394d4104b0743971df311 Mon Sep 17 00:00:00 2001 From: hoelee Date: Fri, 30 Oct 2026 06:09:48 +0800 Subject: [PATCH] post(504): link the public artifact repo and v1.3 report; note cross-session drift --- .../posts/read-amplification-504-gateway-timeout-swr-cache.md | 4 ++-- .../zh/read-amplification-504-gateway-timeout-swr-cache.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/content/posts/read-amplification-504-gateway-timeout-swr-cache.md b/src/content/posts/read-amplification-504-gateway-timeout-swr-cache.md index ed70dd5..61b66a0 100644 --- a/src/content/posts/read-amplification-504-gateway-timeout-swr-cache.md +++ b/src/content/posts/read-amplification-504-gateway-timeout-swr-cache.md @@ -251,10 +251,10 @@ Three findings generalise beyond this endpoint: Four honest caveats, because a benchmark without them is marketing: - **The hardware is one laptop.** Windows 11, local NVMe, single process. The experiment quantifies the *relative* cost of read amplification; it does not reproduce NAS latency. -- **The machine jitters by ±20%.** The same implementation varies that much across three independent full runs. I therefore quote medians and ranges, never a single value to one decimal place — that precision does not exist in this environment. +- **The machine jitters by ±20%.** The same implementation varies that much across three independent full runs — and 19–27% between sessions, which is why the report labels every table with the session it came from. I therefore quote medians and ranges, never a single value to one decimal place — that precision does not exist in this environment. - **The latency table is a projection, not a measurement.** It bills each `read_text()` at a fixed cost L and keeps measured CPU time constant. It does **not** bill `stat()`, which on SMB/NFS is also a round trip, and the incremental path's main cost is roughly 480 of them. At 5 ms per `stat`, incremental refresh is closer to 2.4 s than to 37 ms. That is still off the request path, so the 504 conclusion holds — but "tens of milliseconds" would be an overstatement. - **The corpus is synthetic.** 240 generated notes plus 120 translations, with a known ready/outdated/pending split. Real content has longer bodies and messier front matter, which shifts the absolute numbers and not the shape. The harness generates its own corpus and prints strictly valid JSON, so `python swr_bench.py` reproduces the whole table on any machine within roughly ±30% hardware variance. Every figure in this post is a number some script produced during the run it describes — including the four that made the original version of this post look better than it was, before they were deleted and the experiment was redone. -*The full whitepaper — including the multi-worker state-sharing options, the complete harness, and the three raw result sets — is published separately: [Moving a 504 out of the system (technical whitepaper v1.2)](https://doc.hoelee.com/whitepaper-504-read-amplification-swr.html).* +*The full whitepaper — including the multi-worker state-sharing options, the complete harness, and the three raw result sets — is published separately: [Moving a 504 out of the system (technical whitepaper v1.3)](https://doc.hoelee.com/whitepaper-504-read-amplification-swr-en.html). The harness and the raw runs are public, with every limitation the report admits: [github.com/hoelee/swr-read-amplification-bench](https://github.com/hoelee/swr-read-amplification-bench).* diff --git a/src/content/posts/zh/read-amplification-504-gateway-timeout-swr-cache.md b/src/content/posts/zh/read-amplification-504-gateway-timeout-swr-cache.md index e595714..4b94484 100644 --- a/src/content/posts/zh/read-amplification-504-gateway-timeout-swr-cache.md +++ b/src/content/posts/zh/read-amplification-504-gateway-timeout-swr-cache.md @@ -251,10 +251,10 @@ def _scan(content_dir, locale): 四条必须承认的限定，因为没有限定的基准就是宣传： - **硬件只有一台笔记本。** Windows 11、本地 NVMe、单进程。实验量化的是读取放大的*相对*代价，它没有复刻 NAS 的绝对时延。 -- **机器抖动本身就有 ±20%。** 同一实现在三次独立全跑之间就有这么大差异。所以文中只引用中位数与区间，绝不给出精确到小数点后一位的单一数值——那种精度在这个环境里不存在。 +- **机器抖动本身就有 ±20%。** 同一实现在三次独立全跑之间就有这么大差异，跨会话之间更到 19–27%——所以报告里每张表都标着它来自哪一次会话。所以文中只引用中位数与区间，绝不给出精确到小数点后一位的单一数值——那种精度在这个环境里不存在。 - **延迟表是投影，不是实测。** 它按固定代价 L 给每次 `read_text()` 计费，其余沿用实测 CPU 时间。它**没有**给 `stat()` 计费，而 SMB/NFS 上每次 `stat` 也是一次往返，增量路径的主要成本恰恰是约 480 次 `stat`。按每次 `stat` 5 ms 计，增量刷新更接近 2.4 秒而不是 37 毫秒。它仍在请求路径之外，所以 504 的结论成立——但把它说成「几十毫秒」就是夸大。 - **语料是程序化生成的。** 240 篇生成笔记 + 120 篇译文，ready/outdated/pending 分布已知。真实内容正文更长、front matter 更杂乱，会改变绝对数字，不改变曲线形状。 基准脚本自带语料生成、stdout 为严格合法 JSON，因此在任何机器上执行 `python swr_bench.py` 都能在约 ±30% 硬件差异内复算整张表。本文每个数字都是某次运行里某个脚本产出的——包括那四个让这篇文章的初版看起来比实际更好的数字，它们在实验重做之后被删掉了。 -*完整白皮书——含多 worker 状态共享的各档方案、完整实验脚本与三份原始读数——已单独发布：[《把一个 504 从系统里移出去》（技术白皮书 v1.2）](https://doc.hoelee.com/whitepaper-504-read-amplification-swr.html)。* +*完整白皮书——含多 worker 状态共享的各档方案、完整实验脚本与三份原始读数——已单独发布：[《把一个 504 从系统里移出去》（技术白皮书 v1.3）](https://doc.hoelee.com/whitepaper-504-read-amplification-swr.html)。执行脚本与原始读数已公开，连同报告承认的全部局限：[github.com/hoelee/swr-read-amplification-bench](https://github.com/hoelee/swr-read-amplification-bench)。*