我有一個實時的過程,偶爾通過RS232發送到高速攝像機.我還有其他幾個實時進程占用大量CPU時間,使用CUDA在幾塊GPU板上進行圖像處理.通常,串行通信速度非常快,每次消息和響應大約需要50 ms.但是,當后臺進程忙于進行圖像處理時,串行通信會慢下來,通常需要多秒(有時超過10秒).

總之,在串行通信期間,如果進程B,C等非常繁忙,則進程A會延遲,即使進程A具有最高優先級：

>進程A(實時,最高優先級)：偶爾的串行通信

>進程B,C,D等(實時,低優先級)：繁重的CPU和GPU處理

當我將后臺進程更改為SCHED_OTHER(非實時)進程時,串行通信速度很快;然而,這對我來說不是一個解決方案,因為后臺進程需要是實時進程(當它們不是時,GPU處理無法與高速攝像機充分保持一致).

顯然,串行通信依賴于系統中的一些非實時過程,這些過程由我的實時后臺進程預先占據.我想如果我知道哪個進程用于串行通信,我可以提高其優先級并解決問題.有誰知道串行通信是否依賴于系統上運行的任何特定進程？

我正在使用標準內核(不是PREEMPT_RT)運行RHEL 6.5.它有雙核6核CPU.

在Erki A的建議中,我抓住了一條繩索.顯然這是一個select()系統調用很慢(“set roi2”是攝像機的命令,“Ok！”結尾是攝像機的響應)：

write(9, "set roi2"..., 26) = 26 <0.001106>

ioctl(9, TCSBRK, 0x1) = 0 <0.000263>

select(10, [9], NULL, NULL, {2, 0}) = 1 (in [9], left {0, 0}) <2.252840>

read(9, "Ok!\r\n", 4096) = 5 <0.000092>

慢速select()使得它看起來像攝像機本身響應緩慢.但是,我知道這不是真的,因為通過改變后臺進程優先級如何影響速度.在這種情況下,select()是否依賴于正在運行的某個其他進程？

如果我跳過select()并只執行read(),則read()系統調用很慢.

解決方法:

根據您的串行設備/驅動程序,串行通信很可能依賴于內核工作線程(kworker)將傳入的串行數據從中斷服務例程緩沖區轉移到線路規則緩沖區.您可以增加內核工作線程的優先級,但是,工作線程處理共享工作隊列.因此,增加工作線程的優先級將增加串行處理的優先級以及可能不需要優先級提升的一大堆其他內容.

您可以修改串行驅動程序以使用專用的高優先級工作隊列而不是共享隊列.另一個選擇是使用tasklet,但是,這兩個都需要驅動程序級別的修改.

我懷疑最直接的解決方案是將com端口設置為低延遲模式,可以從命令行通過setserial命令：

setserial /dev/ttySxx low_latency

或以編程方式：

struct serial_struct serinfo;

fd = open ("/dev/ttySxx");

ioctl (fd, TIOCGSERIAL, &serinfo);

serinfo.flags |= ASYNC_LOW_LATENCY;

ioctl (fd, TIOCSSERIAL, &serinfo);

close (fd);

這將導致串行端口中斷處理程序立即將傳入數據傳輸到線路規則,而不是通過將傳輸數據添加到工作隊列來推遲傳輸.在這種模式下,當你從應用程序中調用read()時,如果工作隊列中有工作要刷新,你將避免read()調用休眠的可能性.這種睡眠可能是間歇性延遲的原因.

標簽：linux,serial-port,real-time

來源： https://codeday.me/bug/20190528/1173183.html

總結

以上是生活随笔為你收集整理的linux查看通信延迟,低优先级进程延迟实时进程中的串行通信(Linux)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。