跟着思兼学习Klipper(25)提高 Klipper 进程优先级减少报错
前言
原创文章，转载引用请务必注明链接，水平有限，如有疏漏，欢迎指正交流。
文章如有更新请访问 DFRobot 社区 或者 cnblogs 博客园。
欢迎对 Klipper 固件，以及对改版 CNC 加工的 Voron 三叉戟、v0、v2.4 感兴趣的朋友加群交流（QQ Group：490111638）
由于 Klipper 主要采用滚动更新机制（小而频繁的更新），最近的某次更新中，主观感受其出现 "timer too close" 错误的几率大大增加。
本文尝试通过提升 Klipper 上位机程序 klippy 的进程优先级来提高性能/运行稳定性，减少报错。
本文环境：Ubuntu 22.04 on RK3399，Klipper 全家桶最新版。
同时开辟 [先锋测试] 栏目，主要是我有一些想法，却没有时间精力去测试验证，不过我会提供解题思路，有兴趣的可以试试看。
另外，着急的直接看 2.1 即可。同时本文所附参考文献和链接都值得好好看。
本文涉及到的内容：
- klipper 报错
timer too close的常见原因和可能的解决方法 - 使用
renice工具调节 klippy 上位机软件的系统优先级 - 修改 klippy 的 CPU 核心亲和力，增加进程的 CPU 缓存命中率，从而提升其运行性能
1、[他山之石] 可能的原因
Sineos 在 帖子中 总结了一些常见原因及可能的解决方法。
This error typically occurs when the host sends a message to the MCU, scheduling an event at a time that is in the past.
该错误一般发生在上位机向 MCU 发送消息时，计划触发事件的时间落后于当前。
1.1 Reasons | 原因
- High system load of the host | 上位机系统负载过高
- High disk activity of the host | 上位机磁盘读写过高
- Swapping due to low free memory | 低可用内存导致的高磁盘交换空间使用
- Disk errors / dying SD card | 磁盘错误或者 SD 卡不良
- Unstable voltage | 电压不稳定
- Other hardware hogging the USB bus or other system resources | 其他硬件占用 USB 总线或者其他系统资源
- Running in a Virtual Machine | 在虚拟机中运行
- USB, UART or CANBUS wiring faults leading to extremely delayed messages | 通讯接线错误导致的高传输延迟
- ElectroMagnetic Interference (EMI) affecting proper signal transmission or leading to high resend rates | 电磁干扰信号传输或者导致高重传率
1.2 Potential solutions | 可能的解决方案
- Check for other resource-intensive processes running in parallel | 检查是否同时有高系统资源占用的进程
- Remove additional hardware, especially web cams | 断开其他硬件，特别是网络摄像头
- Check SD card for errors / replace SD card | 检查 SD 卡是否故障/更换其他 SD 卡
- Check for
Under-voltage detected!errors / make sure to use a good and adequate power supply | 检查是否有低电压告警（适用树莓派），确保电源供电功率满足上位机需求。 - Do not run data lines (USB, UART, CANBUS) close to and in parallel to high current lines like heaters or steppers. Use high quality cables (shielded / ferrite core). Keep such cables as short as possible | 避免通讯数据线（USB、UART、CANBUS）与高电流电源线（加热器、步进电机）太近或者并排走行。或使用高质量线缆（屏蔽或带磁环）。或尽量保证线缆越短越好。
- Also see Advanced Trouble-Shooting / Graphing Klipper | 其他
2、我的想法与解决思路
一是使用 klipper 官方工具生成系统负载图进行分析多无明确阳性发现；二是由于 KlipperBox 硬件不变，既往都是很稳定的，此次仅仅升级 Klipper 便导致此错误，故考虑 Klipper 软件问题可能性大。例如运行在上位机的 Klippy 软件对系统资源、实时性要求变高；新版 MCU 固件存在问题等。其实有一点，也是人们常说的，如果当前的固件用着好好的，请不要轻易升级。除非有重大功能更新或者BUG修复。这里探讨两个方法，旨在提升 Klippy 进程优先级，降低由于系统资源被抢占导致出错的机率。
2.1 方法一：调整进程优先级
CPU 给每个进程分配时间片，时间到了就换下一个进程，当切换间隔较短时，用户感觉到就是多个程序同时运行的。
在操作系统的角度看，可用资源太少，而进程又是那么多，每个进程都需要使用可用资源，自然而然的需要给进程划分优先级，谁的优先级高，谁先享受资源的使用
Linux系统优先级有两个来控制：Priority 和 Nice，两者的关系简述如下：
- 系统进程默认有一个优先级 Priority，PRI 值越小越快被执行。
- 优先级可以通过 Nice 来调节，最终的优先级为 PRI(new) = PRI(old) + nice，这样，当 nice 值为负值的时候，那么该程序将会优先级值将变小，即其优先级会变高，则其越快被执行。
- 可以通过
renice工具来调节 nice 值。 - 更多内容可参考：Linux进程中的优先级的理解（PRI 和 NI）_pri ni-CSDN博客
我们可以在 htop 工具中看到进程 Priority (优先级PRI) 和 Nice （NI）值，如：
由于 renice 工具需要知道进程的 PID 编号进程标识符（PID），所以我们可以先获取 klippy 进程的 PID（pidof 命令查询不到，父进程为 python），然后调用 renice 提升优先级，例如项目：klipper-priority-fix。
# 下载安装
git clone https://github.com/Dids/klipper-priority-fix.git ~/klipper-priority-fix
~/klipper-priority-fix/scripts/install.sh
# 默认用户没有 renice 权限，使用 root 权限临时解决.同时执行两个替换规则
sudo sed -i 's/^User=/#&/; s/^Group=/#&/' /etc/systemd/system/klipper-priority-fix.service
sudo systemctl daemon-reload
sudo systemctl restart klipper-priority-fix
# 安装脚本会自动添加 update_manager 更新条目
# 安装脚本会自动添加到 ~/printer_data/moonraker.asvc 中用于管理服务
systemctl restart moonraker
此工具默认将 klippy 设置为 0 + (-20)，也就是系统最高优先级。如果出现莫名其妙的问题，可以参考下文修改源码。具体可以使用 htop 命令来确认。
2.2 [先锋测试] 方法二：设置进程与 CPU 核心绑定以提高性能
2.2.1 什么是绑核
所谓绑核，其实就是设定某个进程/线程与某个CPU核的亲和力（affinity）。
设定以后，Linux调度器就会让这个进程/线程只在所绑定的核上面去运行。但并不是说该进程/线程就独占这个CPU的核，其他的进程/线程还是可以在这个核上面运行的。如果想要实现某个进程/线程独占某个核，就要使用cpuset命令去实现。
其实，很多情况下，为了提高性能，Linux调度器会自动实现尽量让某个进程/线程在同样的CPU上去运行。所以，除非必须，我们没有必要显式的去进行进程绑核操作（虚拟机中有时候需要这样做）。
最后一句话没空去找来源，但是是否和虚拟机运行 Klipper 容易出现各式问题有关？有待验证。同时我们也了解到一个新工具 cpuset，只不过目前用不到。下面是来自的 redhat.com 一个直观演示。
另外还有一个问题，实际上多数程序对多核心支持一般，主要在对单核性能要求高一些。
2.2.2 绑核提升进程运行性能？
在Linux系统中，进程的调度切换是由内核自动完成的，在多核CPU上，进程有可能在不同的CPU核上来回切换执行，这对CPU的缓存不是很有利。
原文是以 x86 CPU 的 L1/L2 和 L3 缓存为例，对于 ARM 架构的 CPU 是否同样适用呢？我们以常见的 Amlogic S905 为例，其 CPU 框图如下：
并参考 S905 的数据手册(来自 Hardkernel) 可知：
- S905 有 4 个核心，每个核心有独立的 32KB 缓存
- 所有核心共用 512KB L2 缓存
所以猜测上述机制有效，即绑核有可能提升 klippy 进程运行性能。具体可以参考上述文章里的程序进行测试验证。
2.2.3 如何绑核
两种方法，一是合并到上述脚本，二是使用配置文件。
Method 1：合并到 klipper-priority-fix 脚本
由于 taskset 命令也需要知道进程 PID，所以可以考虑修改源码和上述 klipper-priority-fix 项目合并，毕竟获取进程 PID 这步原脚本已经实现了。不过需要测试后才建议合并，毕竟绑核可能比提高优先级更可能引发问题。这个理论上不难，我们剖析下此项目：
-
install.sh调用util.sh调用klipper-priority-fix.py，主要过程包括去掉py后缀并复制到/usr/local/bin/klipper-priority-fix，以及安装系统服务。 -
klipper-priority-fix.py脚本中设置默认 nice 为-20，Priority 为0，此时进程优先级最高。 -
klipper-priority-fix.py脚本中使用sudo运行renice需要输入密码时服务会报错无权运行。具体为cmd = f"renice -n {KLIPPY_NICE_VALUE} -p {pid} || sudo renice -n {KLIPPY_NICE_VALUE} -p {pid} " -
合并后的脚本如下，修改
/usr/local/bin/klipper-priority-fix第 19 行cmd = f"renice -n {KLIPPY_NICE_VALUE} -p {pid} || sudo renice -n {KLIPPY_NICE_VALUE} -p {pid} && taskset -cp 0 {pid}"
Method 2：使用配置文件
修改 systemd service 文件来修改进程的 CPU 亲和力，在 [Service] 下添加如下内容
sudo nano klipper.service
# [Service] 添加如下内容,0-3分别代表不同核心，如【0-1,3】，这里我们绑定到第一个核心。
CPUAffinity=0
# 重载服务并重启服务生效
sudo systemctl daemon-reload
sudo systemctl restart klipper
# 查看进程 pid 现在的绑核情况
pi@kbox ~ taskset -p {pid}
pid 690's current affinity mask: 1
# 设置进程绑核
pi@kbox ~ taskset -cp 0 {pid}
pid 690's current affinity list: 0-5
pid 690's new affinity list: 0
此外，我们还可以使用 limits.conf 来设置用户名下进程启动时默认的优先级。
参考文献
- How to Set Linux Process Priority Using nice and renice Commands (tecmint.com) | +使用文件配置优先级
- Limits - Debian Wiki
- 3 tips for Linux process performance improvement with priority and affinity | Enable Sysadmin (redhat.com)
- 技术|使用 nice、cpulimit 和 cgroups 限制 cpu 占用率 (linux.cn)
番外
我们还可以使用 ionice 工具来获取或设置程序的IO调度与优先级，理论上不是导致这次报错的主要原因。
先锋测试：
本期我们提出以下假设：
