Klein/Inbox

Fork 0

Files

Klein 0d81c1792d 创建仓库

2025-12-11 07:24:36 +08:00

33 KiB

Raw Permalink Blame History

tags, aliases, date created, date modified

Project_Baseline 的深度补全

1. 开发环境与构建生态 (Development Environment & Build Ecology)

核心指向：确立代码“以此为基”运行的所有静态背景。包含操作系统底座、异构编译工具链的特殊性、以及依赖库的边界。

1.1 操作系统与内核基座 (OS & Kernel Baseline)

覆盖范围：定义代码运行的最底层软件土壤。重点关注操作系统发行版的特定版本限制、Linux 内核参数配置、以及系统级基础库（如 libc/libstdc++）的兼容性边界。
1.1.1 发行版与内核版本指纹
- 指向：具体的发行版元数据、内核发布号、补丁级别、以及内核构建时的 GCC 版本（防止 insmod 版本不匹配）。
1.1.2 内存子系统策略 (Memory Subsystem Policy)
- 指向：大页内存（HugePages）配置、透明大页（THP）状态、虚拟内存交换策略（Swappiness）、Overcommit 策略。
1.1.3 CPU 调度与核心隔离 (CPU Scheduling & Isolation)
- 指向：CPU 亲和性（Affinity）默认策略、隔离核心（Isolcpus）配置、NUMA 节点拓扑、实时调度策略限制。
1.1.4 系统级资源限制 (System Resource Limits)
- 指向：文件句柄限制（Open Files）、栈空间大小（Stack Size）、最大进程数（NPROC）、核心转储（Core Dump）策略。
1.1.5 设备节点与总线映射 (Device Nodes & Bus Mapping)
- 指向：PCIe 地址空间布局（BAR 空间）、设备文件权限（/dev/*）、IOMMU 组别状态，IO 调度算法 (I/O Scheduler)。
1.1.6 时间同步服务 (Time Synchronization)
- 雷达系统涉及多板卡协同，OS 层面的时钟源（TSC/HPET）以及 chrony/ptp4l 的状态决定了打时标的精度。如果 OS 时间漂移，信号处理的时间对齐会出错。

1.2 异构编译工具链体系 (Heterogeneous Compiler Toolchain)

覆盖范围：区分 Host 端 (CPU) 与 Device 端 (GPU) 的差异化编译路径。重点解决“谁来编译什么”以及“它们如何握手”的问题。
1.2.1 Host 端编译器规范 (Host Compiler Spec)
- 指向：g++ 的绝对路径、版本指纹、以及它所定义的默认 C++ 标准（-std=c++11 vs gnu++14）。
1.2.2 Device 端编译器规范 (Device Compiler Spec)
- 指向：clang++ 的绝对路径、版本、Corex 后端 Target 标志（例如 -x ivcore）、以及它是如何被 CMake 识别的。
1.2.3 链接器与加载器配置 (Linker & Loader)
- 指向：ld 版本、rpath 策略（确保运行时能找到 libixattn.so 等非标库）。
1.2.4 混合编译兼容性 (Hybrid Compilation Compatibility) <-- 新增
- 指向：clang++ 自动引用的 GCC Toolchain 路径（--gcc-toolchain）、C++ 标准库的一致性检查、以及强制定义的预处理宏（Macros）。

1.3 GPGPU 软件开发套件 (GPGPU SDK & Driver Stack)

覆盖范围：不仅包含驱动和基础运行时，重点核查数学库、模板库及官方示例代码。
1.3.1 驱动核心模块状态 (Driver Kernel Modules)
- 指向：.ko 模块加载参数、依赖关系（vfio-pci）、以及 /dev 设备节点的权限与映射。
1.3.2 运行时环境与兼容层 (Runtime Environment & Shim Layer)
- 指向：libcudart.so 的版本伪装、libcuda.so (Driver API) 的存在性、以及动态链接库的真实物理位置。
1.3.3 管理与监控接口 (Management Interfaces)
- 指向：ixsmi 工具的可用性、显存/算力占用查询指令、以及 ECC 错误统计接口（雷达长时运行必需）。
1.3.4 核心数学加速库 (Core Math Libraries)
- 指向：FFT (cuFFT) 和 BLAS (cuBLAS) 库的具体存在性、版本号。这是雷达业务的“心脏”。
1.3.5 开发者头文件与生态 (Developer Headers & Ecosystem)
- 指向：cuda_runtime.h 等头文件的位置、内容检查（是原版还是魔改版？），以及 thrust/ 库是否存在。
1.3.6 官方示例与构建范式 (Official Samples & Build Patterns)
- 指向：SDK 自带 Sample 代码的目录结构、Makefile 写法。这是 AI 学习“如何正确调用 SDK”的唯一真理来源。

1.4 构建系统与工程配置 (Build System & Project Configuration)

覆盖范围：定义“源码 -> 二进制”的自动化流水线。不仅包含 CMake 语法，更包含对异构编译器行为的强制管控。
- 1.4.1 CMake 核心环境与生成器 (CMake Core & Generator)
  - 指向：CMake 最低版本要求 (cmake_minimum_required)、生成器类型 (Unix Makefiles vs Ninja)、以及构建目录外构建 (Out-of-source Build) 的强制策略。
- 1.4.2 异构编译器编排策略 (Heterogeneous Compiler Orchestration)
  - 指向：如何锁定 Host 编译器 (CMAKE_CXX_COMPILER)、如何传递 Device 编译器路径 (CLANG_CUDA_COMPILER)，以及 project() 命令定义的语言范围（是仅 CXX 还是包含 CUDA）。
- 1.4.3 编译选项与性能开关 (Compilation Flags & Performance Switches)
  - 指向：
    - Host 端：-O3, -march=armv8-a+lse, -Wall。
    - Device 端：-x ivcore, --cuda-gpu-arch, -fPIC。
    - 宏定义：NDEBUG, __ILUVATAR__ 等全局宏的管理。
- 1.4.4 依赖管理与链接逻辑 (Dependency Management & Linking Logic)
  - 指向：头文件搜索路径 (include_directories vs target_include_directories)、RPATH 设定 (CMAKE_INSTALL_RPATH)、以及 FindPackage vs FetchContent (如 GTest) 的使用策略。
- 1.4.5 产物输出与安装规则 (Artifact Output & Installation Rules)
  - 指向：CMAKE_RUNTIME_OUTPUT_DIRECTORY (bin 目录)、make install 的行为、以及调试符号 (.debug) 的剥离策略。

1.5 核心依赖库与中间件 (Core Dependencies & Middleware)

覆盖范围：除 OS 和 GPU SDK 外的第三方“军火库”。重点关注 Host 端算法支撑、数据链路传输、以及系统可观测性基础设施。
- 1.5.1 系统运行时与 ABI 基线 (System Runtime & ABI Baseline)
  - 核心指向：这是二进制兼容性的底线。不仅要看 glibc，还要确认 libstdc++.so 包含的符号版本（GLIBCXX_3.4.x），防止引入的新库报 "version not found"。同时关注 zlib / openssl 等基础压缩加密库的版本。
- 1.5.2 Host 端信号处理与数学库 (Host Signal Processing & Math Libs)
  - 核心指向：服务于 CPU 端的预处理/后处理算法。重点探测 FFTW3（是否存在？是否开启了 NEON 优化？）、OpenBLAS 或 Eigen。这些库的性能直接决定了 CPU 负载。
- 1.5.3 通信、存储与基础设施中间件 (Comm, Storage & Infra Middleware)
  - 核心指向：服务于数据网关和系统健壮性。
    - 通信：ZeroMQ/DDS（传输层）、Protobuf/Flatbuffers（协议层）。
    - 存储：HDF5/Parquet（用于存原始回波）。
    - 基建：spdlog/glog（高性能日志）、yaml-cpp/jsoncpp（配置解析）。

1.6 调试、分析与版本控制工具 (Debugging, Profiling & Versioning)

覆盖范围：涵盖从代码质量（内存安全）到性能验证（实时监控），再到大文件管理（Git LFS）的全周期辅助工具。
- 1.6.1 异构调试与内存安全 (Heterogeneous Debugging & Memory Safety)
  - 核心指向：确保代码逻辑正确性与内存健壮性。
  - 内容：GDB 版本与远程/异构配置、C/C++ 内存检测工具（如 Valgrind）、以及 IDE（如 VSCode）对 GPU 调试的集成状态。
- 1.6.2 性能分析与实时监控 (Performance Analysis & Real-time Monitoring)
  - 核心指向：确保代码运行在正确速度并符合实时性要求。
  - 内容：GPU 专用 Profiler（如 ixsmi 高级功能）、Linux 内核分析工具（Perf/ftrace）、以及实时系统负载工具（htop、numa 监控）。
- 1.6.3 版本控制与数据基线管理 (Versioning & Data Baseline Management)
  - 核心指向：确保工程版本与数据的一致性。
  - 内容：Git 版本、Git LFS (雷达数据/系数文件) 配置、CI/CD 环境中的版本标签规范。

2. 数据接口与通信协议 (Data Interface & Communication Protocols)

核心指向：定义系统的“输入”与“输出”。包含前端 ADC 数据的接入方式、内部模块间的数据流转格式、以及对外的结果分发协议。

2.1 原始数据链路与采集协议 (Raw Data Link & Acquisition Protocol)

覆盖范围：定义从雷达前端 ADC/DPU 发送至 Host 端的物理传输机制、链路协商、以及数据包的 L2/L3 层结构。重点关注 PCIe/万兆/自定义高速链路的适配和 JUMBO Frame 的支持状态。
- 2.1.1 物理链路层与传输媒介 (Physical Link Layer & Transport Medium)
  - 核心指向：定义 Host 端 NIC（网络接口卡）或采集卡与前端 DPU/ADC 之间的物理连接类型和规格。涵盖光纤/铜缆 SFP 模块类型、端口速率（10G/40G/100G）、PCIe 链路的实际协商速度与带宽（GT/s, Link Width），以及链路协商的自适应或强制模式。
- 2.1.2 数据链路层协议与封装 (Data Link Layer Protocol & Encapsulation)
  - 核心指向：定义数据流在 L2/L3 层的协议选择。涵盖是否使用标准 UDP/IP 协议，或者定制的裸 Ethernet/RoCE 协议。重点关注 JUMBO Frame 的最大有效载荷（MTU）设置，以及自定义协议头中对雷达单元 ID 和波束 ID 的封装格式。
- 2.1.3 NIC 硬件资源与队列管理 (NIC Hardware Resource & Queue Management)
  - 核心指向：定义网络接口控制器（NIC）硬件的性能参数和配置。涵盖网卡 RX/TX 环形缓冲区（Ring Buffer） 的深度配置、中断聚合（Interrupt Coalescing） 的延迟和计数阈值，以及 RX/TX 队列到 CPU 核心的亲和性（Affinity）绑定策略。
- 2.1.4 数据包完整性与时序保证 (Packet Integrity & Sequencing Assurance)
  - 核心指向：定义在链路层对数据可靠性的保障机制。涵盖雷达数据包的序列号（Sequence Number） 字段、数据包头的 CRC/Checksum 校验、以及对传输层丢包率的实时监控与统计方法。
- 2.1.5 DMA 与内核旁路策略 (DMA & Kernel Bypass Strategy)
  - 核心指向：定义从 NIC 硬件接收缓冲区将数据移动到用户态内存的高速策略。涵盖是否使用传统的内核 TCP/UDP 堆栈，还是采用 DPDK、AF_XDP 或 RDMA 等内核旁路技术实现零拷贝（Zero-copy）的数据路径，以最小化 CPU 参与和内核延迟。

2.2 异构 DMA 与内存传输机制 (Heterogeneous DMA & Memory Transfer Mechanism)

覆盖范围：定义 Host CPU 与 Device GPU（智铠 MR-V100）之间的高速、低延迟数据移动策略。重点关注 零拷贝（Zero-copy）、UVA (统一虚拟寻址) 的利用、以及对 NUMA 拓扑的感知，以优化 Node 1 显存访问性能。
- 2.2.1 锁页内存管理与分配策略 (Page-Locked/Pinned Memory Management)
  - 核心指向：定义 Host 端内存的分配方式以适配 DMA 引擎。涵盖使用 cudaMallocHost 或 cudaHostRegister 申请锁页内存（Pinned Memory），以规避 OS 分页机制导致的 DMA 拷贝性能下降。对于雷达高吞吐业务，需定义专用的大块内存池（Memory Pool）以减少频繁申请/释放的系统调用开销。
- 2.2.2 异步流水线与计算通信重叠 (Asynchronous Pipelining & Compute-Copy Overlap)
  - 核心指向：定义如何利用 GPU 的独立 Copy Engine 实现“掩盖传输延迟”。涵盖 CUDA Streams 的多流设计模式，实现 H2D (Host-to-Device) 拷贝、Kernel 计算、D2H (Device-to-Host) 拷贝的三级流水线并行（Ping-Pong / Double Buffering）。
- 2.2.3 NUMA 感知的内存亲和性控制 (NUMA-Aware Memory Affinity Control)
  - 核心指向：针对双路飞腾 S5000C 的特殊架构，定义内存物理位置的约束。强制要求与 GPU 交互的 Host 内存必须分配在 NUMA Node 1（即 GPU 所挂载的 CPU 插槽）的本地 DRAM 上，严禁跨 QPI/UPI 总线进行 DMA 传输，以避免带宽减半和延迟抖动。
- 2.2.4 统一虚拟寻址与零拷贝技术 (Unified Virtual Addressing & Zero-Copy)
  - 核心指向：利用 Iluvatar SDK 的 UVA 特性，定义特定场景下的免拷贝访问策略。涵盖对于小数据量（如控制参数、波控码）直接让 GPU 通过 PCIe 总线读取 Host 内存（Zero-Copy），以及评估在大数据量回波传输中启用 UVA 的 TLB Miss 风险与收益。
- 2.2.5 传输粒度与 TLP 效率优化 (Transfer Granularity & TLP Efficiency)
  - 核心指向：定义 DMA 传输的最小数据块大小（Batch Size）。基于 PCIe 协议的 TLP (Transaction Layer Packet) 开销和 MPS (Max Payload Size) 限制（审计发现仅 128/256 Bytes），计算最优的传输粒度（如按 CPI 或 Pulse Batch），以最大化 PCIe 有效载荷比率。
- 2.2.6 显存布局与对齐约束 (VRAM Layout & Alignment Constraints)
  - 核心指向：定义数据在显存中的物理排列。涵盖满足 GPU 内存控制器 Coalesced Access (合并访问) 要求的首地址对齐（通常为 128/256 字节对齐）、Padding 填充策略，以及多通道雷达数据的存储格式（SoA vs AoS）转换逻辑，以适配 SIMT 计算模式。

2.3 内部控制平面通信接口 (Internal Control Plane Interface - IPC)

覆盖范围：定义系统内部各功能模块（IModule）与核心管理组件（调度器、配置管理器）之间的控制流交互机制。该接口基于**进程内事件总线（In-Process EventBus）**架构，实现模块间的解耦、生命周期编排、资源仲裁及故障传递。核心约束：控制平面严禁传输任何业务数据块（如 I/Q 数据或点迹数组），仅允许传输元数据、状态码和控制指令。
- 2.3.1 事件总线架构与路由机制 (Event Bus Architecture & Routing Mechanism)
  - 核心指向：定义系统控制流的中枢神经。采用发布 - 订阅 (Pub/Sub) 模式，实现 IEventBus 接口。支持同步分发（publishSync，用于高优先级指令的即时回调）与异步分发（publishAsync，用于状态上报的非阻塞入队）的混合路由策略，确保控制指令在微秒级内准确送达。
- 2.3.2 全链路追踪上下文传递 (Trace Context Propagation)
  - 核心指向：定义控制指令的审计与追踪规范。强制要求所有控制事件（Event）必须携带全局唯一的 TraceID。涵盖在跨线程（如从 API网关 线程到 SignalProcessor 工作线程）传递事件时，利用 TraceContextGuard 或类似的 RAII 机制自动捕获、保存和恢复线程本地存储（TLS）中的追踪上下文，实现“无感”的链路追踪。
- 2.3.3 生命周期编排与状态同步协议 (Lifecycle Orchestration & State Synchronization)
  - 核心指向：定义 TaskScheduler 与业务模块间的握手协议。涵盖标准化的生命周期指令事件（StartModuleEvent, StopModuleEvent, PauseModuleEvent）以及模块的状态变更回执（ModuleRunningEvent, ModuleStoppedEvent）。重点关注在系统启动/关闭时的拓扑依赖顺序控制逻辑，确保无“悬空”状态。
- 2.3.4 故障传播与恢复信令 (Fault Propagation & Recovery Signaling)
  - 核心指向：定义异常情况下的通信契约。涵盖致命错误上报（ModuleFailedEvent，携带标准化 ErrorCode 和堆栈快照）的格式，以及调度器下发的恢复指令流（如 PauseDataFlow -> RestartModule -> ResumeDataFlow）的时序规范。集成**熔断器（Circuit Breaker）**状态广播，防止故障扩散。
- 2.3.5 系统负载保护与热节流控制 (System Load Protection & Thermal Throttling)
  - 核心指向：鉴于显控架构的扁平化，控制平面的资源管理重心从“UI 响应性保障”转移至 “系统物理安全保障”。接口仅用于在极端工况（如机箱温度过高、GPU 功耗触顶）下，强制降低计算负载以保护硬件。
- 2.3.6 两阶段配置热更新协议 (Two-Phase Configuration Hot-Reload Protocol)
  - 核心指向：定义动态配置变更时的协商机制。涵盖 ConfigManager 发起的 “验证询问”（ValidateConfigChangeEvent，模块需在超时前反馈可行性）和 “变更通知”（ConfigChangedEvent，模块执行原子更新），确保在并发环境下配置更新的事务一致性。
- 2.3.7 性能指标遥测通道 (Performance Telemetry Channel)
  - 核心指向：定义业务模块向 MonitoringModule 上报健康数据的单向通道。涵盖 MetricsUpdateEvent 的数据结构定义（键值对映射），以及采用 线程本地缓存（Thread-Local Storage） 结合 MPSC（多生产单消费）队列 的高吞吐、无锁上报策略，彻底消除监控逻辑对业务主线程的锁竞争干扰。

2.4 外部目标数据分发协议 (External Target Data Distribution Protocol)

覆盖范围：定义核心处理服务器（通过 DisplayController）向外部独立显控终端分发高实时性业务数据（如航迹、点迹）的网络通信契约。鉴于显控端采用轻量级 2D 渲染，本协议不再包含针对 UI 交互的流控逻辑，而是专注于全速、单向、无阻塞的数据推送，仅在接收到系统级热保护指令时执行被动节流。
- 2.4.1 传输层拓扑与套接字模型 (Transport Layer Topology & Socket Model)
  - 核心指向：定义数据传输的物理载体。采用 UDP 单播 (Unicast) 模式，由服务器作为发送方，向单一客户端推送。强制使用 非阻塞 (Non-blocking) Socket 配合 epoll 边缘触发模式。鉴于已移除 UI 抢占逻辑，Socket 发送缓冲区 (SO_SNDBUF) 应配置为最大可用值（如 8MB+），以吸收网络抖动，确保在计算核心全速运转时网络层不成为瓶颈。
- 2.4.2 业务数据序列化规范 (Business Data Serialization Specification)
  - 核心指向：定义跨网络二进制格式。继续强制使用 Google Protobuf (v3)。数据包根对象 TrackDataBatch 必须包含全链路追踪 ID (TraceID)。由于取消了任务切分，数据包的生成频率将与雷达脉冲处理周期（CPI）严格同步，不再出现因被抢占而导致的“微批次（Micro-batch）”碎片化数据包。
- 2.4.3 丢包检测与时序完整性机制 (Packet Loss Detection & Sequencing Integrity)
  - 核心指向：定义数据一致性策略。协议头包含单调递增的 batch_sequence_id。客户端对于乱序包执行立即丢弃策略。由于后端不再因 UI 操作而暂停，客户端应预期收到极其平稳的数据流；任何超过 2 个周期的静默都应被客户端判定为“网络故障”而非“后端繁忙”，并触发重连告警。
- 2.4.4 热节流响应与流量整形 (Thermal Throttling Response & Traffic Shaping)
  - 核心指向：（基于 ECN 修正） 定义在系统过热时的降级行为。当 DisplayController 收到 SetComputeThrottleEvent（热保护指令）时，必须在网络发送层执行主动丢包或发送间隔插入（Gap Insertion），以减少网卡中断和总线功耗。例如，在 Level 2 节流状态下，仅发送关键航迹数据（Confirmed Tracks），丢弃所有点迹（Plots）和调试数据，从而降低系统整体热负荷。
- 2.4.5 端到端延迟遥测 (End-to-End Latency Telemetry)
  - 核心指向：定义性能监控闭环。数据包必须携带 “数据生成时间戳”。客户端计算 Glass-to-Glass Latency 并回传。此指标现在主要用于监控网络链路质量和散热系统的有效性（即观察热节流是否导致了延迟显著增加），而非用于调节 UI 渲染优先级。

变更说明 (基于 ECN-2025-001)：

移除：移除了所有关于“为了 UI 响应性而暂停数据发送”的描述。
新增：2.4.4 热节流响应。这是新架构下唯一合法的“主动降速”场景。
调整：在 2.4.1 中强调了 Socket 缓冲区配置为“最大值”，因为不再需要担心缓冲区积压影响 UI 线程（UI 线程已与计算/发送线程物理解耦且互不干扰）。

下一步交互建议： 我们已完成基于 ECN 补丁修正的 2.4 外部目标数据分发协议。请指示：我们是继续进行 3. 信号处理算法与数学原理 的分解，还是您有其他的 ECN 需要应用？

2.5 数据结构定义与序列化规范 (Data Structure Definition & Serialization Specification)

覆盖范围：定义系统内外部数据交互的静态契约。该规范严格区分 “内部原生对象（In-Memory Native Objects）” 与 “外部传输契约（On-Wire Contracts）”，并界定两者之间的转换边界。内部关注极致的计算性能（SIMD 对齐、零拷贝），外部关注跨语言/跨平台的互操作性（Protobuf）。
- 2.5.1 内部高性能业务对象模型 (Internal High-Performance Business Object Model)
  - 核心指向：定义在 DataReceiver -> SignalProcessor -> DataProcessor 流水线中流转的 C++ 原生结构体（DTO）。涵盖 DetectionResult（点迹）和 TrackData（航迹）的内存布局设计，强制使用 POD (Plain Old Data) 类型，并应用 alignas(16/32) 以适配 SIMD (AVX/NEON) 向量化指令优化，严禁在核心计算路径上使用虚函数或复杂对象。
- 2.5.2 内部控制事件模式定义 (Internal Control Event Schema Definition)
  - 核心指向：定义在 EventBus 上流转的控制信令结构。所有事件必须继承自 BaseEvent，并强制包含 全链路追踪 ID (TraceID) 和 高精度时间戳。事件负载（Payload）必须保持轻量（通常仅包含状态码、配置键值对或对象 ID），严禁携带大块业务数据（如 I/Q 波形），以保障控制平面的低延迟响应。
- 2.5.3 外部数据交换契约 (External Data Exchange Contract)
  - 核心指向：定义系统向外部（显控终端、API 网关）输出数据的接口定义语言 (IDL)。强制选用 Google Protobuf (v3) 作为唯一标准。涵盖 .proto 文件的版本管理规范（语义化版本控制），以及字段的 向前/向后兼容性 设计原则（如使用 optional 字段，保留 reserved 标识符），确保前后端可独立演进。
- 2.5.4 零拷贝数据容器规范 (Zero-Copy Data Container Specification)
  - 核心指向：定义承载内部业务对象的通用包装器 DataPacket<T>。涵盖其 Header 的标准化元数据（序列号、源模块、TraceID），以及 Payload 的所有权管理机制——必须使用 std::unique_ptr 配合 自定义删除器 (Custom Deleter)，以实现内存块在生命周期结束时的自动归还（回收到 MemoryPool），彻底消除内存泄漏风险。
- 2.5.5 序列化边界与映射策略 (Serialization Boundary & Mapping Strategy)
  - 核心指向：定义“内部对象”转换为“外部格式”的唯一合法位置。明确规定 仅在 DisplayController（数据网关） 和 ApiCommandService（API 响应） 处进行序列化操作。涵盖从 C++ Struct 到 Protobuf Message 的字段映射逻辑（Mapping Logic），以及在边界处进行 数据清洗与脱敏 的安全规范。

2.6 时序同步与数据一致性 (Timing Synchronization & Data Coherence)

覆盖范围：定义系统的时间基准获取方式、数据流打点策略以及跨模块处理时的时间对齐逻辑。涵盖从硬件层面的 PTP/GPS 同步，到软件层面的 CPI（相干处理间隔）对齐，以及航迹预测中的时间外推算法，确保系统在微秒级精度下的时空一致性。
- 2.6.1 高精度统一时钟源架构 (High-Precision Unified Clock Architecture)
  - 核心指向：定义系统时间的唯一真值来源。优先采用 PTP (IEEE 1588v2) 协议通过网口同步至 GPS/北斗授时服务器，实现亚微秒级的时间同步精度。涵盖在 PTP 不可用时的 NTP 回退策略，以及利用 CPU TSC (Time Stamp Counter) 寄存器作为高频计时源的校准逻辑，防止系统时间跳变（Time Jump）导致的逻辑错误。
- 2.6.2 多级数据打点策略 (Multi-Level Timestamping Strategy)
  - 核心指向：定义数据包时间戳的生成位置与精度分级。首选网卡硬件 TSU (Timestamp Unit) 生成的入站时间戳（Ingress Timestamp），次选内核网络栈的 SO_TIMESTAMP 软件时间戳。在 DataReceiver 封装 RawDataPacket 时，强制将此硬件/内核时间戳固化为数据的 “诞生时间” (Generation Time)，并在后续全链路中保持不变。
- 2.6.3 相干处理间隔对齐机制 (CPI Alignment Mechanism)
  - 核心指向：针对信号处理模块的特殊时序要求。定义如何根据雷达 PRF (脉冲重复频率) 和 波位编码，将连续到达的 UDP 数据包在内存池中重组为严格对齐的 CPI 数据块。涵盖处理网络抖动导致的脉冲到达时间波动（Jitter）的缓冲策略，确保 FFT 和多普勒处理时的数据在时间域上严格相干。
- 2.6.4 航迹外推与异步测量融合 (Track Extrapolation & Asynchronous Measurement Fusion)
  - 核心指向：针对数据处理模块的时空一致性逻辑。定义在进行数据关联（Data Association）时，如何将上一时刻（$t_{k-1}$）的航迹状态，基于运动模型精确外推至当前测量时刻（$t_k$）。涵盖处理乱序到达（Out-of-Order）量测数据的延迟关联或丢弃策略，确保卡尔曼滤波的更新步基于单调递增的时间轴。
- 2.6.5 全链路延迟审计与抖动监控 (End-to-End Latency Auditing & Jitter Monitoring)
  - 核心指向：定义系统实时性的度量标准。利用 DataPacket 头部携带的诞生时间戳，在流水线的每个关键节点（接收、信号处理完成、航迹更新完成、网关发送）计算 驻留时间 (Residence Time)。监控模块需实时统计各阶段的延迟分布，一旦发现处理抖动超过 CPI 周期的一定比例（如 10%），立即触发性能告警或热节流保护。

2.7 链路鲁棒性与错误校检 (Link Robustness & Error Checking)

覆盖范围：定义系统对通信链路故障的容错能力。涵盖在 UDP 链路中部署 CRC/Checksum 校验、丢包统计与报告机制、以及内部 IPC 异常时的超时和重试策略。
- 2.7.1 应用层数据完整性校验 (Application-Layer Data Integrity Verification)
  - 核心指向：弥补 UDP 标准校验和（16-bit）在大数据量传输下的碰撞风险。确立 CRC32c (Castagnoli)（硬件指令加速）为标准算法，强制在所有 TrackDataBatch 和 RawDataPacket 的协议头中包含校验字段。定义校验失败时的**“零容忍”丢弃策略**，防止比特翻转（Bit Flip）导致的脏数据污染卡尔曼滤波状态。
- 2.7.2 链路健康度监测与心跳机制 (Link Health Monitoring & Heartbeat Mechanism)
  - 核心指向：定义双向链路的保活协议。在数据静默期（无业务数据发送时）强制发送 高频心跳包 (1Hz - 10Hz)，以维持中间网络设备的 NAT 映射并快速检测物理断连。定义 “静默超时” (Silence Timeout) 阈值（如 2000ms），一旦触发即判定链路中断，自动触发告警并重置接收状态机。
- 2.7.3 差异化丢包恢复策略 (Differentiated Packet Loss Recovery Strategy)
  - 核心指向：针对不同业务流性质定义恢复逻辑。对于 实时雷达数据（Data Plane），采用 “即时丢弃 (Drop-and-Forget)” 策略，严禁重传以避免队头阻塞（Head-of-Line Blocking）；对于 关键控制指令（Control Plane），采用 “带确认重传 (ARQ / ACK-Retry)” 机制，确保配置变更和启停指令的必达性。
- 2.7.4 内部 IPC 拥塞控制与背压 (Internal IPC Congestion Control & Backpressure)
  - 核心指向：针对进程内 SPSC（无锁队列）的溢出保护。定义 “有界队列 (Bounded Queue)” 策略，当队列深度达到高水位（High Watermark，如 80%）时，对上游模块施加背压 (Backpressure)，强制执行 “尾部丢弃 (Tail Drop)” 或 “间隔抽稀”，优先保障系统主进程不发生 OOM（内存溢出）。

3. 异构计算架构与资源调度 (Heterogeneous Computing & Resource Scheduling)

覆盖范围：从任务模型的定义，到 CPU/GPU 的分工，再到显存内部的精细化管理。核心目标是在 Feiteng + Iluvatar 平台上实现 “数据进，结果出，中间无阻塞，显存不碎片” 的极致流水线。

3.1 异构协同模型与职责边界 (Heterogeneous Collaboration Model & Responsibility Boundary)

核心指向：明确 Host (CPU) 与 Device (GPU) 的绝对分工。确立 “控制密集型在 CPU，计算密集型在 GPU” 的原则。定义 CPU 不再是“保姆”（微观管理每个 Kernel 的启动），而是“指挥官”（下发宏观指令包）。界定后处理（CFAR 之后的数据关联）回流 CPU 的具体边界点，防止 GPU 算力被标量逻辑浪费。

3.2 计算图静态编排与执行引擎 (Static Compute Graph & Execution Engine)

核心指向：针对雷达算法流程固定的特性，摒弃运行时动态解析 DAG（有向无环图）的高开销模式。定义 “静态编译图 (Static Compiled Graph)” 策略，在系统初始化阶段将业务流程固化为一系列预定义的 TaskNode 链表。执行引擎（Execution Engine）仅需按序触发，实现 零开销调度 (Zero-Overhead Scheduling)。

3.3 GPU 上下文与流并发策略 (GPU Context & Stream Concurrency Strategy)

核心指向：定义如何利用智铠 GPU 的硬件队列（Hardware Queues）。鉴于 ECN-2025-001 已移除 UI 抢占，本节确立 “通道级并行 (Channel-Level Parallelism)” 策略。即每个雷达通道（或波束）绑定一个独立的 cudaStream_t，实现多通道算法的物理并行执行，最大化 GPU 占有率（Occupancy）。

3.4 显存暂存区与工作空间管理 (VRAM Scratchpad & Workspace Management)

核心指向：解决算法中间结果（如脉压后的复数矩阵）的存储问题。严禁在热路径上调用 cudaMalloc。设计 “显存竞技场 (VRAM Arena)” 或 “栈式分配器 (Stack Allocator)”，为每个流预分配固定的临时工作区（Scratchpad）。利用内存复用技术（Memory Aliasing），让不同阶段的算法共享同一块物理显存，极大降低显存峰值开销。

3.5 内核启动优化与持久化线程 (Kernel Launch Optimization & Persistent Threads)

核心指向：对抗 PCIe 启动开销（Launch Latency）。针对大量微小算子（如简单的向量加减），引入 “内核融合 (Kernel Fusion)” 策略或 “持久化线程 (Persistent Threads)” 模式（即 GPU 上常驻一个 Loop Kernel，通过轮询标志位执行任务），消除 CPU 频繁下发指令带来的系统调用抖动。

3.6 异构同步机制与完成通知 (Heterogeneous Synchronization & Completion Notification)

核心指向：定义 CPU 如何感知 GPU 计算结束。摒弃高延迟的 cudaStreamSynchronize()（全阻塞），采用 “基于事件的回调 (Event-Based Callback)” 或 “主机轮询标志位 (Host-Polling on Zero-Copy Flag)” 机制。与 2.3.1 的事件总线对接，在计算完成的微秒级内触发下游的 DisplayController。

4. 信号处理业务逻辑流 (Signal Processing Business Logic Flow)

核心指向：定义软件需要实现的“业务链路”。即数据在进入流水线后，需要经过哪些具体的处理节点（Node）以及这些节点的连接顺序和控制逻辑。

5. 实时性能与吞吐量约束 (Real-time Performance & Throughput Constraints)

核心指向：定义系统的“非功能性指标”。包含对处理时延的硬性要求、数据吞吐带宽的限制、以及系统优化的量化目标。

6. 工程架构与可靠性保障 (Engineering Architecture & Reliability Assurance)

核心指向：定义系统的“健壮性”。包含程序的生命周期管理、错误处理机制、日志系统、以及在无人值守情况下的自恢复能力。

33 KiB Raw Permalink Blame History Unescape Escape