關於 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

讀者留言 (0)

留言功能維護中。將於近日重新開放。

連絡作者

Jollen Chen,Moko365(仕橙3G教室)講師,熱愛研究 Linux 與 Android 技術。曾為 Motorola、HTC、Foxconn、LG、OPPO、騰迅、廣達電腦、緯創、仁寶等超過 50 家企業講授課程。目前在 MokoVersity 擔任軟體工程師,撰寫 Node.js 程式,也在幾家科技廠兼任 Android Framework 研發顧問。您可透過電子郵件 <jollen (at) jollen (dot) org> 或這裡與我連絡。