前阵子我把某开源自动驾驶平台的 Cyber RT 调度框架从它们那套专用运行环境里搬到了一台普通的 Ubuntu 服务器上，折腾了几个晚上，中间踩了无数坑，最后总算把端到端调度延迟从毫秒级压到了几百微秒。整个过程让我对“实时性”这件事的理解又深了一层。这篇文章把我这一路的移植过程、调度原理、实时性测试方法和踩坑清单都整理出来，给做自动驾驶系统研究、底层调度开发，或者单纯想把 Cyber RT 跑在自己 Linux 设备上的朋友做个参考。
Cyber RT 并不是一个完整的自动驾驶系统，它是车端底层的一层实时计算框架，可以理解为自动驾驶系统的“调度中枢 + 通信神经网络”。它用了一套和 ROS 完全不同的设计思路：用轻量协程替代传统线程，用共享内存减少通信拷贝，用统一的消息总线连接所有传感器、感知、规划、控制模块。这套方案在自动驾驶这种“高吞吐、多周期、强实时”的场景下，确实比传统通用框架更适合。文章会覆盖它的核心概念、在通用 Linux 上的依赖准备、源码编译、调度参数配置、实时性测试与调优，最后是一份我能想到的问题排查速查表。
1. Cyber RT 到底是什么，自动驾驶为什么需要它
1.1 从车端任务特征看实时调度框架的定位
先聊一个本质问题：为什么自动驾驶需要一个专门的调度框架？把一堆任务用系统自带线程跑起来不行吗？
我举一个实际场景你就明白了。一辆自动驾驶车上有激光雷达、相机、毫米波雷达、IMU 这些传感器。激光雷达点云处理频率通常是 10Hz，相机感知跑深度学习模型，可能是 30Hz 或者 50Hz，规划控制模块往往要求更高的周期稳定性。每个模块都有严格的截止时间（deadline），超过这个时间要么数据作废，要么控制指令晚发导致危险。
如果每个模块都自己开几个线程，那系统调度器对你就完全是黑盒。你不知道持有锁的任务什么时候被抢占，不知道一个高优先级线程会被多少低优先级线程拖住，更无法预估一次上下文切换带来的抖动。传统操作系统调度器优先保证“所有任务公平”，而这种“公平”恰恰是自动驾驶最不需要的——我们需要的是关键任务要么立刻执行，要么被明确规定什么时候执行。
所以 Cyber RT 这一类框架做的事情，本质上就是三件：
- 把任务建模成带优先级的执行单元，交给用户态调度器管理；
- 用协程代替线程，让执行单元的创建和切换代价降低几个数量级；
- 用共享内存实现进程间通信，把消息传递的延迟和拷贝降到最低。
“AI × 实时 Linux”这个组合的含义也在这里：AI 模型负责“看懂路”，实时调度框架负责“在正确的时间点把模型推理结果送到规划控制模块，让指令按时发出去”。两者缺一不可，缺了实时性，AI 再准也不敢动方向盘。
1.2 协程、调度器、消息总线：三个核心抽象
Cyber RT 和传统 ROS 最大的区别，是它设计了一套非常鲜明的计算模型。这套模型由三个核心抽象组成。
Component（组件）：每一个可执行单元都被封装成一个 Component，它本质上是一个协程对象。协程这个东西，你可以把它理解成“用户态自己控制的轻量级执行流”。和线程比，协程的创建开销极小，切换不经过内核，不需要保存一大堆寄存器上下文。我用一个类比：线程像每个人开一桌菜，每换一桌都要重新点菜、结账、收桌子；协程像一个传菜员在同一张桌上端不同的菜，翻台成本低得多。
Scheduler（调度器）：所有 Component 并不会直接在物理 CPU 上运行，而是被交到一个用户态调度器手里。调度器把任务排队，分发给底层一个固定数量的 worker 协程池，worker 再绑定到具体的 CPU 核上执行。每个任务可以设置优先级，调度器会按照优先级决定把任务先分发给哪个 worker。
Writer/Reader（消息总线）：模块之间通过 Writer 和 Reader 发布订阅消息。进程内通信走共享内存，跨进程通信也走共享内存，统一的 API 让上层开发者完全不用关心消息是去了同进程还是别的进程。这一点非常关键，因为所有模块都可以在一个二进制环境里跑，通信路径被大大缩短。
这套设计还有一个非常厉害的地方：所有组件乃至通信，都挂在一张 DAG 图（有向无环图）里。系统初始化时就把这张图画好，消息的上下游关系、依赖顺序全部确定，调度起来非常“有数”。
1.3 实时性不等于“快”，它等于“可预测”
我在移植前犯了一个新手错误：以为实时性就是“更快”。实际上，实时系统的核心指标是确定性（determinism）——不是平均延迟多低，而是最坏情况下延迟多高，以及延迟的波动范围有多大。
你做一个在线支付系统，平均延迟 100ms，偶尔一次 3 秒，用户骂一句就完了。自动驾驶里，传感器数据来了，感知模块推理需要 80ms，规划模块必须在 20ms 内接上，如果你这一轮突然 200ms 才完成，下游模块就断档了。一次断档就可能导致一个异常制动或误判。
所以衡量实时性，我建议你重点看这几个指标，而不是盯着平均延迟看：
| 指标 | 含义 | 为什么重要 |
|---|---|---|
| p50 | 50% 请求延迟都在该值以下 | 常规负载的表现 |
| p99 | 99% 请求延迟都在该值以下 | 长尾表现，反映偶发性卡顿 |
| max | 最坏一次延迟 | 截止时间设计依据 |
| jitter（抖动） | 延迟标准差或 p99 与 p50 的差距 | 判断系统是否“稳定可预测” |
Cyber RT 默认采用的是一种协作式调度策略，协程之间并不会像线程那样被内核强占。好处是调度自己说了算、开销低，但坏处也埋在这里：如果一个长任务跑着不主动让出执行权，后面排队的高优先级任务也得等它跑完。这个问题在实时性调优时特别头疼，我在第 4 章会专门讲怎么处理。
2. 移植前的准备：通用 Linux 上需要解决的四类差异
2.1 “移植”到底移的是什么
Cyber RT 原本运行在车端定制 Linux 环境里，那套环境在编译时带了很多特定工具链、内核配置和预装依赖。到了普通 Ubuntu 或 Debian 上，你需要处理四类差异：
- 内核差异：车端镜像通常开了各种实时抢占选项、调度器扩展、cgroup 配置，通用发行版的内核默认值偏保守；
- 依赖库版本差异：Cyber RT 构建时利用了系统里某些特定版本的 protobuf、absl、gflags、glog，普通源的版本可能偏老或偏新导致编译失败；
- 共享内存与资源限制：进程间通信依赖 /dev/shm，通用 Linux 上默认大小、权限都可能不满足；
- 调度器配置缺失：Cyber RT 运行并不强依赖特殊内核，但你要用的实时特性，比如 CPU 隔离、RT 优先级，需要你自己去内核 cmdline 和用户态里配置。
所以在动手前，先把环境评估做完，不要上来就敲 cmake。
2.2 硬件与内核选型建议
先说硬件。建议不要拿虚拟机做实时性验证，虚拟化层本身会引入严重的调度抖动。我自己测试过，同样的代码在物理机上延迟抖动是几十微秒，在虚拟机里直接飙到几毫秒。想要做正经实时性评估，找一台至少 4 核心的物理 Linux 机器，工控机、普通台式机都可以。
内核方面，如果你只是想“能跑起来、先熟悉框架”，默认发行版内核完全够用。但如果你想验证自动驾驶场景下的实时性，至少要掌握两个东西：
- 内核是否开启了高精度定时器和抢占式调度；
- 是否可以在内核启动参数里加
isolcpus隔离出专用核。
我个人的做法是分两步：先拿默认内核把功能跑通，再换实时内核做优化对比。不建议一开始就上 PREEMPT_RT 补丁，否则编译、驱动、显卡这些杂七杂八的问题会把你的注意力全带走。等框架跑通了，再切换实时内核做对照实验。
2.3 依赖清单和版本锁定
Cyber RT 的依赖挺多，但都不难搞。我在 Ubuntu 上整理出的核心依赖如下：
| 依赖 | 作用 | 版本建议 |
|---|---|---|
| protobuf | 消息序列化 | 3.x 早期版本即可，不需要最新 |
| absl（Abseil） | 基础库、时间、字符串 | 官方最新稳定版 |
| gflags | 命令行参数解析 | 2.2.2 以上 |
| glog | 日志库 | 0.4.0 以上 |
| eigen | 矩阵运算（算法模块用） | 3.3.x |
| yaml-cpp | 配置文件解析 | 0.6.x |
| fastrtps / iceoryx（可选） | 跨机通信中间件 | 按需 |
有一件事我必须强调：版本务必锁定。Cyber RT 编译的时候对 protobuf 的版本很敏感，如果系统里装了 protobuf 新版本，可能直接出现 API 不匹配导致编译错误。我建议在一条干净的环境变量里用一个固定的源码安装目录，不要用 apt 源里的最新版本。apt 默认装的版本很可能就是“能装上但编译不过”的版本。
2.4 被大多数人遗忘的 /dev/shm
这是我在第一次运行时踩到的一个隐蔽问题。Cyber RT 的所有共享内存通信都依赖/dev/shm。Linux 默认把/dev/shm挂载为 tmpfs，大小通常是物理内存的一半。在车端专用系统里，这个目录往往被专门调大过。
如果你在一个内存很小的环境下跑，或者在容器里跑，一旦分配共享内存对象失败，Cyber RT 不会直接报“shm 不足”，而是报各种奇怪的段错误或者消息丢失。排查到后来才发现是共享内存不够。
按经验，建议给/dev/shm分配至少主机内存的 1/4 到 1/2。可以通过临时重挂载验证：
sudo mount -o remount,size=8G /dev/shm如果这样设置之后问题消失，说明就是 shm 容量的问题，再去修改/etc/fstab固化配置。
3. 移植实操：从源码编译到第一个通信示例
3.1 源码获取与分支选择
源码直接从官方代码仓拉取即可，不要用 master 分支跑生产环境开发。我一开始图省事直接用了 master，结果某个子模块频繁变动，编译到一半就开始报各种“依赖版本不一致”。后来老老实实切换到稳定发布分支，整个世界清净了。
签出源码之后，先花十分钟把根目录的 README 和 CMake 配置浏览一遍，重点看两个地方：
- 是否有
CYBER_INSTALL_PREFIX这类自定义安装路径的变量； - 编译选项里有没有开关默认打开了某些你不需要的功能（比如加密通信、可视化工具）。
这两个信息决定了你后续会不会被“莫名其妙的多语言依赖”折腾疯。
3.2 依赖环境准备脚本
我不喜欢把环境配置全写在博客里让读者一遍遍试，直接给一段我验证过的脚本思路。你可以按下面这个流程执行：
# 安装系统基础依赖 sudo apt update sudo apt install -y build-essential cmake git libssl-dev \ libncurses5-dev libyaml-cpp-dev libeigen3-dev # protobuf 建议源码安装并固定版本 git clone -b v3.14.0 --depth 1 https://github.com/protocolbuffers/protobuf.git cd protobuf && mkdir build && cd build cmake .. -DCMAKE_BUILD_TYPE=Release -Dprotobuf_BUILD_TESTS=OFF make -j$(nproc) && sudo make install sudo ldconfigprotobuf 单独用源码装，是为了避免和系统里预装的老版本相互污染。装完 protobuf 之后，再装 abseil、gflags、glog 这些，推荐用 vcpkg 或者直接源码装，都可以。我个人习惯是尽量用 vcpkg，省事且好管理版本。如果你不太想引入额外工具链，源码装也没问题，只要版本对就行。
3.3 编译 Cyber RT 本体
源码和依赖就绪后，Cyber RT 本体编译其实并不复杂：
mkdir -p /opt/cyber/build cd /opt/cyber/build cmake .. -DCMAKE_BUILD_TYPE=Release make -j$(nproc)有几个细节我提醒一下。
第一，内存建议至少 16GB，并行编译时内存吃得很凶，我 8GB 的机器卡到几乎无响应。如果内存小，把-j$(nproc)改成-j4甚至-j2。
第二，编译完之后一定要看一眼生成的setup.bash或者cyber_env.sh，后面一启动所有工具都要 source 这个环境。不要试着直接运行二进制，环境变量不全的时候，日志、模块发现、共享内存全部会出问题。
第三，编译日志里如果看到一些功能模块因为缺少可选依赖被跳过，不用担心，核心调度和通信模块没被跳掉就行。那些可选模块对应的是可视化工具之类，不影响运行。
3.4 跑通第一个进程通信：Talker 与 Listener
Cyber RT 跑起来的感觉和 ROS 很像，但细节完全不同。我先写了一个最简单的发布订阅对：一个 Talker 组件周期性发消息，一个 Listener 组件接收消息并打印。
在 Cyber RT 里写一个组件，核心代码其实就那么几行，有一点和 ROS 很不像——组件必须用注册宏暴露给框架。我一开始没写注册宏，组件编译都过了，但启动后日志里根本没有这个组件。排查了半天，最后发现是宏没写。
完整代码这里不贴太长，核心结构是这样的：
#include "cyber/cyber.h" #include "cyber/examples/proto/examples.pb.h" using apollo::cyber::examples::proto::Chatter; class Talker : public apollo::cyber::Component<Chatter> { public: bool Init() override { writer_ = node_->CreateWriter<Chatter>("/chatter"); return true; } bool Proc(const std::shared_ptr<Chatter>& msg) override { // do something } }; CYBER_REGISTER_COMPONENT(Talker)Cyber RT 的消息类型不一定要继承特定基类，而是用proto::Chatter这种 protobuf 消息。注册宏会把类信息写入一个全局表，运行时框架才能找到它。
启动方式也别用直接跑二进制的方式，Cyber RT 提供了一套自己的控制命令：
source cyber/setup.bash cyber_launch start cyber/examples/talker.launch cyber_launch start cyber/examples/listener.launch一旦能看到 Listener 周期性打印消息，说明到这一步“移植”其实已经成功了一大半。功能通了，剩下的全是实时性调优的活。
3.5 掌握调度器配置文件 cyber_sched.conf
Cyber RT 的调度策略，全部体现在一个配置文件里，一般在cyber/conf/cyber_sched.conf。这个文件是实时性调优的核心抓手。
我贴一份常见的配置结构，并解释每个字段实际影响什么：
scheduler_conf { policy: "classic" process_level: 0 threads: [ { name: "main_worker" affinity: "0-1" cpuset: "0-1" policy: "SCHED_FIFO" prio: 50 }, { name: "perception_worker" affinity: "2-3" cpuset: "2-3" policy: "SCHED_FIFO" prio: 60 } ] classic_conf { groups: [ { name: "default_group" processor_num: 4 affinity: "0-3" tasks: [ { name: "/perception" processor: 2 prio: 60 } ] } ] } }简单拆解一下：
policy：调度策略。classic是 Cyber RT 自己实现的协作式调度器，也是默认选项；threads：底层 worker 线程。affinity和cpuset是线程的 CPU 亲和性，policy和prio是线程自身持有的 Linux 调度策略和优先级；classic_conf.groups：任务组。一个组管理一组协程任务，processor_num是这个组可用的逻辑核数；tasks：把具体任务指定到某个processor（逻辑核编号）上，并给一个协程优先级prio。
这里有一个重点：Cyber RT 的协程优先级和 Linux 线程优先级是两套体系。协程优先级是调度器内部排序用的，线程优先级是内核抢占用的。调优时两层都要配，只调一层往往没有效果。
4. 实时性分析：测什么、怎么调、数据怎么看
4.1 端到端延迟的正确测量方法
很多人跑通通信示例之后就宣布“移植完成”，但这只是开始。你要证明这套系统在通用 Linux 上实时性达标，必须能量化测量。
Cyber RT 官方源码里带了一些性能测试工具，但我不建议直接依赖它们，因为那些基准工具大多测试的是吞吐量，而不是端到端延迟。我用的是最土但最可靠的办法——自己在代码里打时间戳。
思路很简单：
- 发送端在发送前调用
clock_gettime(CLOCK_MONOTONIC, &ts)取一个时间，把时间戳写进消息； - 接收端收到消息后再取一个时间，两个时间相减就是端到端延迟；
- 连续跑几万条消息，把延迟数据存下来，离线统计 p50、p99、p95、max。
为什么要用CLOCK_MONOTONIC而不是gettimeofday？因为gettimeofday返回的是墙上时钟，一旦系统时间被 NTP 校准或人工调整，数据就全乱了。单调时钟只递增，不受系统时间跳变影响。
还有一点非常关键：测试时不要在回调函数里写日志。我在第一次测时天真地用了 LOG 打印每条消息延迟，结果日志 IO 本身就把延迟拉高了上百微秒。正确的做法是把原始计数值暂存在一个环形缓冲区里，等跑完测试再落盘统一分析。
下面是我测试程序的伪代码，供你参考：
void SendLoop() { while (running) { struct timespec ts; clock_gettime(CLOCK_MONOTONIC, &ts); msg.set_timestamp(ts.tv_sec * 1e9 + ts.tv_nsec); writer_->Write(msg); } } void RecvCallback(const std::shared_ptr<Msg>& msg) { struct timespec ts; clock_gettime(CLOCK_MONOTONIC, &ts); uint64_t now = ts.tv_sec * 1e9 + ts.tv_nsec; uint64_t delay_us = (now - msg.timestamp()) / 1000; // us buffer.push_back(delay_us); }离线统计时，把数据排序，p50就是第 50% 个位置的值，p99就是第 99% 个位置的值，max就是最后一个值。我强烈建议测试次数不低于 10 万次，否则偶发尖峰根本暴露不出来。
4.2 CPU 隔离：一次见效最大的一招
如果只让我推荐一个调优手段，我首推 CPU 隔离。这是我从毫秒级压到几百微秒最关键的一步。
Linux 是一个通用操作系统，CPU 上除了你的任务，还有各种内核线程、中断、定时器。即使你的任务优先级最高，中断也会抢占你。CPU 隔离做的事情是：告诉内核“有几个核永远不要给我放用户任务”，然后你把 Cyber RT 的所有 worker 绑到这几个隔离核上，系统里其他乱七八糟的事情全部扔到另外的核上。
具体操作分三步：
第一步，在内核启动参数里加isolcpus。修改 GRUB 配置：
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash isolcpus=2,3 nohz_full=2,3 rcu_nocbs=2,3"isolcpus隔离 CPU 后，内核调度器默认不会把普通用户进程放到 2、3 号核上。nohz_full关闭这两个核的周期时钟中断，rcu_nocbs把 RCU 回调挪到别的核。这三件套配合使用，效果最好。
第二步，在 Cyber RT 调度器配置里，把 worker 线程绑定到隔离核，并把 Linux 线程优先级设置为SCHED_FIFO。我在 3.5 节给出的配置里写得很清楚，就是那组affinity、cpuset、policy、prio字段。
第三步，关掉irqbalance服务，并把网卡和定时器中断手动绑定到非隔离核。这一步往往被忽略，但它同样关键。中断是不讲道理的，它随时可能占用你的隔离核执行中断处理函数。我是在/proc/irq/*/smp_affinity里手动指定 CPU 掩码，把所有中断都绑到 0 和 1 号核，给 2、3 号核一个绝对干净的运行环境。
4.3 长尾延迟的三级排查清单
做完 CPU 隔离后，延迟曲线通常已经非常漂亮，但偶尔还会冒出几个几十毫秒的尖峰。这种长尾问题，我总结了三级排查顺序：
第一级：看看有没有核在休眠。CPU 空闲时会自动进入 C-State 省电模式，退出休眠需要几十微秒甚至更多。如果隔离核在上一轮任务结束后空闲了，下一轮任务来了它要“起床”，延迟就上去了。解决办法是在 BIOS 里关闭 C-State，或者用cpupower idle-set -d 1禁掉浅睡眠之外的所有状态。
第二级：看看中断是否还在打扰隔离核。我之前遇到过一次性能回退，排查半天发现是某个 USB 设备的中断跑到了隔离核上。把 USB 控制器整个绑到别的亲和域，问题立刻消失。
第三级：看看调度器内部有没有长任务阻塞。协程调度是协作式的，一个感知训练任务如果跑几百毫秒不主动让出，后面的规划任务就得排队。这种问题的排查要看 Cyber RT 日志里有没有出现“task timeout”之类的警告。如果确认存在，就要把长任务拆碎，或者在调度策略上做抢占开关。
4.4 一组实测数据对比
我在一台 4 核工控机上做了三次测试，分别对应三个阶段的配置：
| 配置 | 平均延迟 | p95 | p99 | 最大延迟 |
|---|---|---|---|---|
| 默认内核 + 普通线程发布 | 2.3ms | 8ms | 15ms | 47ms |
| 默认内核 + Cyber RT 协程 | 420us | 1.6ms | 3.1ms | 21ms |
| 实时内核 + CPU 隔离 + RT 优先级 | 180us | 340us | 520us | 1.2ms |
从数据里可以明确看出三个结论：
- Cyber RT 协程模型相比普通线程模型，平均延迟降低了 80%，这就是用户态调度的优势；
- 平均延迟降低并不代表实时性达标，p99 和 max 依然在毫秒级，说明协作式调度有不确定性；
- 加入 CPU 隔离和 RT 优先级后，p99 从 3.1ms 降到 520us，这才是真正“实时化”的一步。长尾被明显压低，系统变得可预测了。
我反复强调 p99，是因为自动驾驶安全设计完全依赖最坏情况分析，你设计控制周期时不能按平均值来，必须按可能出现的最大延迟加余量来定。如果 max 是 1.2ms，那控制周期至少应该留 3~4ms 余量，才能保证不会断档。
5. 常见问题与排查技巧实录
5.1 编译期问题速查
我移植过程中遇到的编译问题，整理成下面这个表：
| 问题现象 | 根本原因 | 解决办法 |
|---|---|---|
protobuf 的.pb.h找不到 | 版本冲突或未安装 | protobuf 源码固定版本后重新安装，确认/usr/local/include有文件 |
no matching function for call to | absl 或 glog 版本 API 变化 | 锁死依赖版本，不要追新 |
cmake 找不到gflags | 缺 dev 包或者找错路径 | export CMAKE_PREFIX_PATH指定安装目录 |
| 链接时 undefined 符号 | 编译顺序或库顺序问题 | 在 CMake 里检查target_link_libraries里库的先后顺序 |
| 内存不足编译 OOM | 并行度太高 | 压缩make -j数量，加 swap |
有一个经验可以分享：一旦编译报错，第一反应不是去改代码，而是去查依赖版本是否对齐。我在 Cyber RT 上踩过的 80% 编译错误，最后都是依赖版本问题，改代码改半天其实方向就错了。
5.2 运行期问题速查
编译过了，运行期还有一批更隐蔽的坑：
| 问题现象 | 根本原因 | 解决办法 |
|---|---|---|
| 启动后日志一切正常但组件不触发 | 注册宏漏写或消息类型不匹配 | 检查CYBER_REGISTER_COMPONENT，确认 topic 名字一致 |
| CPU 占用一直为 0 | 组件没有实际任务，或者调度器没把任务绑进去 | 查看cyber_dashboard或日志中的 task 注册信息 |
| 共享内存段创建失败 | /dev/shm空间不足或权限不对 | 检查挂载容量，确认用户有写权限 |
| 消息延迟突然变成几百毫秒 | 有长任务占用了 worker | 检查调度器配置，拆分长任务，考虑加 worker 数量 |
| 进程启动直接 coredump | 版本不匹配或依赖环境变量没 source | 先source setup.bash，再检查依赖库版本 |
我印象最深的一个案例是：组件明明注册了，日志里也出现了组件初始化成功，但Proc回调就是一次都不触发。我去查 topic 名字，两边完全一致，查了个把小时才发现是两个进程跑的setup.bash环境变量版本不同，其中一个进程加载了不同路径的动态库，导致消息协议版本不匹配，消息直接被内部过滤掉了。这种问题对新手来说几乎就是天书，建议你在多个进程上跑之前，先统一 source 同一个环境脚本。
5.3 实时性不达标时，按这个顺序排查
如果实测延迟始终压不下去，我给你一个固定的排查顺序，每次按这个顺序走，能省大量时间：
第一步，先确认硬件层面没有省电干扰。关掉 BIOS 里的 C-State、SpeedStep，用cpupower frequency-set -g performance把频率锁定。
第二步，确认隔离核真的干净。用htop看隔离核上有没有内核线程活动，如果有，把rcu_nocbs、nohz_full这些参数再检查一遍。
第三步，确认消息传递路径没有走网络。如果两个组件不在同一进程，通信会不会走了环回网络而不是共享内存？ss -t或者perf trace看看有没有 socket 调用。走一次网络，延迟立刻多几十微秒。
第四步，用perf sched latency查内核调度延迟。如果内核调度延迟本身很高，说明你的 RT 优先级配置或者线程绑定没生效。
第五步，如果延迟尖峰还是周期性出现，查一下有没有周期性的后台任务，比如日志轮转、监控脚本定时触发。我排查过一起问题，最后发现是某监控软件每 10 秒跑一次负载检查，把 CPU 占用拉满导致延迟尖峰。
这套排查顺序帮我在很多台机器上快速定位问题，你也可以根据自己的环境做适当调整。
最后分享两个我自己体会最深的点
第一个体会是：移植 Cyber RT 到通用 Linux，真正困难的地方从来不是“能编译、能跑”，而是“实时性经得起测试”。我跑通功能只花了一个晚上，但把延迟曲线从乱七八糟压到可预测，花了整整两个晚上。所以我的建议是，每一步改动都要留下量化数据，调优前后对比，不要靠感觉判断。
第二个体会是，如果只是做研究验证，先完全用默认配置跑通，再一步一步加约束，不要一上来就上全套实时内核加 CPU 隔离。每加一个变量，问题排查难度就翻一倍。我后来换实时内核时又踩了驱动兼容的坑，最后发现默认内核加上 CPU 隔离和 RT 优先级，在很多场景下延迟已经能到几百微秒级别，完全够用。
最后再给你一个小技巧：调优时可以用flamegraph抓一下 CPU 热点，很多看似玄学的延迟问题，其实都是某个不显眼的后台线程在抢 CPU。把火焰图生成一次，比盲目改参数高效得多。Cyber RT 这套框架本身的设计质量很高，在通用 Linux 上完全可以发挥出接近专用平台的实时能力，只要你有耐心把每一层配置调整到位。
