jackandCursor
631d97e493
目的是在第二台机器（AWS）上跑一套完全相同的采集，看不同地理位置的数据差异。 滑点里最大的一项是延迟漂移，而延迟含网络传输，所以机房选址是可优化参数。 数据侧两处必需改动： - 全部输出加 site 列（三张 CSV 加 gzip 里的盘口与成交流）。没有这一列，两台 机器的数据合起来就分不清来源。为免四处 writerow 漏加一处产生静默空值， 改在 _SiteWriter 里统一注入。 - start.sh 在时钟未同步或偏移超 10ms 时**拒绝启动**。所有延迟数字都是 「本地时钟 − 交易所 K 线收盘」，时钟偏 50ms 就全部同向偏 50ms，且不报错， 只会让跨地对比得出一个干净且完全错误的结论。 deploy/ 下四个文件：setup.sh（docker + chrony + 拉镜像）、start.sh（校验时钟、 写运行元数据、起容器）、status.sh（健康速查）、README。运行元数据记 git commit、 镜像摘要、时钟偏移——两地数据对不上时，这三项任一不同都足以解释差异。 compare_sites.py 做配对对比：只取各站都有的 K 线（不取交集可能在比不同时段， 而延迟对市场活跃度敏感），并报配对差的符号占比而非两个中位数相减。已用注入 120ms 的合成数据验证能精确还原。另有一条自检：同一固定延迟点上两站漂移应当 相同——漂移是市场性质，若也差很多则先查时钟与时段对齐。 status.sh 里按列名取字段下标而非写死数字：加 site 列时字段整体右移过一次， 写死 $8 会静默变成读 lag_signal_ms 而非 lag_data_ms。 Co-authored-by: Cursor <cursoragent@cursor.com>
影子采集器部署
在第二台机器上跑一套完全相同的采集，用来看不同地理位置的数据差异。
为什么要跨地采集
滑点里最大的一项是延迟漂移：从 K 线收盘到实际下单之间，价格已经走掉的 那部分。而延迟 = 交易所出包 + 网络传输 + 本地处理。本机（新加坡）实测到达 延迟中位 350~650ms，其中网络传输占多少、换个机房能压掉多少，只有实测。
延迟压下来直接等于滑点下降，所以机房选址是个可优化参数，不是固定成本。
三个必须一致，一个必须不同
必须一致，否则差异分不清是地理位置还是环境造成的：
- 代码版本（
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，拉镜像
SHADOW_SITE=aws-tokyo bash research/live/deploy/start.sh
确认健康：
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 慢的根占多少」比「两个中位数差多少」更能说明有无系统性差异。
判读上有一条自检：同一个固定延迟点上，两站的漂移应当几乎相同——漂移是 市场性质，与机器位置无关。若漂移也差很多，先怀疑时钟或时段没对齐，而不是 急着下结论。
资源占用
本机实测：内存约 1.5GB（两个计算进程 + 盘口缓冲），CPU 单核不满。 盘口与成交流落盘约 15MB/天（gzip）。一周 168 小时的量级在百 MB 内。
--workers 2 是因为信号计算走独立进程池、不能阻塞事件循环。核数少的机型
可以给 1，但要看心跳里的 compute_ms：若接近 60 秒就会开始堆积。