93 lines
4.2 KiB
Markdown
93 lines
4.2 KiB
Markdown
|
---
|
|||
|
|
tags:
|
|||
|
|
date created: 星期三, 十一月 19日 2025, 4:10:16 下午
|
|||
|
|
date modified: 星期三, 十一月 19日 2025, 4:10:27 下午
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# 1.1.6 时间同步与系统关键疑点深挖 (Time Synchronization & Deep-Dive)
|
|||
|
|
|
|||
|
|
**1. 时间同步服务健康度 (Time Synchronization Health)**
|
|||
|
|
|
|||
|
|
- **关键性**：P1
|
|||
|
|
- **信息解析**：
|
|||
|
|
- **时钟源 (Clocksource)**：系统正确使用了 `arch_sys_counter`，这是 ARM64 架构下的高精度硬件计数器，基准可靠。
|
|||
|
|
- **同步偏差 (Offset)**：当前与 NTP 服务器的偏差约为 **6ms - 7ms** (`-6106us` \~ `+7072us`)。对于毫秒级雷达应用尚可接受，但若涉及多站协同或相控阵微秒级同步，此偏差**过大**，建议改用 PTP (Precision Time Protocol) 或连接本地高精度 GPS 时钟源。
|
|||
|
|
- **频率漂移 (Frequency Skew)**：`89.988 ppm`，表明本地晶振走得稍快，但在 Chrony 修正范围内。
|
|||
|
|
- 探测命令与结果：
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
|
|||
|
|
arch_sys_counter
|
|||
|
|
|
|||
|
|
chronyc sources -v
|
|||
|
|
^* 113.141.164.38 … -6106us[-6155us] +/- 35ms
|
|||
|
|
^+ 223.4.249.80 … +7072us[+7072us] +/- 34ms
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**2. GPU 链路降级确认 (GPU Link Downgrade Verification)**
|
|||
|
|
|
|||
|
|
- **关键性**：P0 (Critical)
|
|||
|
|
- **信息解析**：
|
|||
|
|
- **链路状态**：明确确证 **GPU 运行在 PCIe 4.0 x8 模式** (`Speed 16GT/s (ok), Width x8 (downgraded)`)。
|
|||
|
|
- **根本原因**：物理插槽可能仅为 `x8` 电气连接，或者 GPU 金手指接触不良，亦或是主板 BIOS 设置了通道拆分（Bifurcation）。
|
|||
|
|
- **后果**：理论带宽上限从 32GB/s (x16) 降至 16GB/s (x8)。若雷达回波数据量巨大（如多通道宽带信号），这将成为数据传输的硬瓶颈。
|
|||
|
|
- 探测命令与结果：
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
lspci -s 0001:01:00.0 -vv | grep -E "LnkCap:|LnkSta:"
|
|||
|
|
LnkCap: Port #0, Speed 16GT/s, Width x16 …
|
|||
|
|
LnkSta: Speed 16GT/s (ok), Width x8 (downgraded)
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**3. 系统性能配置档 (System Performance Profile)**
|
|||
|
|
|
|||
|
|
- **关键性**：P1
|
|||
|
|
- **信息解析**：
|
|||
|
|
- **激活策略**：`throughput-performance` 已激活。
|
|||
|
|
- **缺陷**：尽管使用了高性能配置，但前序审计发现 `numa_balancing=1` 依然开启。这说明 Kylin 默认的 `throughput-performance` 策略并未激进地关闭 NUMA 自动均衡，后续需创建自定义 Tuned Profile 来覆盖此项。
|
|||
|
|
- 探测命令与结果：
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
tuned-adm active
|
|||
|
|
Current active profile: throughput-performance
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**4. 透明大页整理策略 (THP Defrag Policy)**
|
|||
|
|
|
|||
|
|
- **关键性**：P2
|
|||
|
|
- **信息解析**：
|
|||
|
|
- **当前状态**：`[madvise]`。
|
|||
|
|
- **评价**：这是一个**相对安全**的设置。意味着内核仅在应用程序通过 `madvise(MADV_HUGEPAGE)` 显式请求时才整理大页，避免了全局强制整理带来的随机延迟。与 1.1.2 节建议一致。
|
|||
|
|
- 探测命令与结果：
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
cat /sys/kernel/mm/transparent_hugepage/defrag
|
|||
|
|
always defer defer+madvise [madvise] never
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**5. 网络接口映射概览 (Network Interface Mapping)**
|
|||
|
|
|
|||
|
|
- **关键性**：P2
|
|||
|
|
- **信息解析**：
|
|||
|
|
- **接口列表**：
|
|||
|
|
- `ens4f0` - `ens4f3`：这极有可能是那是那块**带宽受限**的网迅四口千兆/万兆网卡。目前 `ens4f1` 为 `UP` 状态。
|
|||
|
|
- `ens2f7u1u2`：USB 网卡或转接设备，当前处于 `UP` 状态。
|
|||
|
|
- **下一步行动**：后续网络调优时，需重点针对 `ens4f*` 系列接口使用 `ethtool` 检查 Ring Buffer 大小和硬中断聚合（Coalesce）设置。
|
|||
|
|
- 探测命令与结果：
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
ip -br link show
|
|||
|
|
ens4f0 DOWN …
|
|||
|
|
ens4f1 UP …
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
-----
|
|||
|
|
|
|||
|
|
### 1\. 开发环境与构建生态 - 审计总结
|
|||
|
|
|
|||
|
|
至此，**1.1 操作系统与内核基座** 的深度审计已全部完成。我们已经掌握了这台机器的“体检报告”：
|
|||
|
|
|
|||
|
|
- **底座**：Kylin V10 SP1 (aarch64), Kernel 4.19 (GCC 7.3 构建), **64KB PageSize**。
|
|||
|
|
- **算力**：Feiteng S5000C + Iluvatar 智铠 GPU (PCIe x8 降级运行)。
|
|||
|
|
- **风险**：PageSize 兼容性、GPU 带宽减半、NVMe 中断挤压在 CPU0、系统时钟偏差较大。
|