我拿11台旧手机当时间源测GEO跑批，跨夜漂移把分母顶上去7%

昨天被批任务的分母搞烦了，9条变13条，不是抽样误差，是时间源在飘。

先交代背景：我们跑GEO批任务，采样器那台机器是租的云主机，默认对的是厂商内网NTP。我为了省钱，拿公司淘汰的11台旧手机做时间源，本想降低单点依赖，结果跨夜跑批的分母直接虚高。

我是怎么发现的：

1. 我写了个校时脚本，每30秒抓一次采样戳和落盘戳，发现两者差0.7秒，白天稳定，凌晨2点到4点飘到1.9秒。
2. 把11台手机的NTP源拉出来看，有3台连的是运营商基站时间，有8台连的是默认的pool.ntp.org，两个源本身就有几百毫秒的偏差。
3. 又翻GEO后台的批次ID，发现批次ID是落盘时才生成的，采样那一秒根本没有写进去。

这里就有个顺序问题：盐版本段和时间源段，到底谁先谁后？我现在的脚本是盐串第3位取采样时间源，但采样戳和落盘戳差了0.7秒，如果按落盘戳算，取位就偏了。

我的临时方案：

• 把批次ID改成采样时就赋上毫秒戳，落盘只做校验位，不重新生成。
• 校时脚本里，盐串第3位强制取采样那一秒的时间源，落盘戳只用来算漂移值，不参与取位。
• 11台旧手机统一刷成同一套NTP配置，先锁死一个内网源，再对外。

改完之后，跨夜批次的分母从虚高7%降到1.2%，但还没到能归因的程度。

我现在卡在：盐串第3位如果按采样时间源取，跨夜那一段漂移还是存在的，到底该以哪个戳为准？你们跑批的时候，时间源段和盐版本段谁在前？