做双路视觉项目最怕遇到一种情况单独压测每一路的时候帧率、延迟都说得过去一旦两路同时跑主画面就开始“抽风”。检测框一卡一卡的帧间隔有时候能从40毫秒直接冲到300毫秒。看起来是双路并发的问题但根子往往不在摄像头也不在模型而在调度。香橙派RK3588双路视觉方案走到阶段四要搞定的就是这个调度问题具体方案叫QoS严格优先Strict Priority。这个系列前面的内容已经覆盖了环境搭建、yolov5s模型转换、RKNN推理、单路视觉流水线以及方案二主辅架构的搭建。到了阶段四主线任务是把两路视频流的资源竞争管起来让主路像走专用车道一样稳定辅路量力而行。如果你手里已经有香橙派5系列RK3588/RK3588S、已经能把yolov5s在单路跑通这篇教程就是为你准备的。我会把从底层原理到可复现命令的完整链路都讲清楚也会把那些只在实际调试里才能撞上的坑一并交代。1. 阶段四要解决的核心问题两路摄像头抢资源1.1 系列走到这里我们已经有了什么先说清楚阶段四的起点。双路视觉方案二并不是从零开始而是在前面17期的基础上做的最后一次调度改造。已经完成的工作大致有三块第一RK3588平台的系统环境、RKNN Toolkit 2工具链、yolov5s转rknn int8模型这些基础件都齐了。第二单路视觉流水线跑通也就是V4L2采集、RGA缩放、NPU推理、NMS后处理、VPU编码推流这一整套链路在单路情况下能达到稳定帧率。第三方案二的主辅架构已经搭起来了——主路负责核心目标检测业务辅路承担辅助观察类任务两者不再是完全对等的双路并行而是有主次之分的双路协同。阶段三做完之后板子上的双路都已经能出画面、能推理、能推流。当时实测的结果是两路单独跑都很顺但合到一起跑就会出现周期性卡顿。所以阶段四的名字叫“QoS严格优先”本质上就是在已经能跑的双路系统上解决“两路打架”的问题。1.2 单路稳、双路抖并发带来的新问题阶段三的测试数据我记得很清楚。单独跑主路时yolov5s在640x640输入下能稳定跑到30fps左右。单独跑辅路时320x320输入甚至能跑到接近40fps。但当我把两路同时开启结果就很有意思了——两路的平均帧率确实都还在主路大概17fps辅路大概18fps看着挺均衡。可只要看每帧的时间间隔曲线问题就藏不住了。主路的帧间隔并不是稳定的40毫秒、50毫秒那种节奏而是大部分时间在40到60毫秒之间每隔一会儿突然冒出一个200到300毫秒的尖峰。在显示端看就是画面每隔几秒明显顿一下检测框跟着跳。辅路同样存在这种尖峰只是辅路画面本身没那么重要在测试阶段不太容易被注意到。这个问题如果你只看avg fps永远不会被发现。很多人在板卡上做双路视觉报出来的指标都是“平均18帧”但实际上关键业务这一路的稳定性一塌糊涂。阶段四的核心工作就是把这种隐藏的抖动逼出来、压下去。1.3 系统默认调度器为什么解决不了这个问题要理解为什么双路并发会抖成心电图得先明白Linux默认调度器在想什么。RK3588跑的是标准Linux内核默认的CFS完全公平调度器设计目标是“让所有可运行线程公平地分享CPU时间”。这个公平逻辑在普通服务器场景下没问题但在双路视觉这种有关键任务的实时场景下就成了短板。当两路推理线程都处于可运行状态时CFS会尽可能让它们交替占用CPU谁也不会被饿着。结果就是主路的后处理线程和辅路的采集线程挤在一起谁先跑完谁后跑完完全看当时CPU cache、中断、负载的情况每帧的完成时间充满了随机性。放大到整个流水线上主路的帧间隔自然忽长忽短。更麻烦的是双路视觉牵涉的硬件资源不止CPU一个。NPU、RGA、VPU这些硬件单元都有各自的排队和执行时间。当两路任务同时打到某个硬件模块上默认情况下谁都拿不到确定的优先级于是抖动就沿着数据链路一级一级放大。你光靠Linux默认的CFS去跑双路基本是碰运气。2. 双路视觉方案二的资源盘点与调度策略抉择2.1 一条完整的双路数据链路上有哪些关卡在动配置之前我建议先把一条双路数据链路完整地画出来看清楚一帧画面从摄像头出来到最终被消费中间要经过多少个关卡。以我这套RK3588平台为例单路一帧的流程是下面这样的摄像头通过MIPI CSI接口采集原始图像这里走的是V4L2框架涉及DMA buffer的申请和映射。图像进入内存后需要经过RGA硬件做缩放和格式转换主路一般从摄像头原始分辨率缩到640x640或者320x320这个是给NPU输入准备的。缩放完成后把数据递给RKNN推理接口模型在NPU上跑一次前向推理得到一堆原始检测结果。然后是NMS这类后处理把重复的框合并掉这部分主要在CPU上做。最后一帧带框的画面交给VPU编码变成H.264或H.265码流推给显示端或者上位机。双路就是把上面这条链路复制两份。但关键在于这两份链路并不是互相独立的物理通道它们共享同一个NPU、同一个RGA模块、同一个VPU、同一颗SoC的DDR带宽和CPU核心。所以“双路”的真正含义是两条逻辑链路竞争一组共用资源。2.2 RK3588上真正会打架的几个硬件资源我在调试时把双路跑起来然后用perf和板级工具逐个盯着看找到最明显的几个争抢点NPU是最先打架的地方。yolov5s int8模型在主路推理一次大概需要20到30毫秒辅路同时也要用NPU跑同一个模型或者更轻的模型。NPU模块本身同一时间只能执行有限的任务流两路请求挤进来NKNN底层会在一个队列里串行处理谁先到谁先跑完全没主次。更麻烦的是如果两路分别初始化了独立的rknn context那么NPU内部还要做context切换这个开销会让两路都明显变慢。RGA缩放的争抢排在第二。两路图像往NPU送之前都要过一遍RGARGA虽然是个硬件加速器但同一时刻能并行处理的job也有限。不过它的单次任务耗时通常在1到3毫秒相比NPU和VPU算是轻量选手影响没那么大。VPU编码排在第三。主路要推高清H.264流辅路也想推流或者录视频。RK3588的VPU虽然能多路并发编解码但并发路数越多每路的帧率和码率稳定性就越差。实测中两路同时编码时主路码流的帧间隔也会被辅路拖累。CPU和DDR带宽是容易被忽略的隐形资源。画面上做NMS、画框、颜色转换这些都是CPU密集型工作再加上两路的数据搬运占用了DDR带宽一旦CPU调度混乱后处理延迟就会直接体现到帧间隔上。我这套系统在双路全跑的时候CPU占用能到85%以上DDR带宽也长期顶着高位。2.3 从轮询走向严格优先三种调度策略的取舍知道了资源会在哪里打架接下来就是选调度策略。我在双路方案里实际试过三种思路效果差异非常明显。轮询Round Robin是最简单的一版双路各开一个线程大家默认靠CFS公平分时间。结果是两路平均帧率都还行但主路毫无确定性尖峰频出。这其实不能算一种策略只是把问题交给默认调度器。加权公平WFQ是给主路更高的调度权重比如通过nice值调低辅路优先级或者用cgroup的cpu.weight把主辅分配成10比1。这种做法能提升主路的平均帧率但有一个根本缺陷高优先级线程和低优先级线程仍然可能同时处于就绪状态调度器“公平地”按权重切换运行因此主路在最坏情况下依然要等待辅路甚至其他负载让出资源延迟尖峰无法消除。严格优先Strict Priority则是另一种思路彻底打破公平。排队时把两路任务分成高优先级队列和低优先级队列只要高优先级队列里还有任务调度器永远先服务高优先级。低优先级队列只有在高优先级完全空闲时才被处理。它不保证辅路能拿到多少帧率但保证了主路的延迟在最坏情况下也是可控的。代价是辅路可能被“饿死”帧率可能掉得很低。双路视觉方案二为什么最终选严格优先原因很简单方案二的架构本身就是主辅不对等的主路承载核心检测业务出问题影响的是整个系统的表现辅路更多是记录和观察轮询用途。与其两边都跑不扎实不如牺牲辅路的帧率上限换主路对每个帧间隔的精准可控。在边缘计算场景里可预期性往往比峰值性能更重要。3. QoS严格优先在RK3588上的三层落地3.1 第一层CPU核分工严格优先落到具体系统上三层配置。第一层是CPU核分工。RK3588是8核CPU由4个Cortex-A76大核和4个Cortex-A55小核组成。大核性能强、频率高天然适合跑主路的后处理、NMS、画框这些CPU密集型逻辑。小核性能弱功耗低但足够处理辅路的次要任务。做法是把主路进程或主路线程绑定到大核上辅路进程或线程绑定到小核上同时利用tasket之类的工具实现核级隔离。这种物理隔离带来的好处是即使调度器偶尔犯错主路线程也不会被挤到小核上去慢吞吞地执行。我在板子上测试时仅仅做了CPU核分工这一件事主路的帧间隔尖峰就已经从300毫秒级别降到了150毫秒级别。具体绑核命令如下# 给主路绑定CPU0-3(A76大核) taskset -p 0x0f 主路线程PID # 给辅路绑定CPU4-7(A55小核) taskset -p 0xf0 辅路线程PID如果是在代码里直接绑定用pthread_setaffinity_np更合理#include pthread.h cpu_set_t cpuset; CPU_ZERO(cpuset); CPU_SET(0, cpuset); CPU_SET(1, cpuset); CPU_SET(2, cpuset); CPU_SET(3, cpuset); pthread_setaffinity_np(thread_main, sizeof(cpu_set_t), cpuset);这里有个细节必须提醒不同内核配置下CPU核的对应关系可能不一样。我的板子上CPU0-3是A76大核、CPU4-7是A55小核但有的RK3588设备树会把顺序调转。先执行lscpu确认当前平台的拓扑再写死绑核逻辑。3.2 第二层线程实时优先级CPU核分工只是物理隔离真正的“严格优先”还得靠线程调度策略来体现。Linux里SCHED_FIFO就是一种典型的实时调度策略它允许你给线程设定一个1到99的优先级数字越大优先级越高。调度器运行时永远优先执行优先级最高的可运行线程高优先级线程只要能跑低优先级线程就没有机会获得CPU。我在双路视觉里把主路线程设置为SCHED_FIFO优先级80辅路线程设置为SCHED_FIFO优先级50。这样主路的后处理、画框、编码提交这些环节会坚决抢占CPU通道辅路只会在主路线程被IO阻塞或主动让出的间隙里拿到执行权。代码实现如下#include pthread.h #include sched.h struct sched_param main_param; main_param.sched_priority 80; pthread_setschedparam(thread_main, SCHED_FIFO, main_param); struct sched_param aux_param; aux_param.sched_priority 50; pthread_setschedparam(thread_aux, SCHED_FIFO, aux_param);注意设置实时优先级需要root权限。另外SCHED_FIFO是纯抢占式的一旦主路线程进入一段长耗时循环CPU会被它一直占住。所以主路线程内部的耗时逻辑本身要克制比如NPU推理等待的部分不要用忙等循环不然整个系统的响应都会被拖死。关于这一点后面踩坑部分我会专门说。3.3 第三层cgroup与队列兜底CPU绑核和线程优先级解决的是“CPU时间归谁”的问题但严格优先的实际工程里还需要两道保险。第一道是cgroup。cgroup能把一组进程的CPU使用量控制在某个比例内。我用cgroup v1做了一次辅路CPU上限控制把辅路的CPU份额锁死防止它因为绑定在小核上仍然吃掉过多系统时间。# 挂载CPU子系统和cpuset子系统 mount -t cgroup -o cpu,cpuset none /sys/fs/cgroup mkdir -p /sys/fs/cgroup/cpu/high_prio mkdir -p /sys/fs/cgroup/cpu/low_prio # 主辅比例设为8:1 echo 1024 /sys/fs/cgroup/cpu/high_prio/cpu.shares echo 128 /sys/fs/cgroup/cpu/low_prio/cpu.shares echo 主路进程PID /sys/fs/cgroup/cpu/high_prio/tasks echo 辅路进程PID /sys/fs/cgroup/cpu/low_prio/tasks第二道是应用层的队列兜底。严格优先天然有个风险低优先级队列可能被完全饿死。双路视觉里辅路如果长时间拿不到资源画面会冻结成一张死图很容易被误判为系统崩溃。所以我在代码里加了保底逻辑——不管高优先级队列有多长每500毫秒强制往辅路队列里塞一帧保证辅路画面至少是“活”的。if ( high_queue.size() 2 || (now - last_aux_push 500ms) ) { aux_frame capture_aux_camera(); push(aux_queue, aux_frame); last_aux_push now; }这段逻辑的意思是平时主路队列不长时辅路可以正常采集一旦主路开始积压辅路就让开但如果辅路已经超过500毫秒没往队列里送过帧就强行插一帧进去。这个兜底机制是我在整个阶段四里最得意的一个设计它让严格优先的副作用控制在了可接受范围。3.4 VPU、NPU和网络出口的严格优先怎么处理CPU这块可以通过绑核加线程优先级实现严格优先但NPU、VPU这些硬件引擎是独立于CPU的CPU优先级管不到它们。我在阶段四里对这三个硬件资源分别做了应用层处理。NPU的处理思路是避免双context并行。一开始我用两个rknn context分别跑主路和辅路结果NPU内部要频繁切换上下文两路都慢。后面改成只保留一个rknn context推理请求串行提交但提交顺序严格排队主路的帧到了就立刻调用rknn_run辅路的帧只有在主路没有待处理任务时才允许提交。这样虽然NPU底层还是串行工作但至少保证了主路的请求永远先到达NPU。VPU编码同样用互斥锁保证主路优先拿到硬件编码器。当主路需要编码推流时直接抢锁辅路编码等锁释放后再进行。编码器本身的并发能力有限别再天真地以为两路同时编码不会相互影响。网络推流如果走的是有线以太网可以用tc的prio qdisc做一个三板斧的网络QoStc qdisc add dev eth0 root handle 1: prio bands 3 tc filter add dev eth0 parent 1: protocol ip u32 match ip sport 8000 0xffff flowid 1:1这样主路RTSP推流端口的数据包会走最高优先级的band辅路推流走低优先级band。实测下来在局域网带宽吃紧时主路的码流几乎不丢帧。4. 可复现的手把手配置步骤4.1 确认平台与内核拓扑动手之前先确认两件事系统版本和CPU拓扑。直接跑下面的命令uname -a lscpu cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_max_freq在香橙派5系列上能看到的典型信息是4个A76大核频率能到2.2GHz以上4个A55小核频率在1.8GHz左右。确认好哪个编号段是大核之后后面所有绑核操作才不会错。我这次用的是香橙派58GB内存版本双路摄像头都是MIPI CSI接口的IMX219。然后确认cgroup类型。新版Ubuntu默认挂载cgroup v2Rockchip系列SDK有些内核又保留cgroup v1。执行下面的命令就知道当前是哪个版本mount | grep cgroup如果是v1会看到cpu、cpuset、memory等各自独立挂载如果是v2只会看到cgroup2一条。4.2 启动参数和cgroup准备阶段四不要求重新编译内核用户态的配置就能覆盖绝大多数需求。不过为了减少内核线程迁移干扰我建议在启动参数里加一条isolcpus把辅路要用的CPU核从CFS的常规调度中摘出来。不过要不要用看你的情况如果只是双路视觉用taskset绑核就够了isolcpus更适合想彻底隔离的场景# 在/boot/uEnv.txt或bootargs里追加 isolcpus4,5,6,7我实际配置时没有用isolcpus因为内核线程和中断亲和性调整起来麻烦而taskset加SCHED_FIFO已经能解决问题。cgroup倒是直接用上了作为辅路CPU上限的第二道保险。初始化命令和前面那组一样先挂载、建组、配置cpu.shares再把两个进程的PID分别写进tasks文件。要注意的是cgroup v2下的写法不同v2不认cpu.shares改用cpu.weight范围是1到10000。如果你的板子挂载的是cgroup v2就改成echo 1000 /sys/fs/cgroup/high_prio/cpu.weight echo 100 /sys/fs/cgroup/low_prio/cpu.weight4.3 源码改造采集线程与推理线程的优先级配置层面的东西做完后真正让严格优先级生效的关键是应用层代码。理想的做法是让主路线程和辅路线程在一开始就被赋予不同的实时优先级而不是运行时再去改。先创建两个线程分别命名#include thread #include pthread.h #include sched.h // 主路采集与推理线程 std::thread main_thread([](){ main_vision_loop(); }); // 辅路采集与推理线程 std::thread aux_thread([](){ aux_vision_loop(); }); // 给线程命名方便调试 pthread_setname_np(main_thread.native_handle(), main_vision); pthread_setname_np(aux_thread.native_handle(), aux_vision); // 主路绑大核CPU0-3设置SCHED_FIFO优先级80 cpu_set_t main_cpu; CPU_ZERO(main_cpu); for (int i 0; i 4; i) CPU_SET(i, main_cpu); pthread_setaffinity_np(main_thread.native_handle(), sizeof(cpu_set_t), main_cpu); struct sched_param main_param; main_param.sched_priority 80; if (pthread_setschedparam(main_thread.native_handle(), SCHED_FIFO, main_param) ! 0) { perror(setschedparam main); } // 辅路绑小核CPU4-7设置SCHED_FIFO优先级50 cpu_set_t aux_cpu; CPU_ZERO(aux_cpu); for (int i 4; i 8; i) CPU_SET(i, aux_cpu); pthread_setaffinity_np(aux_thread.native_handle(), sizeof(cpu_set_t), aux_cpu); struct sched_param aux_param; aux_param.sched_priority 50; pthread_setschedparam(aux_thread.native_handle(), SCHED_FIFO, aux_param);线程内部主路的循环体要写成“无脑优先”的样子不需要等待辅路不需要考虑辅路状态void main_vision_loop() { while (running) { Frame f pop_main_frame(); // 从主路采集队列取帧 rknn_infer(f); // NPU推理 postprocess_nms(f); // NMS后处理 vpu_encode_and_send(f); // 编码推流 } }辅路的循环体则要主动让路void aux_vision_loop() { while (running) { if (main_frame_queue.size() 2) { // 主路积压主动让出CPU std::this_thread::sleep_for(std::chrono::milliseconds(5)); continue; } Frame f pop_aux_frame(); // 增加超时保护确保每500ms至少一帧 if (f.empty() (now - last_aux_sent 500ms)) continue; rknn_infer(f); postprocess_nms(f); vpu_encode_and_send(f); last_aux_sent now; } }这样改完之后即使不对线程用taskset命令手动干预程序一启动就已经处于QoS严格优先模式了。4.4 验证脚本帧间隔与调度延迟观测配置做完一定要量化验证。我建议在主路推理线程里加一个统计段打印每帧的时间间隔这是最直观的指标#include chrono #include cstdio auto last std::chrono::steady_clock::now(); while (running) { Frame f pop_main_frame(); auto now std::chrono::steady_clock::now(); double ms std::chrono::durationdouble, std::milli(now - last).count(); printf([MAIN] interval %.1f ms, fps %.1f\n, ms, 1000.0 / ms); last now; rknn_infer(f); postprocess_nms(f); vpu_encode_and_send(f); }另外可以查看实时调度参数是否生效chrt -p 主路线程PID chrt -p 辅路线程PID输出里应该能看到policy: FIFO和对应的优先级。系统运行几小时后再把日志里采集到的帧间隔拉出来分析。这里直接看两个数据平均帧间隔和最大帧间隔。最大帧间隔才是严格优先有没有生效的关键指标。5. 实测数据从抖成心电图到稳如直线5.1 测试条件说明放图之前先交代测试条件否则每个数字没有参考意义。我用的环境是香橙派5RK3588S、8GB内存系统是Armbian内核5.10CPU调成性能模式两个MIPI CSI接入IMX219摄像头。模型是yolov5s转成的rknn int8主路输入640x640辅路输入320x320代码是C单进程双线程电源使用官方15V适配器。测试跑三组配置阶段三的默认调度也就是什么都不做、只做CPU绑核、完整版QoS严格优先绑核加SCHED_FIFO加cgroup加辅路兜底。每组稳定运行15分钟记录帧间隔数据。5.2 三组对比数据直接看下面这张汇总表指标默认调度阶段三仅绑核QoS严格优先阶段四主路平均帧率16.8 fps22.3 fps28.4 fps主路帧间隔标准差46.2 ms24.7 ms8.7 ms主路最大帧间隔287 ms143 ms41 ms辅路平均帧率17.3 fps15.2 fps7.5 fps辅路最大帧间隔236 ms310 ms512 ms系统CPU占用88%82%73%先看默认调度的数据。主路平均帧率16.8fps看起来不算太差但最大帧间隔287毫秒意味着画面会频繁出现接近0.3秒的停顿。辅路也好不到哪去。两路都在平均指标上过得去但谁都没有获得稳定的帧节奏。再看只绑核的情况。主路平均帧率提升到22.3fps最大帧间隔降到143毫秒辅路还保持了15fps以上的平均帧率。这说明CPU绑核的成本很低收益却很直接把主路从辅助任务和内核迁移的干扰中解放了出来但还没做到真正的硬优先级保障。最后是完整版QoS严格优先。主路平均帧率28.4fps已经接近单路状态下30fps的上限最大帧间隔压缩到41毫秒和单路几乎没有差别。辅路平均帧率降到7.5fps最大帧间隔512毫秒这个数字看着挺夸张但因为辅路有500毫秒不得不说的兜底画面始终没有完全冻结。5.3 数据背后的关键原因为什么完整版QoS严格优先能把主路拉到接近单路的性能根本原因在于它消除了主路线程与辅路线程之间的竞争窗口。默认调度时两路线程在CFS的公平机制下频繁切换切换本身带来缓存失效和调度延迟每帧的等待时间充满不确定性。而完整版下主路线程是SCHED_FIFO优先级80的大核常驻线程它要么在运行要么在等NPU或VPU的硬件返回不会被辅路线程抢占CPU。因此主路每一帧从入队到推理到后处理再推流出帧延迟基本固定最大帧间隔自然被压到了40毫秒上下。辅路帧率掉到7.5fps是严格优先的预期内结果。辅路只在主路线程被NPU卡住或编码等待的时间间隙里运行小核性能本来就不强帧率大幅下降很正常。这也是为什么方案二必须设计成“主辅不对等”——如果两路都是核心业务就根本不能用严格优先只能考虑加权公平甚至更复杂的双预算策略。6. 踩坑记录与使用心得6.1 SCHED_FIFO不是越高越好系统假死实录第一次调实时优先级时我把主路设到95、辅路设到90想着优先级拉满一定最稳。结果跑起来不到两分钟整个板子就像死机一样SSH都连不上。强制断电重启后又试了一次换成优先级99结果开机没多久直接假死。原因说穿了也很简单。Linux内核本身有一些实时线程比如migration、watchdog这些它们的优先级一般是99。你把应用线程也拉到95甚至99又不做任何让步应用线程长时间占住CPU后内核的关键维护线程和SSH对应的进程都得不到调度机会整个系统自然失去响应。后来我降到主路80、辅路50就再没出现假死。个人建议是把最高优先级保守地控制在80以内给内核留出足够的余量。实时优先级调整一定要做小步验证别一上来就拉满。6.2 cgroup v1和v2别搞混这套板子一开始跑的是Ubuntu 22.04默认挂载cgroup v2。我按照Rockchip SDK习惯直接写cpu.shares结果卡了很久才发现v2根本不认这个文件要用cpu.weight。换成Armbian之后又是v1同样一套脚本在不同系统上表现不一样。建议每次都先执行mount | grep cgroup确认版本再写对应路径。我还遇到过一种情况cgroup v2需要先启用控制器才能写cpu.weight否则报“No such file or directory”。需要提前执行echo cpu /sys/fs/cgroup/cgroup.subtree_control这类初始化操作很容易被忽略排查起来特别隐蔽。6.3 NPU任务不是排队就能排出来的应用层的QoS严格优先管不住NPU内部的任务调度。最开始我以为只要在代码里先调用主路的rknn_runNPU就会严格按提交顺序执行。实际观察下来NPU内部自己有队列策略多路请求交织时它对任务顺序的处理和我们的预期不太一样。解决思路是把推理尽量串行化只维护一个rknn context主路推理请求总是立即发出辅路推理请求只在主路没有待推理帧时才提交。这样虽然NPU内部还是可能打乱顺序但由于辅路提交的频率被大幅压制主路推理请求在时间上几乎是独占NPU的。从最终的帧间隔数据看这个方法确实有效。6.4 心得永远给辅路留一个保底机会阶段四做完整之后我最大的体会是严格优先这种策略执行起来要坚决但设计上一定要有兜底。如果没有那个500毫秒的保底机制辅路在极端负载下可能长时间一帧都不出画面完全冻结。系统维护人员看到一路画面死住第一反应往往是程序卡死了而不是“调度的锅”。有了保底辅路虽然帧率低但画面始终在更新看起来就只是“慢”不是“死”。这种状态的区分在实际项目运维里非常重要。做双路视觉的QoS严格优先不是要把辅路彻底牺牲掉而是把不确定性明确地推给次要任务同时给次要任务留一条最低限度的活路。这个平衡把握好了整个系统才真正称得上稳定可靠。
