PTP 时钟漂移导致分布式锁"租约过期"误判：如何 10 分钟内区分 NTP、网卡驱动与内核时基？

【背景】 我负责一套 12 节点业务集群（Linux 5.15，gRPC + etcd 做分布式锁），节点分布在两个机房，走 25G 内网专线。集群里所有节点的 NTP 源都指向同一个机房 A 的 chrony server（stratum 2，上游是阿里云 NTP），关键业务用 etcd lease（TTL=15s）做选主。

【现象】 最近 3 周，机房 B 的 3 台节点（10.20.40.x）每隔 2–4 小时出现一次"被踢出选主"，应用日志报 etcd lease expired，但 etcd 服务端日志里 lease 实际还活着（只是客户端续约请求因为时间戳被服务端判定为"未来时间"而丢弃）。机房 A 的 9 台节点 0 次复现。ping/iperf 全绿，交换机队列 0 堆积。

【已尝试的排查】

1. chronyc tracking：事发时 offset 从正常的 +0.8ms 跳到 +230ms，然后 5 分钟内又回到 +1ms——典型的"漂移-拉回"，不是 NTP 源挂了（源端日志 0 异常）。
2. dmesg 无 NIC 告警，ethtool -S 无 rx_missed_errors / rx_dropped。
3. 抓包看到事发时本机发出的续约请求，TCP timestamp 比对端回包早 200ms+——说明是本机时钟被推快了，不是网络延迟。
4. 怀疑三个方向：(a) chrony 在弱网窗口拉了个坏 sample 没被过滤；(b) 网卡驱动（ixgbe 5.15）在 PTP 模式下 hwclock 和内核 timekeeping 打架；(c) 内核 TSC 不稳定（这台是较老的 Xeon E5-2680v3）。

【期望的回答形态】 希望有同样踩过这个坑的同学给一套可执行的最小排查路径，按"10 分钟内能定位到 NTP / 驱动 / 内核时基三选一"的粒度回答：

1. 哪几条命令能一次区分三种根因？（我目前想到的候选：chronyc sources -v、chronyc activity、hwclock --show 对比 date、dmesg | grep -i tsc、cpupower frequency-info 看 TSC 是否 stable，但不确定够不够。）
2. 如果是 chrony 拉了坏 sample，怎么配置 makestep / stratumweight / local stratum 让它更稳？
3. 如果是 NIC PTP 驱动问题，ixgbe 在 5.15 上有没有已知的 hwclock 漂移 bug，怎么关掉 PTP 走纯 NTP 验证？
4. 业务侧有没有兜底：etcd lease TTL 设多少才不会被这种 200ms 级别的时间戳抖动误杀？

有具体版本、配置片段、复现步骤的回答优先，谢谢。