關於 Acceptable Time 概念：運用在我的 Event-Driven 架構中

jollen 發表於 April 8, 2007 2:34 PM

前一篇日記提到，「feedback scheduler」是 time-triggered 模式，但我所規劃的架構為「full user-space」的實作，因此，怎麼在 user-space 計算時間，便成為一個核心議題；考慮到我們所定義的「acceptable time」有別於真實的系統時間（clock），或是即時性（real-time），因此我定義了一個基本時間單位：T。

若下一個時間單位為 T2，則 T_interval = T2 - T1，也就是每個 T 時間可以取得一個真實的系統時間，即 T_interval，但這不是我們想要的「時間」；假設 T_interval = 10ms，那個在我的系統中，每個基本時間單位 T 會等於真實時間的 10ms。

我們定義 TS(n) 為：每個事件到達後，一直到它的「control task」被「啟動」所需的花費時間（latency）。再定義 TD(n) 為：control task 啟動後，到執行結束所需要的時間長度。由於在這個系統裡，是不考慮真實時間的，只用「幾個單位」來表示所謂的「時間」，所以可以簡單將此系統的概念表示成：

TS(n) = n * T
TD(n) = n * T

這樣有什麼用呢？例如，TS(3) 表示某一事件到達後，需要 3 個時間單位（3 個 T）來啟動 control task；TD(15) 表示該 control task 執行需要 15 個 T。那麼，假設我們的 embedded Linux 系統有一個按鍵，按下後會出現目前電池用量資訊，若此按鍵的事件稱為 battery_key，便能根據使用經驗將 battery_key 的 TS(n) 定義為 100，寫成：

TS_battery_key(100)

也就是若 battery_key 使用上述的 "TS(n)" 系統，則 TS_battery_key(100) = TS(100) = 100T。換算成真實時間可能是 100*10ms = 1000ms，也就是 1 秒；我們定義按鍵按下到「開始出現畫面」的最長間隔是 1 秒，我們認為這是使用者視覺上可接受的時間，此外，對使用者來說，1 秒與 0.9 或是 0.8 秒感覺都是一樣的，所以我們用 "T"，也就是「時間單位」的概念來陳述。

接著，要「秀好畫面」，也就是 control task 要做完整個工作的時間（execution time）如果是 150 個 T 的話，寫成 TD_battery_key，同樣也是使用與 TS_battery_key 相同的時間系統，那麼：

Turn around time of event 'battery_key' = TS_battery_key(100) + TD_battery_key(150) = T(100) + T(150) = 100T + 150T = 250T

我們「定義」整個動作在 300 個時間單位內完成都是可被「使用者接受」，或是「難以被使用者查覺」的，寫成 Taccept_battery_key(300)，當然，acceptable time 也必須與上述二個時間使用相同的時間系統；最後得到，我的排程器必須設法做到：

Turn around time of event 'battery_key' <= Taccept_battery_key(300) = T(300)

對於在我的 event-driven 架構中所使用的 "acceptable time" 概念，先簡單介紹到這裡。（待續）

來源：Jollen's Blog

主選單

近期文章

我的工作

關於 Acceptable Time 概念：運用在我的 Event-Driven 架構中