jack/Chan

Files

T

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

5.2 KiB

Raw Blame History

影子采集器部署

在第二台机器上跑一套完全相同的采集，用来看不同地理位置的数据差异。

先看这一节：延迟的瓶颈不在机房

滑点里最大的一项是延迟漂移，所以延迟越低越好。但延迟拆开之后，可优化的地方和直觉不一样。腾讯云新加坡实测（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 给到核数减一。

三个必须一致，一个必须不同

必须一致，否则差异分不清是地理位置还是环境造成的：

代码版本（git_commit）——同一个 commit
镜像摘要（image_digest）——同一个 hummingbot 镜像
时钟——两台都同步到 NTP，偏移都在 10ms 内

必须不同：

SHADOW_SITE——写进每一行数据，是合并后区分来源的唯一依据

start.sh 会把这四项连同内核、核数、内存一起写进 research/out/run_meta_<site>.json。两地数据对不上时先看这个文件。

时钟为什么是硬门槛

所有延迟数字都是「本地时钟 − 交易所 K 线收盘时间戳」。时钟偏 50ms，全部延迟就同向偏 50ms，而且不会有任何报错——只会让跨地对比得出一个干净、自信、且完全错误的结论。所以 start.sh 在时钟未同步或偏移超阈值时直接拒绝启动，而不是打个警告了事。

步骤

在新机器上：

git clone ssh://jack@git.jackyu66.com:2222/jack/chan.git
cd chan && git checkout chan

bash research/live/deploy/setup.sh          # 装 docker + chrony，拉镜像

# 站点名带上机型，因为要比的是 CPU 而不是位置
SHADOW_SITE=aws-sg-c7a4x WORKERS=3 bash research/live/deploy/start.sh

WORKERS 按核数减一给。3 个币同时收盘，worker 少于 3 就会排队，而排队时间直接计入 compute_ms。本机 2 核只能给 2，这本身就是 646ms 里的一部分。

确认健康：

bash research/live/deploy/status.sh

启动日志里应当看到：

[补丁] 覆盖生效：基类取首元素 … 本地取末元素 …
成交流已挂 ['BTC', 'ETH', 'SOL']
就绪 3.0s · 1m [2001, 2001, 2001] 根 · 5m [801, 801, 801] 根

第一行尤其重要。上游 Bitget 连接器的换根解析有 bug（只取多根消息的首元素），补丁把它修掉拿回约 1.06 秒。补丁若失效是静默的——不崩不报错，只是延迟悄悄退回 1.4 秒，所以启动时做了断言。

对比

把两站的 research/out/ 收到一处（同名文件会覆盖，所以分目录放）：

mkdir -p collected/sg collected/aws
rsync -av sg-box:chan/research/out/   collected/sg/
rsync -av aws-box:chan/research/out/  collected/aws/

python research/live/compare_sites.py \
  --glob 'collected/*/shadow_latency.csv' \
  --drift-glob 'collected/*/shadow_drift.csv' \
  --meta-dir collected/sg --meta-dir collected/aws

对比脚本做两件事值得说明：

只取各站都有的 K 线做配对比较。不取交集就可能在比不同时段，而延迟对市场活跃度敏感。
报配对差的符号占比而不只是两个中位数相减。同根配对消掉了市场状态，「A 比 B 慢的根占多少」比「两个中位数差多少」更能说明有无系统性差异。

判读上有一条自检：同一个固定延迟点上，两站的漂移应当几乎相同——漂移是市场性质，与机器位置无关。若漂移也差很多，先怀疑时钟或时段没对齐，而不是急着下结论。

同理，lag_data_ms 两站也应当几乎相同（网络那段只有 2ms 空间）。真正该出现差异的是 compute_ms。如果 lag_data_ms 差很多，先查时钟——比查网络更可能。

资源占用

本机实测：内存约 1.5GB（两个计算进程 + 盘口缓冲），CPU 单核不满。盘口与成交流落盘约 15MB/天（gzip）。一周 168 小时的量级在百 MB 内。

--workers 2 是因为信号计算走独立进程池、不能阻塞事件循环。核数少的机型可以给 1，但要看心跳里的 compute_ms：若接近 60 秒就会开始堆积。

5.2 KiB Raw Blame History Unescape Escape