 jackandCursor
|
54792fe015
|
把 compute_ms 拆成排队与纯计算，据此否掉换机器这个方向
compute_ms 一直是「提交进程池到拿到结果」的墙钟时间，排队和纯计算混在一个
数里，所以「加核有没有用」只能靠猜——这也是原先打算在 AWS 开第二台比 CPU
的依据。
worker 内部自己计时，连同父进程传入的提交时刻一起回传，拆出 queue_ms 与
inner_ms。实测中位 3ms / 695ms：2 个 worker 跑 3 个币并不排队，因为三个币的
收盘消息错峰到达。瓶颈全在单线程，加核压不到。
顺带把 README 里的内存数据从臆测的 1.5GB 改成实测 410MiB，并注明跨站点比
CPU 收益有限。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-08-28 03:02:06 +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 |
|
|
jackandCursor
|
01c4a4ab4d
|
主口径仓位定为 10 万 USDT，并量出限价单前方的排队量
用户 2026-08-28 确认资金规模不会更大，故仓位档改为 25k/50k/100k/200k
（上下留档是为了读出局部斜率，单点看不出再大一倍会怎样）。该规模下两条
约束都不绑定：冲击占预算 0.1~11.1%，成交量效应使预算降幅不足 1%。
新增 queue_ahead：排队是唯一还没建模的成本项，exit_fill 假定我们能吃到该
价位的全部对手方成交量。10 万仓位相对最优档为 BTC 0.2 倍、ETH 0.7 倍、
SOL 69.7 倍。SOL 畸高是 tick 更细所致（同样的量摊到约 10 倍价位上），
对它应看 5bp 档（0.17 倍），但仍是三币中排队压力最大者。
同时在 shadow_depth 模块头标注：composite_fill 只算首次触及那一根的可成交
量，系统性偏悲观，不作为成交率结论——真实成交率见 lib/exit_fill.py。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-08-28 02:39:47 +08:00 |
|
|
jackandCursor
|
181bca303f
|
影子测量改用框架吃单原语，并补齐容量与 maker 成交率两项测算
吃单查询换成 Hummingbot 的 OrderBook.get_vwap_for_volume：手写的 walk_book
返回的是按计价币吃单的加权均价，但框架的 get_price_for_quote_volume 返回
边际价、get_vwap_for_volume 收基础币量，两者语义不同。改为按基础币下单
（真实委托与 PositionExecutor.amount 均是基础币计价），深度不足由
query_volume/result_volume 判定，框架此时返回 nan 而非一个看似正常的
部分成交均价。
落盘完整盘口（双边 50 档）。此前只记三个固定名义额的成交价，这批数据的
寿命就等于那几个档位的寿命；存完整深度后任意资金量级的冲击都能离线重算。
仓位档同时从 1k/5k/20k 提到十万量级，此前低估真实仓位约两个数量级。
订阅成交流，按根按价位聚合。买卖分开存——多头在目标位挂卖出靠主动买盘
成交，混在一起会把成交率高估约一倍。BTC 每根总成交额中位与 210 天历史
的 volume×close 差 0.3%，可确认采集完整。
新增两项测算：
- 冲击不是绑定约束。32 万仓位单边冲击 0.19~2.39bp，对 8.58~20.64bp 的
预算只占 1.6~14.2%，冲击反推的资金上限 100~500 万。
- maker 成交率才是。止盈位被首次触及时，限价在该根价格区间中的位置
中位 k=0.28（63.9 万次触及，三币一致）；合并每根成交额后，32 万仓位
的全额成交率仅 30.1%/15.6%/1.5%。要 80% 全额成交，仓位须 ≤ 4.7 万
/1.4 万/0.26 万——比冲击反推的上限低 40~370 倍。
回测把这些止盈按「全额成交在目标价」计，故预算所依据的收益流本身需重估。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-08-28 02:39:47 +08:00 |
|
|
UbuntuandCursor
|
7e339d2a54
|
research: 影子交易器落在 Hummingbot 上，并修掉 Bitget 连接器的换根延迟
1m 腿的滑点余量只有几个 bp，所以要测的必须是生产路径的滑点——换个运行时
测出来的数就不作数。框架因此从「滑点已知后再定」提前到测量阶段就定为
Hummingbot（Spot/Perp 连接器均 v2.0，Bitget 是 Foundation Partner）。
新增 research/live/。前置测量：
- bench_compute.py 本机算力，1m 单币 0.318s、三币串行 1.38s
- venue_parity.py Binance 与 Bitget 同根信号重合仅 14.6~42.6%
- signal_sensitivity.py 0.25bp 扰动就换掉一半信号
- aggregate_robustness.py 但总体期望不降——脆的是信号身份，不是 alpha
- bitget_baseline.py 因此改用 Bitget 原生基线定预算：余量 BTC -0.13bp、
ETH +4.02bp、SOL +2.92bp。BTC 本就为负，只作延迟测量的参照物
运行时选型：
- parity_env.py 容器与本机信号逐一相同（下标、中枢数、checksum 全等），
容器内 0.26s/币反而更快。故 chanlun 直接挂载进容器，不必另起信号服务。
装进现有 .venv 那条路走不通：Hummingbot 要 numba>=0.61.2 与
aiohttp<3.14，与本机 Python 3.14 冲突
- latency_ccxt.py / latency_hummingbot.py / latency_compare.py 初测显示
Hummingbot 比 ccxt.pro 慢约 1030ms，90 根逐根配对里 80~97% 更慢
- probe_ws_action.py 否掉「丢弃 snapshot」的猜测：换根首条就是 update
- probe_hb_vs_raw.py 与 latency_attribute.py 四路归因——容器网络 2~18ms、
Hummingbot 处理 -10~-30ms，1350~1480ms 全落在解析方式上
- probe_ws_payload.py 定位根因：Bitget 换根会推一条带两根的消息
[上一根, 新一根]，而上游取 data["data"][0] 拿到的是上一根，新一根要等
下一条单元素消息
修复：
- patched_candles.py 处理消息里的全部元素。不能简单改成 [-1]——那样上一根
的收盘价会永远停在换根前约 1 秒的那次推送上，而信号对 0.25bp 都敏感
- verify_patch.py 60 根配对验证：拿回 1060~1090ms，与原始 WS 只差 5~14ms
已贴理论下限，19 根已收盘 K 线 OHLCV 逐根未变。折算 ETH 省 0.54bp、
SOL 省 0.42bp。此 bug 值得向上游反馈
影子交易器：
- shadow_hb.py 不下单，读连接器真实盘口按仓位吃单深度算成交价，与次根开盘价
（回测 entry_delay=1 的口径）相减，分解成延迟漂移、盘口价差、深度冲击。
盘口 10Hz 滚动缓冲 30 秒，把延迟变成自变量：每个信号记 0.5/1/2/5s 与实际
算完时刻各一个滑点值，本机算得慢也不影响能读出的曲线
- shadow_signal.py 信号计算隔离到子进程。0.26s 是纯 CPU 且 chanlun 受 GIL
限制，放进 asyncio 循环会把行情处理一起卡住
- shadow_report.py 首日延迟门槛与滑点曲线报表
不用 paper trade 测滑点：它的成交由 Hummingbot 自己的撮合模型模拟，
测出来是模型行为而非市场行为。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-08-27 23:51:57 +08:00 |
|