Linux 上的低延迟串行通信 [英] Low latency serial communication on Linux

问题描述

我正在 Linux 上通过串行端口实现协议.该协议基于请求应答方案，因此吞吐量受限于将数据包发送到设备并获得应答所需的时间.这些设备大多基于 arm 并运行 Linux >= 3.0.我在将往返时间减少到 10 毫秒以下时遇到了麻烦(115200 波特，8 个数据位，无奇偶校验，每条消息 7 个字节).

I'm implementing a protocol over serial ports on Linux. The protocol is based on a request answer scheme so the throughput is limited by the time it takes to send a packet to a device and get an answer. The devices are mostly arm based and run Linux >= 3.0. I'm having troubles reducing the round trip time below 10ms (115200 baud, 8 data bit, no parity, 7 byte per message).

哪些 IO 接口的延迟最低:select、poll、epoll 或使用 ioctl 手动轮询?阻塞或非阻塞 IO 会影响延迟吗?

What IO interfaces will give me the lowest latency: select, poll, epoll or polling by hand with ioctl? Does blocking or non blocking IO impact latency?

我尝试使用 setserial 设置 low_latency 标志.不过好像没什么效果.

I tried setting the low_latency flag with setserial. But it seemed like it had no effect.

还有什么我可以尝试减少延迟的方法吗?由于我控制所有设备，因此甚至可以修补内核，但最好不要.

Are there any other things I can try to reduce latency? Since I control all devices it would even be possible to patch the kernel, but its preferred not to.

---- 编辑----

---- Edit ----

串行控制器使用的是 16550A.

The serial controller uses is an 16550A.

推荐答案

在与更多工程师讨论这个话题后，我得出的结论是，这个问题在用户空间中无法解决.由于我们需要跨过桥进入内核领域，我们计划实现一个内核模块，它与我们的协议对话并为我们提供延迟 <1 毫秒.

Having talked to to some more engineers about the topic I came to the conclusion that this problem is not solvable in user space. Since we need to cross the bridge into kernel land, we plan to implement an kernel module which talks our protocol and gives us latencies < 1ms.

--- 编辑---

事实证明我完全错了.所需要的只是增加内核滴答率.默认的 100 个滴答声增加了 10 毫秒的延迟.1000Hz 和一个负值的串行过程给了我想要达到的时间行为.

Turns out I was completely wrong. All that was necessary was to increase the kernel tick rate. The default 100 ticks added the 10ms delay. 1000Hz and a negative nice value for the serial process gives me the time behavior I wanted to reach.

这篇关于Linux 上的低延迟串行通信的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！