第三章 硬件环境准备：CPU选型、内存配置、存储设备与网络硬件
做实时系统性能测试，硬件选型是地基。地基没打好，后面调优再努力也是白搭。我见过太多团队，软件优化做到极致，结果发现瓶颈在硬件上——CPU主频不够、内存延迟太高、磁盘IO卡死。嗯，今天咱们就把这四块硬骨头啃下来。
3.1 CPU选型：主频、核心数、缓存
CPU是实时系统的核心。选型时，三个参数必须盯死：主频、核心数、缓存。
3.1.1 主频：实时任务的硬指标
主频决定了单条指令的执行速度。对于实时系统，尤其是硬实时场景，主频越高越好。为什么？因为实时任务有严格的截止时间，你必须在规定周期内完成计算。
我个人习惯，对于周期在1ms以内的任务，主频至少3.0GHz起步。如果任务周期在100μs以下，建议直接上4.0GHz以上的CPU。
关键点：主频不是唯一指标。IPC（每时钟周期指令数）同样重要。同一主频下，不同架构的CPU性能可能差30%。
我在项目中遇到过，某客户用2.5GHz的CPU跑10kHz控制环路，死活跑不满。换成3.5GHz的同一架构CPU，问题直接解决。说白了，主频就是实时系统的硬通货。
3.1.2 核心数：并行与隔离的博弈
核心数多了，你能做任务隔离。这是实时系统的关键技巧。
我建议：
- 实时任务独占核心：至少留1-2个物理核心给实时任务，禁止操作系统调度其他进程上去
- 非实时任务放其他核心：Linux的cpuset或isolcpus参数可以做到
- 超线程要小心：超线程核心共享执行单元，实时任务建议关闭超线程
你想想看，如果实时任务和普通进程抢CPU缓存，中断延迟可能从几微秒飙升到几十微秒。这谁受得了？
避坑指南：我曾经在8核CPU上跑4个实时任务，以为留4个核心就够了。结果发现操作系统后台进程（比如ksoftirqd）偶尔会跳到实时核心上。后来用isolcpus+CPU亲和性绑定，才彻底解决。
3.1.3 缓存：L1/L2/L3的命中率决定生死
缓存命中率直接影响实时任务的确定性。L1缓存访问延迟约1ns，L3缓存约10-20ns，内存访问约100ns。你想想看，如果频繁缓存未命中，实时任务的执行时间会剧烈抖动。
我一般这样选：
- L1缓存：越大越好，至少32KB指令缓存+32KB数据缓存
- L2缓存：每核心至少256KB，512KB更佳
- L3缓存：共享缓存，至少8MB起步。如果多个实时任务共享数据，L3大能减少跨核心通信延迟
举个例子，我调过一个视觉实时系统，图像处理任务频繁访问大数组。L3缓存从8MB换成16MB后，任务执行时间抖动从±15%降到±3%。
3.2 内存配置：DDR类型、时序、容量
内存是实时系统的另一个关键瓶颈。选错了，CPU再强也白搭。
3.2.1 DDR类型：带宽与延迟的取舍
目前主流是DDR4和DDR5。DDR5带宽更高，但延迟也略高。对于实时系统，我更看重延迟而非带宽。
| 参数 | DDR4-3200 | DDR5-4800 | DDR5-5600 |
|---|---|---|---|
| 带宽（GB/s） | 25.6 | 38.4 | 44.8 |
| 典型延迟（ns） | ~70 | ~85 | ~80 |
| 实时推荐 | ★★★★★ | ★★★☆☆ | ★★★★☆ |
我个人习惯，如果实时任务对内存带宽要求不高（比如控制环路、信号处理），优先选DDR4，延迟更低。如果涉及大量数据搬运（比如雷达信号处理），才考虑DDR5。
3.2.2 时序：CL值越低越好
内存时序（CL-tRCD-tRP-tRAS）直接影响访问延迟。CL值是最关键的，它代表列地址选通延迟。
我建议：
- CL值：越低越好。DDR4常见CL16-CL22，DDR5常见CL30-CL40
- tRCD：行地址到列地址延迟，同样越低越好
- tRP：行预充电时间，影响随机访问性能
小技巧：买内存时，别只看频率。同一频率下，CL值差2，延迟可能差5-8ns。我习惯在BIOS里手动压时序，但要注意稳定性测试。
3.2.3 容量：够用就好，别贪多
实时系统对内存容量的要求，和普通服务器不一样。容量太大反而可能增加延迟——因为内存控制器需要管理更多rank。
我一般这样算：
- 实时任务本身：代码+数据，通常几百MB到几GB
- 操作系统+驱动：预留2-4GB
- 缓冲区：根据最大数据量，再留50%余量
举个例子，一个工业控制实时系统，任务数据量约500MB，我配了8GB内存。够用，而且延迟比配32GB低约10%。
注意：我曾经在64GB内存的机器上跑实时任务，发现内存访问延迟比8GB机器高15%。原因是内存控制器需要管理更多内存颗粒。后来我改用小容量高频内存，问题解决。
3.3 存储设备：NVMe vs SATA、RAID配置
存储设备影响实时系统的数据加载和日志写入速度。选错了，IO延迟会让你怀疑人生。
3.3.1 NVMe vs SATA：延迟差距巨大
NVMe走PCIe总线，延迟通常在10-50μs。SATA走AHCI协议，延迟在100-500μs。对于实时系统，这个差距是致命的。
我建议：
- 实时数据存储：必须用NVMe SSD，延迟低且稳定
- 日志/归档：可以用SATA SSD，成本低
- 机械硬盘：别用在实时系统里，延迟动不动几十毫秒
你想想看，如果实时任务需要每1ms写一次日志，用SATA SSD可能卡住几十次。NVMe SSD基本无感。
3.3.2 RAID配置：性能与冗余的平衡
RAID能提高可靠性，但也会增加延迟。对于实时系统，我一般这样选：
| RAID级别 | 特点 | 实时推荐 |
|---|---|---|
| RAID 0 | 条带化，性能最高，无冗余 | ★★★★☆（可接受） |
| RAID 1 | 镜像，写性能略降，读性能好 | ★★★★★（推荐） |
| RAID 5 | 奇偶校验，写性能差，有冗余 | ★★☆☆☆（不推荐） |
| RAID 10 | 条带+镜像，性能与冗余兼顾 | ★★★★★（推荐） |
我个人习惯，实时系统用RAID 1或RAID 10。RAID 5的写惩罚（每次写需要读-改-写）会导致延迟抖动，不适合实时场景。
关键点：RAID卡本身也有延迟。如果对延迟极度敏感，可以考虑用软件RAID（如Linux mdadm），但要注意CPU占用。
3.4 网络硬件：网卡型号、交换机延迟
分布式实时系统离不开网络。网络延迟是实时通信的硬约束。
3.4.1 网卡型号：从千兆到100G
网卡选型看三点：带宽、延迟、卸载功能。
我建议：
- 千兆网卡：延迟约100-200μs，适合非实时控制
- 万兆网卡：延迟约10-30μs，适合中等实时需求
- 25G/40G/100G网卡：延迟可低至1-5μs，适合硬实时
网卡卸载功能也很重要。比如TCP卸载引擎（TOE）、RDMA（远程直接内存访问）。RDMA能绕过操作系统协议栈，延迟从几十微秒降到几微秒。
小技巧：我习惯用Intel或Mellanox的网卡，驱动成熟，延迟稳定。有些廉价网卡在压力下延迟会剧烈抖动，千万别用在实时系统里。
3.4.2 交换机延迟：端到端的关键
交换机延迟是网络延迟的重要组成部分。普通交换机延迟在10-50μs，数据中心级交换机可低至1-5μs。
我一般这样选：
- 非实时系统：普通千兆交换机，延迟50μs以内可接受
- 软实时系统：万兆交换机，延迟10μs以内
- 硬实时系统：专用实时交换机（如支持TSN的），延迟1μs以内
你想想看，如果实时任务需要跨节点通信，交换机延迟加上网卡延迟，可能超过任务周期的10%。这时候就必须用低延迟交换机。
避坑指南：我曾经在项目中用普通千兆交换机跑实时控制网络，结果发现偶尔出现几十毫秒的延迟尖峰。后来换成支持802.1Qbv（时间感知整形）的TSN交换机，延迟稳定在2μs以内。嗯，交换机选型不能省。
3.5 硬件选型总结
说了这么多，其实核心就一句话：实时系统的硬件选型，延迟比带宽更重要，确定性比峰值性能更重要。
我习惯在选型前，先做一个小测试：用cyclictest或类似工具，测量当前硬件的中断延迟和调度延迟。如果抖动超过任务周期的10%，就得换硬件。
最后，别忘了做压力测试。我曾经在实验室里跑得好好的硬件，一上生产环境就出问题。原因？散热不够，CPU降频了。嗯，硬件选型是个系统工程，别只看参数。
公众号:蓝海资料掘金营，微信deep3321