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

问题描述

我在Linux上通过串行端口实现协议。该协议基于请求应答方案，因此吞吐量受到将分组发送到设备并获得答案所花费的时间的限制。这些设备大多是基于arm的，运行Linux> = 3.0。我有麻烦，减少往返时间低于10ms（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.

推荐答案

我已经与更多工程师谈过这个话题，我得出结论，这个问题在用户空间是不可解决的。由于我们需要将桥穿过内核陆地，我们计划实现一个内核模块，它描述我们的协议， 1ms。

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.

---编辑---

结果我完全错了。所有必要的是增加内核tick率。默认的100个滴答添加了10ms延时。 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屋！