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

什么IO接口会给我最低的延迟：使用ioctl手动选择,轮询,epoll或轮询？阻塞或非阻塞IO是否会影响延迟？

我尝试使用setserial设置low_latency标志.但它似乎没有效果.

还有其他我可以尝试减少延迟的事情吗？由于我控制所有设备,甚至可以修补内核,但它首选不要.

—-编辑—-

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

解决方法:

请求/应答方案往往效率低下,并且在串行端口上很快显示出来.如果您对吞吐量感兴趣,请查看窗口协议,如kermit文件发送协议.

现在,如果你想坚持你的协议并减少延迟,选择,轮询,阅读都会给你大致相同的延迟,因为正如Andy Ross所说,真正的延迟是在硬件fifo处理中.

如果你很幸运,你可以在不修补的情况下调整驱动程序行为,但是你仍然需要查看驱动程序代码.但是,让ARM处理10 kHz中断率肯定不会对整体系统性能有利…

另一种选择是填充数据包,以便每次都达到fifo阈值.它还将确认是否存在fifo阈值问题.

10毫秒@ 115200就足以传输100个字节(假设为8N1),所以你看到的可能是因为没有设置low_latency标志.尝试

setserial /dev/<tty_name> low_latency

它将设置low_latency标志,当在tty层中向上移动数据时,该标志用于内核：

void tty_flip_buffer_push(struct tty_struct *tty)
{
         unsigned long flags;
         spin_lock_irqsave(&tty->buf.lock, flags);
         if (tty->buf.tail != NULL)
                 tty->buf.tail->commit = tty->buf.tail->used;
         spin_unlock_irqrestore(&tty->buf.lock, flags);

         if (tty->low_latency)
                 flush_to_ldisc(&tty->buf.work);
         else
                 schedule_work(&tty->buf.work);
}

schedule_work调用可能是您观察到的10毫秒延迟的原因.