實時優化: 鍊路延遲計算

1. 背景

如何為自動駕駛程式計算鍊路延遲?

一般來說在網際網路開發上, 我們采用

Distributed Systems Tracing

(比如說Google Dapper), 來追蹤一次服務調用的鍊路延遲.

但是對機器人程式來說, 是不存在"服務調用"的概念的. 鍊路上可能大部分程式都是time-based, 對資料都是buffer的形式來使用. 無法建立上下遊的關聯.

換種思路, 其實可以大問題分解成小問題: 通過各部分task/io的執行情況, 來證明某個鍊路的延遲.

2. 延遲計算

stop鍊路如下, 從決策一直到底盤:

Decider --> Planning --> Control --> Guardian --> Chassis           

這裡的程式邏輯如下:

(time-based, 100hz)表示是定時觸發, 頻率為100hz

Decider --> Planning(time-based, 10hz) --> Control(time-based, 100hz) --> Guardian(event-based) --> Chassis(time-based, 100hz)           

如下假設是Decider到Planning發decision的一個io情況:

max_delay(測量) = Planning收到queue - Decider發出 = cpu排程響應時間 + 處理時間 = 10ms           

根據上面的資料, 該io的deadline可以設定到10ms

關于deadline概念:

Planning的timer callback執行情況如下:

max_delay(測量) = Planning完成task- timer wakeup = cpu排程響應時間 + 處理時間 = 10ms           

根據上面的資料, Planning的timer task的deadline可以設定10ms

(time-based任務的deadline的start為timer wakeup時間, event-based任務的deadline的start為event input的時間)

最終:

Decider到Planning消費decision的延遲 = Planning周期間隔(100ms) + Planning Timer Deadline(10ms) + io Deadline(10ms) = 120ms           

其他地方同理, 一個個計算過來疊加, 就可以得到整個鍊路的預期最大延遲.

這樣算過來的值會偏大, 但還是足夠合理.

3. 其他

使用上述方法, 鍊路的延遲就簡化為deadline一種可變量.

控制了deadline, 就可以保證所有鍊路延遲的确定.

• 不做實時性優化, deadline是不可确定/不可控的, 進而所有鍊路的預期最大延遲也都是不可确定.
  • "CPU配置設定與任務排程"算是一項實時性優化.
• 即時是做了實時性優化, 也不能保證task/io的執行就不會超過deadline
  • 是以要使用deadline監控, 以此回報指導程式設計
  • 最終要做到deadline在99.99%情況下都不會被突破