 jackandCursor
|
ef2a85dd8c
|
币池可配，实测十币的排队代价；标出漂移的 tick 地板
加 --syms（start.sh 传 SYMS），默认仍是三币。TRX 不进十币池：实盘口径 208 天
只有 5 笔，ATR 门控几乎全刷掉。
十币实测（对比三币）：
queue_ms 2 → 169ms（P90 519ms，每刻最大排队中位 533ms）
inner_ms 144 → 196ms（CPU 争抢也拖慢了纯计算）
lag_signal_ms 621 → 958ms；同一收盘时刻最后算完的币中位 1376ms
排队从可忽略变成主项，与「10 币 × 196ms ÷ 2 核 ≈ 640ms 突发」吻合。这也是
之前「加核没用」那个结论唯一会翻转的场景：CPU 占用率只有约 3%，问题纯粹是
所有币同一秒收盘的突发，加核压的是并行度而非单币耗时。
但 800ms 哨兵不受影响——它喂的是 t_data − kline_ts（数据腿），十币下逐币
154~532ms 全在线内。加币不碰那道闸。
另外发现一个会被静默误读的东西：ADA/AVAX/DOGE/LINK/LTC 的漂移中位精确等于
半个 tick 且在四个延迟点上完全相同。那不是漂移，是中价的最小变动量——ADA 半
tick 就有 2.34bp。拿这个数去比预算会误判某币不可做。shadow_report 加了
tick_floor() 标注；方向上安全（真实漂移只会更小，这些是上界）。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-08-28 04:50:09 +08:00 |
|
|
jackandCursor
|
6c843639d5
|
影子路径开 lean 模式，实测完整链路 1410 → 683ms
拉到新引擎后在服务器侧直接实测，没有沿用 3.4 倍那个换算——那是在旧代码上量的。
先做等价性验证。不能直接引用 step46 的对拍结论：它固化的是 bsp_list 那条链的
哈希，而影子路径走 find_fast_bsp3 + build_htf_zones + htf_fx_timeline +
attach_htf_context，两条链读的东西不一样。所以新建 verify_lean_parity.py 在
这条路径上逐根对拍 compute() 的每个返回字段。
其中一个坑：随机取窗口测不到信号分支。信号密度约 1/2000 根，头 12 个窗口命中
0 个，「一致」只覆盖了早退路径。改成一半窗口对齐到已知信号根，命中率才上来。
最终 180 窗口 / 两模式各 90 命中 / 零分歧。
生产实测（inner_ms，容器内同口径）：
compute_ms 646 → 132ms 4.89x
inner_ms 612 → 128ms 4.80x
lag_signal_ms 1410 → 683ms 完整链路，落回 800ms 线内
比 3.4 倍更好，因为是引擎 ~3.5x 叠 lean ~1.35x。
两点判读上的订正：
- lag_data_ms 那 576→490ms 是噪声，不要记在引擎账上。均值 721±36 vs
740±127，重叠；而且引擎本来就影响不到交易所与网络那一段。
- 仍有 44% 的根超 800ms，但尾部现在完全由数据腿主导（lag_data P90 1482ms
vs compute P90 237ms）。计算既不是瓶颈也不是尾部主因了，继续压计算换不到
尾部改善。800ms 那道闸取的是最近 30 根的中位数，683ms 已满足。
start.sh 加 SHADOW_LEAN（默认 1），设 0 可退回 full 复量两模式差异。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-08-28 04:24:08 +08:00 |
|
|
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 |
|
|
jackandCursor
|
631d97e493
|
加跨地部署脚本与站点对比，数据全表加 site 列
目的是在第二台机器（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>
|
2026-08-28 02:39:47 +08:00 |
|