压榨硬件极限：CH9344 USB 串口 Linux 实时超低延迟调优指南

在工业控制、机器人多关节同步等高实时性场景中，USB 转串口的延迟抖动往往是系统性能的“隐形杀手”。近期在优化 CH9344 串口驱动时，我遇到了典型的 34ms 周期性卡顿 以及随机的延迟抖动。

经过从系统内核、驱动源码到应用层逻辑的全栈调优，最终将 RTT (Round-Trip Time) 稳定压制在 1.5ms 以内。本文将分享这一整套全栈优化方案。

1. 痛点分析：消失的 34ms 去哪了？

在默认的 Linux RT 内核环境下，通讯表现出两种典型的异常：

• 现象 A (致命卡顿): 每隔约 1 秒，串口通讯会突发一次 32ms ~ 34ms 的巨大延迟。这对于控制频率要求在 500Hz 以上的系统来说是不可接受的。
• 现象 B (随机抖动): 在消除大卡顿后，依然存在平均 1ms、峰值 1.5ms 的微小抖动。

2. 系统层调优：消除周期性“血崩”

这是解决 34ms 卡顿的核心，本质上是解决 Linux 内核对实时进程的限制以及中断抢占问题。

2.1 关闭 Real-Time Throttling

Linux 内核默认为了防止实时进程意外耗尽 CPU 导致系统锁死，预留了 5% 的 CPU 时间给非实时进程（每秒 50ms）。当实时任务负载较高时，内核会强制暂停实时进程，造成 30-50ms 的卡顿。

操作命令：

sudo sysctl -w kernel.sched_rt_runtime_us=-1

2.2 USB 中断提权 (IRQ Priority)

USB 控制器 (XHCI) 的中断处理线程默认优先级通常较低，容易被其他系统服务抢占，产生优先级翻转。

优化方案：

1. 找到 irq/128-xhci_hcd（具体编号视硬件而定）的 PID。
2. 将其调度策略设为 SCHED_FIFO，优先级设为 90。

2.3 清理干扰服务

ModemManager 会定期轮询串口尝试识别调制解调器，而 irqbalance 会动态调整中断亲和性，这两者都会导致串口通讯瞬间中断。

sudo systemctl stop ModemManager irqbalance brltty

3. 驱动层优化：打通缓冲区血脉

原厂驱动为了兼顾吞吐量，往往存在缓冲机制，这在追求低延迟的场景下适得其反。

3.1 移除 PACKLOAD 机制

在 driver/ch9344.c 源码中，PACKLOAD 宏会导致驱动等待 4 字节对齐或特定超时才推送数据。

修改建议：

注释掉或取消定义 PACKLOAD 宏。强制驱动在收到 USB 包后立即推送到 TTY 层。

3.2 强制 low_latency 标志

在驱动代码中手动设置 port->low_latency = 1，确保内核 TTY 层以最小缓冲模式运行。

4. 应用层：极限压榨延迟

当系统和驱动都打通后，应用层的写法决定了最后 1ms 的稳定性。

4.1 核心绑定与调度策略

使用 SCHED_FIFO 策略并将进程绑定到特定 CPU 核心（如 CPU 3），配合内核启动参数 isolcpus=3，可以极大减少进程切换开销。

4.2 禁止 CPU 深睡眠 (C-States Locking)

硬件唤醒延迟（从 C1/C1E 状态回到运行态）约有 100-200us。通过操作 /dev/cpu_dma_latency 可以锁定 CPU 频率。

// 应用层 C-State 锁定代码片段
int32_t target = 0;
int fd = open("/dev/cpu_dma_latency", O_WRONLY);
write(fd, &target, sizeof(target));

4.3 IO 模型：从 Poll 到 Busy Wait

传统的 poll() 或 select() 涉及“睡眠-中断-唤醒”路径。在独占 CPU 的前提下，改用 ioctl(FIONREAD) + 自旋死循环 是延迟最低的选择（Zero Latency）。

// 示例：死循环自旋读取
while (keep_running) {
    int bytes_avail;
    ioctl(fd, FIONREAD, &bytes_avail);
    if (bytes_avail >= target_len) {
        read(fd, buf, target_len);
        break;
    }
    // CPU 保持活跃，立即响应
}

5. 最终成果与总结

经过上述全栈优化，在 RT-Kernel 6.1.0 环境下测得：

物理极限说明

目前残留的 1.5ms 峰值延迟 主要受限于 USB 2.0 的物理特性。USB 2.0 High Speed 基于 125us 的微帧调度，在多次“发-收”交互中，错过帧窗口导致的累积延迟是物理定律的极限。

对于追求极致实时的开发者，这一套方案已经逼近了 USB 2.0 串口通讯的理论上限。

参考资料：

• CH9344 官方驱动手册
• Linux Kernel RT Patch Documentation
• Project Maintainer: Diana / Antigravity