• 沒有找到結果。

GPIO 3 GPIO 2

nAck

<PC signal>

<LART signal>

PC LART

圖 4-2-8 系統量測接腳圖

當 PC signal 由 low 變 high 時,LART 實驗板上的中斷被觸發,作業系統將 目前所有中斷,進行中斷處理常式的分派動作,當對應的中斷處理常式被喚醒時,

隨即將 LART signal 設成 low,PC 端得知 LART signal 被設成 low 後,同時也將 PC signal 降為 low。最後,中斷處理常式完成工作後,會再將 LART signal 回恢成 high。在 PC 中斷產生至 LART 回應訊號這段時間就是中斷延遲,我們不斷地重覆 這樣的程序,並利用邏輯分析儀量測並記錄這段時間。其時序圖,如圖 4-2-9 所示。

我們在無負載與負載情況下,分別安排三種不同環境下,進行中斷延遲時間的量 測:

(1) RTAI 環境下的 Real-Time interrupt handler (2) RTAI 環境下的 Linux interrupt handler (3) 一般 Linux interrupt handler

Interrupt handler finishs

Interrupt latency PC

signal

LART signal

Trigger an interrupt

Interrupt handler starts running

time

圖 4-2-9 中斷延遲測試時序圖

這裡所呈現的三種不同測試環境之中,RTAI 的 Real-time handler 與 Linux 的 handler 的量測結果,是為了比較在即時作業系統與一般作業系統,其系統的反應 能力差異。而 RTAI 下的 Linux handler 量測結果,是為了說明 RTAI 的 RTHAL 對 Plain Linux handler 7.512 1.232 1.7299 1.536 0.60 21397

表 4-2-5 負載情況下中斷延遲統計表

Handler Max. Min. Mean Med. Std. Dev. Samples

RTAI RT-handler 15.56 1.6 3.002 2.744 0.9905 19941 RTAI Linux handler 518.4 4.84 67.151 50.58 64.187 20385 Plain Linux handler 41.63 2.528 5.119 3.76 4.613 22078

首先針對無負載測量的結果來看,我們可以觀察得知,在無負載的情況下 RTAI 的 Real-time handler 與 Linux 的一般 handler,其反應能力的差異並不明顯。但就平 均的反應能力而言,RTAI 的1.9944 s

µ

略高於 Linux 的1.7299 s

µ

,由此可見,在無 負載下,Linux 較能提供較佳的平均效能。而造成這種小差距的原因是 RTHAL 在 中斷處理時,增加了微小的延遲,此微小的延遲我們可以由圖 4-2-10 及圖 4-2-11 的中斷延遲分佈圖,看出這樣的差異性。其中的中斷延遲分別集中在1.2

µ s

~ 6

µ s 以

及 2.2

µ s

~ 7

µ s 。而在 RTAI 下的 Linux handler,並不是直接接受硬體中斷,而是

RTHAL 先接收硬體中斷後,經過中斷的分派,並執行對應的中斷處理常式後,再 產生軟體中斷給 Linux 核心,這時才由以 Linux 來執行中斷處理常式。在 RTHAL 的中斷分派與處理過程中,可能有大量的中斷發生,而即時作業系統必須先行處 理必要的中斷常式,因此,這就造成之後在 Linux 核心處理中斷的明顯延遲。

圖 4-2-10 無負載情況下 Linux 中斷延遲分佈

圖 4-2-11 無負載情況下 RTAI 中斷延遲分佈

接著,在負載的情況下,由實驗結果得知 RTAI RT-handler 與 Linux handler 就有較明顯的延遲差異。但此時 Linux 平均延遲 5.119 s

µ

欲較 RTAI 下的延遲 3.002 s

µ

大,主要的原因除了加入的外部負載中斷(網路中斷),確實造成了 RTHAL

與 Linux 核心的負擔外,探視 /proc 下的 Linux 核心資訊,造成 Linux 核心更大的 負擔,以致於有較大的延遲。在相同條件下,RTAI 的 RT-handler 不受 Linux 核心 負載的影響,而有較好的反應能力。圖 4-2-12 與圖 4-2-13 為負載下中斷延遲分佈 圖。

圖 4-2-12 負載情況下 Linux 中斷延遲分佈

圖 4-2-13 負載情況下 RTAI 中斷延遲分佈

在負載的情形中,其最差情況(Worse-Case)的延遲,如圖 4-2-14 與圖 4-2-15 所示,在 Linux 的環境中,其延遲為 41.63 s

µ

,而 RTAI 的環境中,其延遲皆被局 限在16 s

µ

以內,顯然 RTAI 擁有較佳系統反應能力。就其延遲標準差而言,Linux 為 4.613 s

µ

,而 RTAI 的標準差值被控制在1 s

µ

以內,顯視中斷延遲在 RTAI 環境下 的變動差異較小,較能提供一個可預測的即時環境。

圖 4-2-14 負載情況下 Linux 中斷延遲取樣(22078 samples)

圖 4-2-15 負載情況下 RTAI 中斷延遲取樣(19941 samples)

4.2.3.2 中斷任務延遲(Interrupt Task Latency)

假設一個外部裝置已收集好所有外界資料時,裝置會發送一個硬體中斷訊號 給系統,系統接收到中斷後會找尋對應的中斷處理常式並執行。外部裝置中斷發 生之後至系統選擇對應的工作這段時間,就是所謂的中斷任務延遲,如圖 4-2-16 所示。為了方便了解系統活動,除了使用原有的 PC signal 當作外部中斷及 LART signal 做為中斷任務的執行狀態外,我們另外安排了一個 GPIO 4 當作中斷處理常 式的執行狀況,稱為 Handler signal。

如圖 4-2-17 所示,當 PC signal 設成 high 時,對應的處理常式會被執行,於 是 Handler signal 亦被設定在 high,待處理常式結束前,會將優先權高的工作放入 等待佇列中,這時 LART signal 被設定成 low,表示工作處於等待狀態。當處理常 式結束後,系統會由等待佇列中挑選優先權高的工作執行,一旦對應的工作開始 執行時,LART signal 會被恢復成 high 狀態。而 PC signal 為設定成 high 至 LART signal 設定成 high,這段時間就是欲量測的延遲。在這項測試中,分別在無負載與 負載情況下,我們安排了 Linux 與 RTAI 兩種環境,進行中斷任務延遲的量測與比 較。

interrupt occurs

interrupt recongized

handler