jackandCursor
95f2b614a2
延迟瓶颈实测为本机 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>
2026-08-28 02:51:51 +08:00
..
2026-08-28 02:51:51 +08:00
2026-08-27 23:51:57 +08:00
2026-08-27 23:51:57 +08:00
2026-08-27 23:51:57 +08:00
2026-08-28 02:51:51 +08:00
2026-08-27 23:51:57 +08:00
2026-08-27 23:51:57 +08:00
2026-08-28 02:39:47 +08:00
2026-08-27 23:51:57 +08:00
2026-08-27 23:51:57 +08:00
2026-08-28 02:39:47 +08:00
2026-08-28 02:39:47 +08:00
2026-08-28 02:39:47 +08:00
2026-08-27 23:51:57 +08:00
2026-08-27 23:51:57 +08:00
2026-08-27 23:51:57 +08:00
2026-08-28 02:39:47 +08:00
2026-08-28 02:39:47 +08:00
2026-08-28 02:39:47 +08:00
2026-08-28 02:39:47 +08:00
2026-08-27 23:51:57 +08:00
2026-08-27 23:51:57 +08:00
2026-08-27 23:51:57 +08:00
2026-08-28 02:39:47 +08:00