2.6.5 全链路延迟审计与抖动监控 (End-to-End Latency Auditing & Jitter Monitoring)

如果说 2.6.4 是为了让算法“算得对”，那么 2.6.5 就是为了证明系统“跑得快”且“跑得稳”。这是系统性能的心电图，也是触发 2.3.5 热节流 和 2.3.4 故障恢复 的核心依据。

TL;DR

本节确立了 “关键节点埋点 (Checkpointing) + 驻留时间计算 (Residence Time)” 的基线策略。利用数据包中携带的 不可变时间戳 (Birth Timestamp) 作为 T0，在流水线的每个交接点（Handoff Point）采集当前时间，计算 阶段耗时 与 全系统驻留时间。监控数据通过 无锁直方图 (Lock-free Histogram) 聚合，并实时计算 P99 延迟与抖动（Jitter），一旦超出 CPI 周期阈值，立即触发流控。

一、约束输入与对齐 (Constraints & Alignment)

基于前序基线，我们面临以下硬性约束：

时间基准：所有打点必须使用 2.6.1 确立的 HighPrecisionClock (TSC-based)，以保证纳秒级精度和极低开销（< 20ns）。
零干扰：监控逻辑严禁阻塞业务线程。严禁在热路径上进行文件 I/O（写日志）或复杂的锁操作。
关联性：必须能够将延迟数据关联到具体的 StationID 和 TraceID，以便定位是哪个雷达阵面或哪一帧数据导致了卡顿。

二、权衡分析与选项呈现 (Trade-off Matrix)

议题 1：埋点粒度 (Granularity)

选项	A. 仅首尾打点 (Black Box)	B. 细粒度逐级打点 (White Box) (推荐)
机制	仅在 `DataReceiver` 入口和 `DisplayController` 出口记录。计算 $T_{out} - T_{in}$。	在每个模块的 Input/Output 队列处均打点：Rx, DSP_Start, DSP_End, Track, Tx…
开销	极低。	低（TSC 读取极快）。
诊断能力	差。只能知道系统慢了，不知道是 GPU 算慢了，还是 PCIe 堵了，还是调度器卡了。	强。能精确绘制“火焰图”，定位瓶颈环节。
结论	仅适用于最终用户 SLA。	研发与运维的标准解。

议题 2：数据聚合策略 (Aggregation Strategy)

选项	A. 全量日志 (Raw Logs)	B. 内存直方图聚合 (In-Memory Histogram) (推荐)
机制	`LOG(INFO) << "Packet " << id << " took " << lat << "us";`	维护一组原子计数器桶（Buckets），如 `<1ms`, `1-5ms`… 仅统计次数。
IO 压力	极大。每秒 10k 包产生 10k 条日志，瞬间打爆磁盘 IOPS。	零。仅涉及内存原子自增 (`fetch_add`)。
实时性	延迟高（需等日志落盘分析）。	实时。控制面可随时读取当前 P99 值。

三、基线确立与实施规范

为了实现“显微镜级”的性能观测，我们确立 B. 细粒度逐级打点 + B. 内存直方图聚合 为基线。

1. 关键路径检查点定义 (Checkpoint Definition)

我们将数据包在系统中的生命周期划分为 5 个关键时刻（Timestamp）：

T0 (Birth/Ingress): DataReceiver 收到 UDP 包的时刻（硬件/内核打点，见 2.6.2）。
- 阶段 1：接收耗时 (Rx Latency) = T_1 - T_0
T1 (Dispatch): AssemblyBuffer 组装完成，推入 GPU 输入队列的时刻。
- 阶段 2：排队与传输 (Queue & PCIe) = T_2 - T_1
T2 (Algo Start): SignalProcessor 从队列取出数据，开始 CUDA Kernel 的时刻。
- 阶段 3：计算耗时 (Compute) = T_3 - T_2
T3 (Algo End): 信号处理完成，生成点迹/航迹的时刻。
- 阶段 4：后处理与关联 (Post-Proc) = T_4 - T_3
T4 (Egress): DisplayController 完成序列化并调用 sendto 的时刻。

全链路驻留时间 (Residence Time) = $T_4 - T_0$。

2. 数据结构：伴随式遥测对象 (`TelemetryContext`)

为了避免在 DataPacket 中增加过多字段（膨胀 Payload），我们采用 “边车模式 (Sidecar)” 或利用 TraceContext（如果支持携带额外数据）。考虑到 C++ 性能，建议直接在 DataPacket::Header 中扩展调试字段（仅在 Debug/Profile 模式下启用）或使用 Thread Local 统计器。

生产环境基线（高性能方案）：不随包携带所有中间时间戳，而是 即时聚合。

// 伪代码：各模块内的埋点逻辑
void SignalProcessor::onData(DataPacket& pkt) {
    uint64_t now = Clock::now();
    
    // 1. 计算上一阶段耗时 (排队延迟)
    // Packet Header 中记录了上一个节点的离开时间 last_leav_time
    uint64_t queue_latency = now - pkt.header.last_leave_time;
    Metrics::Histogram("dsp_queue_latency")->observe(queue_latency);

    // 2. 执行业务
    process(pkt);

    // 3. 计算本阶段耗时
    uint64_t done = Clock::now();
    uint64_t compute_latency = done - now;
    Metrics::Histogram("dsp_compute_latency")->observe(compute_latency);

    // 4. 更新 Header，传给下游
    pkt.header.last_leave_time = done;
}

3. 抖动监控与告警阈值 (Jitter Monitor)

单纯看平均耗时（Avg）会掩盖问题，我们必须监控 P99 (99 分位) 和 抖动 (Jitter)。

抖动定义：J_i = |(T4_i - T4_{i-1}) - (T0_i - T0_{i-1})|
- 即：输出间隔的变化量 与 输入间隔的变化量 之差。
- 理想情况下，如果系统处理能力恒定，输入是 10ms 间隔，输出也应该是 10ms 间隔，抖动为 0。
阈值设定：
- Warning: P99 Latency > $0.8 \times \text{CPI_Interval}$。
- Critical: P99 Latency > $1.0 \times \text{CPI_Interval}$（系统已无法实时处理，必然积压）。

4. 闭环反馈：触发热节流 (2.3.5 Linkage)

这是 2.6.5 与 2.3.5 的联动点。热节流不仅仅由温度触发，也应由性能拥塞触发。

逻辑： MonitoringModule 每秒轮询一次延迟指标。
- 如果 dsp_queue_latency (排队延迟) 持续增长 -> 说明 GPU 处理不过来。
- 动作：发布 SystemOverloadEvent(Type=COMPUTE_LAG)。
- 响应：调度器下发 SetComputeThrottleEvent(Level=1)，通过主动降级（如减少点迹提取数量）来恢复实时性。

四、总结：2.6 章节整体回顾

至此，2.6 时序同步与数据一致性 已全部完成。我们构建了一套严密的时空治理体系：

2.6.1 时钟源：Hardware PTP + TSC，确保尺子是准的。
2.6.2 打点：Kernel/Hardware Ingress Timestamp，确保起点是真实的。
2.6.3 对齐：原地乱序重组，确保数据在进入算法前是齐整的。
2.6.4 融合：异步外推，确保航迹与量测在物理时间上是对齐的。
2.6.5 审计：全链路耗时监控，确保系统没有因过载而失速。

7.0 KiB Raw Permalink Blame History Unescape Escape

2.6.5 全链路延迟审计与抖动监控 (End-to-End Latency Auditing & Jitter Monitoring)

TL;DR

一、 约束输入与对齐 (Constraints & Alignment)

二、 权衡分析与选项呈现 (Trade-off Matrix)