上一篇文章我们把IGH编译安装跑通从站也扫出来了。但如果你真拿它在Ubuntu 22.04默认内核上做周期控制很快会碰壁明明EtherCAT从站都进OP了跑起来却隔三差五抖一下1ms周期实测能蹦到5ms以上控制效果根本没法看。问题基本不出在IGH本身而在于内核实时性没验证、没调优。这篇文章接着上一篇往下走基于linux 6.6.119这个带ethercat igc支持的6.6稳定版最新内核配合PREEMPT_RT补丁把“实时内核性能验证与调优”这步做完整。核心解决三件事第一确认RT内核真的生效第二用cyclictest一类工具把系统调度延迟测到可见第三把延迟压下去之后回到IGH和EtherCAT从站做整体周期抖动验证。文章里所有命令都是我在实际环境中跑过的参数也按常见工程场景给出你可以直接照着来。1. 为什么选6.6.119 PREEMPT_RT以及RT内核生效确认1.1 6.6.119到底解决了什么问题在Ubuntu 22.04上做实时控制绕不开一个现实问题官方generic内核默认没有开启完整实时抢占能力跑IGH这类依赖微秒级调度的任务延迟是硬伤。所以我的方案一直是“主线内核 PREEMPT_RT补丁”自编译。这次搜到的6.6.119属于6.6 LTS稳定分支RT补丁跟得比较勤而且这个版本对igc网卡的支持已经很成熟。igc是什么它是Intel I225/I226系列2.5G网卡的驱动。IGH访问EtherCAT从站本来就需要一块网卡做收发常见选择是e1000e千兆或者igc2.5G。如果网卡驱动和内核配合不好EtherCAT帧的发送时机就不稳定实时性再好也白搭。6.6.119在igc驱动上已经积累了不少修复实测下来帧收发抖动比早期6.x版本好很多这也是我把它定为基线版本的核心原因。另一个容易被忽略的点IGH的通用网卡驱动模式是ec_generic它靠网卡驱动的NAPI回调接收帧。如果你用igc网卡ec_generic配合igc在6.6.119上表现稳定而老内核上时常出现收帧丢包、cyclictest和EtherCAT实测对不上的现象。这个我已经在实际项目中踩过所以版本选择不是玄学是有具体驱动修复背景的。1.2 别只看uname要确认PREEMPT_RT真正打开很多人在内核编译安装完敲一句uname -r看到版本号带rt字样就以为大功告成。这种想法要不得。RT补丁是否生效要看内核配置里CONFIG_PREEMPT_RT是否等于y还要看运行时dmesg输出。我自己判断RT内核生效一般两步走。第一步看内核启动信息确认调度器确实是实时抢占模型。命令行执行uname -a能看到PREEMPT_RT字样是最直观的信号但还不够。我更建议查一下实际生效的配置避免启动时加载了另一个内核cat /boot/config-$(uname -r) | grep PREEMPT_RT输出是CONFIG_PREEMPT_RTy才算真正编译进去了。如果显示CONFIG_PREEMPTy但不是RT说明你用的其实是低延迟内核配置不是完整RT。第二步用内核实时性自检工具dmesg确认preempt能力。执行dmesg | grep -i preemptRT内核启动时会有调度器相关提示。这里要特别注意很多人启动时忘了改GRUB的default entry编译好的RT内核根本没用上uname看到的还是generic。我建议编译完RT内核后把/boot/grub/grub.cfg里对应的menuentry彻底搞清楚最好直接用GRUB_DEFAULT指定别靠手动选择因为工控机经常断电重启没人盯着选内核。另外一个实用细节装了RT内核后如果发现nvidia显卡驱动掉了、虚拟机起不来这类问题基本可以确定是RT补丁对某些子系统有影响优先检查内核配置里CONFIG_DRM、CONFIG_VHOST相关选项而不是直接换回generic。实时内核性能验证第一步就是把环境固化成一条命令能确认的基准后面所有调优才有对照意义。2. cyclictest实战实时内核的性能基准测试与指标解读2.1 测试环境准备和常用命令确认RT内核生效后测试工具我用的是rt-tests里的cyclictest这是评测Linux实时性最通用的工具没有之一。Ubuntu 22.04上可以直接安装sudo apt install rt-tests测试主机的CPU拓扑要先看清楚。比如一台8核16线程的机器如果开了超线程实时任务和中断会被挤到同一个物理核的两个逻辑核上互相干扰测出来的延迟数据完全没有参考价值。所以第一步是用lscpu确认物理核和逻辑核分布然后在后续调优里把CPU隔离做好。我日常跑的最基础测试是这样的sudo cyclictest -t 8 -p 80 -i 1000 -l 1000000 -m参数含义拆开讲-t 8表示创建8个测试线程-p 80是线程实时优先级-i 1000是线程间隔1000微秒即1ms-l 1000000是循环一百万次-m是锁内存防止换页。这个测试会持续跑约16分钟测出来的max值如果普遍低于50微秒说明系统实时性在常规负载下是健康的。如果只想快速摸底可以把循环次数缩小sudo cyclictest -t 8 -p 80 -i 1000 -l 10000大概十几秒出结果能看出个大致区间。但正式验收或者排查抖动问题时我建议至少跑30分钟以上。实时系统最怕随机出现的毛刺跑太短测不出来。2.2 结果怎么读max值只是开始分布更重要cyclictest输出里T: 0表示第一个测试线程P: 80是优先级I: 1000是间隔Min是观测到的最小延迟Act是最近一次延迟Avg是平均延迟Max是最大延迟。大部分新手只盯Max觉得Max在100微秒内就OK。这个判断太粗糙。我自己的判断逻辑分两层。第一层是Max必须低于周期预算的30%。比如你要跑1ms周期控制调度延迟Max超过300微秒就很危险因为EtherCAT本身还有帧收发时间。所以我的验收标准一般定在Max小于100微秒。第二层是看延迟分布。如果Avg只有十几微秒、Max偶尔跳到200微秒说明系统整体稳定但存在偶发干扰源这种场景下做运动控制就可能出现个别周期异常。怎么看分布可以用cyclictest的直方图模式sudo cyclictest -t 8 -p 80 -i 1000 -l 1000000 -m -h 500-h 500表示记录0到500微秒区间的分布测试完会打印一长串分布计数。我拿到这个数据会重点看高延迟区间的计数。如果10微秒以内的采样占了99.99%偶尔有个别到几百微秒问题大概率出在中断或内核线程抢占而不是基本盘不行。另外一个必须养成的习惯测试时观察负载。不要开着浏览器、网易云音乐这类应用去测实时性那测的是娱乐环境不是控制环境。我用top、htop观察是否有异常CPU占用进程同时用vmstat看上下文切换是否剧烈。实时性验证讲究的是在可控环境下测出系统底噪而不是在乱七八糟的环境里测一堆无法解释的数字。2.3 测出来的延迟偏高时先查这几类干扰如果首次测试Max直接几百上千微秒别急着怀疑RT内核先排查下面几项我按出现频率排个序。第一CPU调频没关闭。Ubuntu 22.04默认的cpufreq调控器是powersave或schedutilCPU频率随负载动态变化频率切换本身就有几十微秒级延迟。这个在实时场景必须关掉方法是sudo cpupower frequency-set -g performance如果提示没有cpupower先装linux-tools-common和linux-tools-$(uname -r)。这一步做完延迟通常立刻降一个量级。第二中断和内核线程抢CPU。最典型的是网卡中断、显卡中断、USB中断都挤在CPU0上而cyclictest的线程也会跑到CPU0。用htop按CPU逐核看就会发现CPU0明显忙其他核心闲置。这种需要在下一节的启动参数里做CPU隔离和中断亲和性配置。第三是电源管理。笔记本上跑实时测试时尤其明显ACPI的C-state切换会造成几十微秒的停顿。BIOS里能关C-state最好不能关的话尝试启动参数processor.max_cstate1和intel_idle.max_cstate0。在我的实际项目机器上单单这一步就把Max从80微秒压到了30微秒。我在测试时还遇到过一次很诡异的场景AMESys的BIOS更新后cyclictest Max从40飙到300查了一圈发现是BIOS里Turbo Boost开启导致频率跃升抖动。实时领域有个取舍追求极致低延迟建议关掉Turbo和C-state如果延迟预算比较宽开节能换功耗也凑合。但做IGH运动控制我一般直接关Turbo保证频率恒定的代价换来可预测的延迟。3. 系统级实时调优实操清单把延迟压到可预测3.1 内核启动参数isolcpus、nohz_full、rcu_nocbs怎么配合系统底噪排查完之后下一步是改内核启动参数。这一块是实时调优的核心也是很多教程讲得最含糊的地方。我先给出一份我在IGH项目中实际使用的参数组合再逐个解释作用isolcpus2-7 nohz_full2-7 rcu_nocbs2-7这里假设CPU0和CPU1留给系统、中断和普通任务CPU2到CPU7作为实时计算核。isolcpus的作用是把指定CPU从通用调度器中隔离出去普通用户进程默认不会跑到这些核上只有通过taskset显式指定的进程才能用。这样EtherCAT周期任务和cyclictest线程就可以独占一个核不受其他任务干扰。nohz_full是关闭隔离核上的周期性时钟中断减少无谓的计时器打断。rcu_nocbs则是把RCU回调挪到非隔离核上处理。这三者通常组合使用缺一不可。我见过有人只加了isolcpus没加nohz_full延迟数据没有本质改善就是因为周期性tick还在不停打断实时线程。改启动参数的方式有两种。一种是临时在GRUB菜单按e编辑linux行追加参数测试有效后再写进配置文件。另一种直接改/etc/default/grub在GRUB_CMDLINE_LINUX里追加然后sudo update-grub sudo reboot个人建议先临时改确认有效再固化。固化之后启动时间会稍微变长因为系统把一部分CPU隔离出去后一些驱动初始化会慢这是正常的。另外很多教程会让你加irqaffinity参数比如irqaffinity0-1把中断绑到前两个核上。实际中我一般不发这个参数而是通过修改/proc/irq/N/smp_affinity把EtherCAT网卡中断单独绑到CPU0或CPU1比全局参数更精细。3.2 中断亲和性绑定的实操细节隔离核之后EtherCAT网卡的中断如果落在被隔离的CPU上还是会打断实时任务。正确做法是把网卡中断明确绑定到非实时核。以igc网卡为例先在启动后找到对应的中断号cat /proc/interrupts | grep -i igc假设结果是irq 32把它绑到CPU0上echo 1 /proc/irq/32/smp_affinity这里的1是CPU亲和性的位图表示值1代表CPU0值2代表CPU1值4代表CPU2。把bit0和bit1都选上就写3。这里有个容易踩的坑有些网卡用MSI-X多队列每个队列有独立中断号一个队列不够用。我见过有的人只绑了一个中断另一个队列的中断照样往实时核上泼延迟突然飙升。所以绑定后一定要用cat /proc/interrupts | grep -i eth观察所有相关中断号上的计数是否在实时核之外增长别只看配置不看实际效果。同样地对于IGH方案最终目标是让ec_generic收到的EtherCAT帧中断只在指定CPU上触发这样才能保证周期任务和帧收发互不干扰。3.3 电源管理、文件系统和BIOS层面的坑启动参数和中断绑完之后如果cyclictest的Max还在50微秒以上浮动需要继续往低层挖。三个方向依次排查。第一BIOS里关闭C-state、Turbo Boost和SMT超线程。SMT关闭尤其关键。打开超线程后同一个物理核的两个逻辑核共享执行单元实时任务和系统任务挤在一起延迟不可控。在BIOS关掉SMT后lscpu里的Thread(s) per core会显示1这时候实时任务的执行资源才是独占的。第二文件系统挂载参数。IGH应用如果频繁读写磁盘日志文件系统也可能成为延迟来源。把日志目录挂载时加上noatime可以少一些元数据写盘动作。当然更极端的做法是把日志直接写到tmpfs内存盘上但这种方案有掉电丢日志的风险适合调试期不适合长期运行。我在项目中是调试期用tmpfs稳定后切回磁盘并限制日志量。第三内存分配策略。IGH在实时线程里如果访问内存触发缺页异常一次page fault能吃掉几百微秒。RT应用一般用mlockall锁住内存IGH应用在ecrt_master_activate之前就要做完内存锁定。用如下命令验证进程内存是否锁定grep VmLocked /proc/$(pgrep your_igh_app)/status如果数值稳定不变说明mlockall生效。这个点很隐蔽我见过不止一次应用跑在RT内核上却因为换页延迟超标最后查出来是没锁内存。4. IGH与EtherCAT从站实时性验证从命令到周期实测4.1 确认主站运行环境和实时线程状态系统级调优完成后回到IGH本体验证整体效果。先加载主站模块并确认主站状态sudo modprobe ec_master main_devices00:11:22:33:44:55 sudo dmesg | grep -i ethercat sudo ethercat masterethercat master输出里会显示主站版本、活动状态和配置的从站数量。这里我特别要强调一点IGH主站的周期任务不是靠模块自动跑的它必须由应用层通过ecrt_master_activate触发而且应用线程必须运行在实时调度类上。如果你的应用主循环是普通SCHED_OTHER优先级那IGH周期就是随缘的和内核实时性再强也没关系。启动IGH测试应用时我用chrt把线程设为SCHED_FIFO优先级通常在80到90之间sudo chrt -f -p 85 $(pgrep igh_app)SCHED_FIFO是实时调度策略优先级数值越大越优先但IRQ线程优先级一般在50-70之间。把IGH应用线程设为85意味着它在用户态优先级高于大多数中断线程配合中断绑核后EtherCAT周期就比较稳定。优先级不是越高越好太高的优先级会导致IGH线程把softirq饿死反而收不到帧。这个边界需要你实测我自己的习惯是从80起步逐步调高观察ethercat命令中是否有帧错误计数。4.2 DC模式下的周期抖动实测方法IGH主站如果使用DC同步模式从站时钟会被主站同步此时衡量实时性的最好方法是直接测量实际周期与目标周期的误差。IGH提供的工具里我常用这个方法做初步验证先通过ethercat命令查看主站域信息ethercat master ethercat slav ethercat pdos从站全部在线、PDO映射正确后用一个简单的周期打点程序在每个周期里记录当前时间和时间点间隔统计偏差。更直接的方法是在应用层每周期调用ecrt_master_sync_reference_clock和ecrt_master_sync_slave_clocks之后打印相邻两次周期调用时间差这个时间差围绕设定周期波动最大值和最小值之差就是周期抖动。实测达到几十微秒以内说明IGH的通信链路实时性基本合格。如果不方便改应用代码直接用下面的方法观察主站收发统计cat /sys/class/ethercat_master/master0/stats不同IGH版本的路径可能略有差异但总能找到帧发送次数、丢失次数之类的统计。重点关注是否有frame loss和working counter变化异常。EtherCAT的working counter是指数据交换过程中成功参与的从站数如果它在运行中随机变小大概率是周期任务没按预期调度某个周期没发帧或者网卡中断被抢占了。4.3 EOE为什么默认禁用以及和实时性的关系标题相关热词里有一个“igh为什么要禁用eoe”这个我实际工作中经常被问到。EOE全称EtherCAT over Ethernet作用是把普通以太网帧封装进EtherCAT数据报里传输相当于在EtherCAT总线上开了一条“网络隧道”。EOE的代价是普通以太网帧长短不一封装进EtherCAT循环帧后导致帧长度不确定这会直接影响EtherCAT的实时性能。EtherCAT的帧在总线上是顺序执行的一个周期内如果混入了EOE数据帧发送时间和处理时间都会变得不可控。IGH主站在默认状态下不启用EOE就是让实时过程数据通信保持长度固定、时间确定。如果你的应用里确实需要从站传递普通以太网数据我建议走独立网口或换用其他通信方式别在运动控制周期里混入EOE。顺着这个思路IGH的网卡驱动选择也遵循同样的确定性原则。ec_generic是通用网卡驱动模式转发路径相对简单ec_igc则是IGH专门为igc网卡优化过的驱动中断处理路径更短延迟更低。如果网卡是I225/I226这类igc网卡强烈建议直接用ec_igc。我实测过同一台机器上ec_generic周期抖动大约30到50微秒换成ec_igc后能压到10到20微秒差别非常明显。5. 常见问题与排查技巧实录5.1 一张表说清高频故障调优过程中总会碰到各种幺蛾子我把自己遇到的、加上身边朋友遇到的高频问题整理成一个速查表现象直接原因处理方式cyclictest Max经常超200usCPU调频未关闭或C-state开启cpupower设置performanceBIOS关C-state/Turbo中断全挤在CPU0实时任务被抢未设置isolcpus或中断未绑核启动参数isolcpusecho绑定smp_affinityIGH从站扫不到网卡驱动错误或main_devices未指定modprobe时用main_devices网卡MAC应用掉到普通调度类周期乱跳未用chrt设置SCHED_FIFOchrt -f -p 85启动/设置IGH周期运行一会儿丢失working counter实时线程饿死中断处理降低优先级或调整中断与线程绑核关系从站进不了OPPDO映射不匹配或DC同步失败检查ethercat pdos映射DC配置升级内核后IGH模块加载失败内核头文件和IGH模块版本不匹配重新编译IGH确认模块目录对应uname -r这里再展开一个具体场景。有人问“igh进入op读不到数据”遇到这个我一般按顺序排查先ethercat slaves看从站是否在OP状态再ethercat pdos看映射对不对接着确认自己的应用有没有周期性调用ecrt_master_activate最后用chrt确认实时线程有没有起来。这四个节点做完90%的问题能定位。曾经有个项目从站能进OP但过程数据读出来全是0排查到最后发现是PDO映射里设置了错误的起始地址。这种问题只有对着从站XML文件逐条核对才能发现没有捷径。IGH本身没有bug满天飞的问题大部分“有bug”其实都是配置和使用方式不对。5.2 OOM和内存分配在实时场景中的隐蔽影响关于热词里提到的oom报错场景及调优方法在实时IGH应用里也有一种隐蔽表现。IGH主站和应用层分配了大量内存但没锁定某些时刻触发swap或page fault延迟瞬间飙高系统甚至出现OOM kill。这类问题在cyclictest上看不出来但EtherCAT周期里会周期性抖一下。我建议在启动IGH应用前检查系统可用内存并让应用调用mlockall时加上MCL_FUTURE标记。如果应用本身不方便改可以用ulimit -l unlimited提升锁定限额ulimit -l unlimited sudo -E ./your_igh_app同时控制进程数量别让无关应用抢内存。实时控制主机建议只跑必须的服务其他能停就停。Chromium这类浏览器平时用着没事但它多点内存分配和后台任务分分钟让IGH周期多出几个超大延迟点。另外如果遇到IGH周期任务被OOM killer干掉的情况先看是内存泄漏还是短时间内内存暴涨别急着加内存。IGH本身内存占用不大很多时候是调试程序或者日志库把内存吃满。把日志缓冲限制加上或者改用环形缓冲异步写盘就能缓解。5.3 一个典型的调优前后对比案例我拿一台实际工控机举例配置是Intel i5-12500、32GB内存、I225网卡、Ubuntu 22.04、6.6.119-rt内核。未调优前cyclictest数据大概是Min 3us、Avg 15us、Max 850us。这个Max完全没法做1ms周期控制偶尔的一下抖动足以让运动轨迹出现肉眼可见的顿挫。按顺序做完整套调优后BIOS关C-state和Turbo、启动参数isolcpus2-7 nohz_full2-7 rcu_nocbs2-7、cpupower performance、中断绑核、ght应用chrt -f 90最终cyclictest稳定在Min 2us、Avg 5us、Max 28us。IGHigh的周期打点实测1ms周期下的抖动从调优前约200us降低到20us以内完全满足常规运动控制需求。这个案例说明什么实时性的提升不是靠某一个神仙参数而是靠一整套组合拳。每步可能只压掉一点延迟叠加起来效果就非常可观。而且每台机器硬件不同BIOS表现不同参数细节要适当调整别盲目抄作业。核心思路是一致的先测底噪、再隔离CPU、再绑中断、再验IGH周期一环扣一环。最后说一个我个人的习惯调优过程中每一步改完都要重新跑一遍cyclictest和IGH周期打点把数据记录下来。看着延迟一步步从几百微秒压到几十微秒你对这台机器的实时性心里就有底了。以后系统里加新服务、更新驱动你也能快速对比出变化不会被一个突然飙高的延迟弄得手足无措。实时调优这事数据积累比理论推导重要得多。