延迟瓶颈实测为本机 CPU 而非机房位置，跨站对比主指标改为 compute_ms

用户指出本机选新加坡是因为 Bitget 机房在新加坡。查证下来 ws.bitget.com 解析
到的是 CloudFront（dxotqhr62n6z4.cloudfront.net），落在新加坡 AS16509
（Amazon），即连的是 AWS 的 CDN 边缘而非 Bitget 自有机房。

腾讯云 ap-singapore（AS132203）到该边缘实测：ICMP 往返 2.1ms、TCP 握手
3.3ms、TLS 完成 9.0ms、首字节 87.8ms。首字节减 TLS 那约 79ms 是 CloudFront
回源开销，与我们的位置无关。

延迟构成（33 根样本）：数据到达中位 506ms、信号计算中位 646ms、合计 1315ms。
随机房位置变化的只有那 2ms 往返，占总延迟 0.15%。而 646ms 的信号计算是每根
在 2000 根 1m 加 800 根 5m 上重建缠论结构，本机 2 核、2 个计算进程，三币同时
收盘时第三个还要排队——这才是有改善空间的一项。

因此：
- 新增 deploy/netprobe.sh，把网络那一段单独量出来并入运行元数据。用到达
  延迟去比两个机房等于用公斤秤称克，必须把可变的那段拿出来单独看。
- compare_sites.py 主指标改为 compute_ms，lag_data_ms 降为自检项（两站应当
  接近；若差很多，先怀疑时钟而非网络）。元数据表加 nproc/cpu_model/往返。
- README 改写：第二台机器该测 CPU 规格而非地理位置，WORKERS 按核数减一给，
  币数多于 worker 数时排队时间直接计入 compute_ms。

另修正站点标签：本机是腾讯云而非 Hetzner，sg-hetzner → sg-tencent，标错的
33 行数据已清掉重采。

Co-authored-by: Cursor <cursoragent@cursor.com>

research/live/deploy/README.md

@@ -2,13 +2,34 @@
 
 在第二台机器上跑一套完全相同的采集，用来看不同地理位置的数据差异。
 
-## 为什么要跨地采集
+## 先看这一节：延迟的瓶颈不在机房
 
-滑点里最大的一项是**延迟漂移**：从 K 线收盘到实际下单之间，价格已经走掉的
-那部分。而延迟 = 交易所出包 + 网络传输 + 本地处理。本机（新加坡）实测到达
-延迟中位 350~650ms，其中网络传输占多少、换个机房能压掉多少，只有实测。
+滑点里最大的一项是**延迟漂移**，所以延迟越低越好。但延迟拆开之后，可优化的
+地方和直觉不一样。腾讯云新加坡实测（2026-08-28）：
 
-延迟压下来直接等于滑点下降，所以机房选址是个可优化参数，不是固定成本。
+| 构成 | 中位 | 随机房位置变化吗 |
+| --- | --- | --- |
+| 数据到达（交易所推送 + 回源 + 网络） | 506ms | 只有网络那段，**2ms** |
+| 信号计算（本机 CPU） | **646ms** | 不变，取决于 CPU |
+| 合计到可下单 | 1315ms | |
+
+`ws.bitget.com` 解析出来是 **CloudFront**（`dxotqhr62n6z4.cloudfront.net`），
+落在新加坡的 AS16509（Amazon）。所以我们连的是 AWS 的 CDN 边缘，不是 Bitget
+自己的机房。从腾讯云新加坡到这个边缘：
+
+    ICMP 往返      2.1ms
+    TCP 握手       3.3ms
+    TLS 完成       9.0ms
+    首字节        87.8ms   ← 减去 TLS 的 9ms，约 79ms 是 CloudFront 回源开销
+
+回源那 79ms 和交易所自己的推送节奏，不管我们坐在哪都一样。而随位置变化的
+只有那 2ms 往返。**换机房的全部空间是 1~2ms，占总延迟 1315ms 的 0.1%。**
+
+真正的大头是本机 646ms 的信号计算：每根 K 线要在 2000 根 1m 加 800 根 5m 上
+重建缠论结构，三个币同时收盘而本机只有 2 核、2 个计算进程，第三个币还要排队。
+
+**所以第二台机器该测的是 CPU 规格，不是地理位置。** 看 `compute_ms`，不是
+`lag_data_ms`。3 个币至少要 3 个 worker，`--workers` 给到核数减一。
 
 ## 三个必须一致，一个必须不同
 
@@ -41,9 +62,14 @@ git clone ssh://jack@git.jackyu66.com:2222/jack/chan.git
 cd chan && git checkout chan
 
 bash research/live/deploy/setup.sh          # 装 docker + chrony，拉镜像
-SHADOW_SITE=aws-tokyo bash research/live/deploy/start.sh
+
+# 站点名带上机型，因为要比的是 CPU 而不是位置
+SHADOW_SITE=aws-sg-c7a4x WORKERS=3 bash research/live/deploy/start.sh
 ```
 
+`WORKERS` 按核数减一给。3 个币同时收盘，worker 少于 3 就会排队，而排队时间
+直接计入 `compute_ms`。本机 2 核只能给 2，这本身就是 646ms 里的一部分。
+
 确认健康：
 
 ```bash
@@ -88,6 +114,9 @@ python research/live/compare_sites.py \
 市场性质，与机器位置无关。若漂移也差很多，先怀疑时钟或时段没对齐，而不是
 急着下结论。
 
+同理，`lag_data_ms` 两站也应当几乎相同（网络那段只有 2ms 空间）。真正该出现
+差异的是 `compute_ms`。如果 `lag_data_ms` 差很多，先查时钟——比查网络更可能。
+
 ## 资源占用
 
 本机实测：内存约 1.5GB（两个计算进程 + 盘口缓冲），CPU 单核不满。