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>
98 lines
3.7 KiB
Markdown
98 lines
3.7 KiB
Markdown
# 影子采集器部署
|
||
|
||
在第二台机器上跑一套完全相同的采集，用来看不同地理位置的数据差异。
|
||
|
||
## 为什么要跨地采集
|
||
|
||
滑点里最大的一项是**延迟漂移**：从 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` 在时钟未同步或偏移超阈值时直接
|
||
拒绝启动，而不是打个警告了事。
|
||
|
||
## 步骤
|
||
|
||
在新机器上：
|
||
|
||
```bash
|
||
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
|
||
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/` 收到一处（同名文件会覆盖，所以分目录放）：
|
||
|
||
```bash
|
||
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 秒就会开始堆积。
|