眾所周知,實時系統(tǒng)并不通過單一分析進行測試,即使單一分析可以證明實時系統(tǒng)的正確性。實時系統(tǒng)的測試是詳盡討論此問題的依據(jù)。您的工作就是建立起用戶對解決方案的信任感。下文介紹的工具可以完整、實時地解釋應用程序和操作系統(tǒng)之間的交互作用,它們有助于您加深對實時系統(tǒng)的了解。
盡管關于實時的定義還存在諸多爭議,我們還是來了解一下對它的定義。這里,我引用comp.realtime FAQ的定義。實時系統(tǒng)的權威定義(Donald Gillies)如下:
“實時系統(tǒng)是這樣一種系統(tǒng),即其計算正確與否,不僅取決于計算邏輯是否正確,還取決于計算結果所花費的時間。如果不能滿足系統(tǒng)的時間限制,就會出現(xiàn)系統(tǒng)失敗的情況?!?/STRONG>
因為集高速I/O、機器人技術和機械控制于一身的工業(yè)自動化應用對時間的要求最為苛刻。微軟開始了解實時嵌入式操作系統(tǒng)的特殊社會要求。自1986年以來,通用汽車動力公司(GMPTG)在制造應用中實施OMAC技術方面一直處于領先地位,并且在后來促成了OMAC用戶群的形成。他們一起對數(shù)百種應用進行評估后發(fā)現(xiàn),大多數(shù)系統(tǒng)(95%)需要一毫秒或稍長的周期。一毫秒周期允許的變化幅度為10%,或是100微秒(μs)。這是基于200 MHz X86系統(tǒng)的Windows CE的設計目標,其在該平臺上的平均響應時間為50 μs。Windows CE達到或超過了95%的被評估的硬實時應用OMAC的要求。
大部分滿足要求的工業(yè)自動化應用是由從一臺機器發(fā)出的外部信號驅動的。此信號以中斷形式發(fā)送給硬實時應用。微軟鼓勵Windows CE的開發(fā)人員,盡可能在中斷服務線程(IST)中置入更多的應用代碼。這使OMAC抖動定義變?yōu)獒槍Σ怀^100 μs的IST延遲的時間限制。其余被評估的應用使用計時器創(chuàng)建其周期。這就需要一臺延遲或抖動不超過100 μs的1毫秒計時器??傊琌MAC定義提出以下設計和測試要求:
·Interrupt Service Thread (IST) latencies of no more than 100 μs latency.
·1 millisecond timers with maximum of 100 μs latency.
·中斷服務線程(IST)延遲不超過100 μs。
·1毫秒計時器的延遲最長為100 μs。
在了解了OMAC的設計和測試要求后,接下來讓我們看看Windows CE中安裝的工具。這些工具的用途是確定中斷定時、應用執(zhí)行動作、操作系統(tǒng)功能定時和時序安排定時。
區(qū)分實時系統(tǒng)和實時操作系統(tǒng)也很重要。實時系統(tǒng)包含硬件、操作系統(tǒng)和應用等所有元素。實時操作系統(tǒng)僅僅是構成實時系統(tǒng)的其中一個元素。如需了解更多信息,請參閱微軟Windows CE實時性能設計和優(yōu)化。
我們將介紹諸多工具和用途:
·ILTiming。該工具用于確定平臺的中斷服務例程(ISR)和中斷服務線程(IST)延遲。ISR延遲是指從硬件中斷到第一次中斷服務例程指令之間的時間間隔。而IST延遲是指從現(xiàn)有ISR到中斷服務線程開始之間的時間間隔。
內核實時性能最重要的特性之一,就是可以在指定的時間內實施中斷。中斷延遲主要指軟件中斷處理延遲,即從外部中斷到達處理器直到中斷處理開始之間的時間間隔。
如果不發(fā)生分頁操作,Windows CE中斷延遲時間被限制于內存中鎖定的線程。這樣就可以計算最糟糕情況下的延遲時間 — 到ISR的啟動和到IST的啟動的總用時。通過計算ISR和IST所需時間,可以確定中斷處理以前的總用時。
ISR延遲
ISR延遲是指從IRQ在CUP中被設置到ISR開始運行時的時間。以下三個與時間相關的變量會影響ISR的啟動:
A = 中斷在內核中關閉的最長時間。內核很少關閉中斷,但如果將它們關閉,則關閉的時間長度會受到限制。
B = 在內核調度中斷和ISR被實際調用之間的時間。內核使用該時間確定要運行什么ISR,并保存在繼續(xù)之前必須保存的任何寄存器。
C = 在 ISR 返回到內核和內核實際停止處理中斷之間的時間。這是內核通過還原在ISR被調用之前被保存的任何狀態(tài)(例如寄存器)來完成ISR操作的時間。
正在測量的ISR的啟動時間可以基于系統(tǒng)中其他中斷的當前狀態(tài)進行計算。如果中斷正在進行,則計算要測量的新 ISR 的啟動時間必須考慮到兩個因素:所關注的中斷已經發(fā)生之后將發(fā)生的較高優(yōu)先級中斷的數(shù)量,以及執(zhí)行ISR所占用的時間。
Windows CE和原始設備制造商(OEM)都會影響執(zhí)行ISR的時間。Windows CE的控制變量A、B和C都受到限制。
IST延遲
IST延遲是指從完成執(zhí)行ISR即(通知線程)到IST開始執(zhí)行的時間。以下四個與時間相關的變量會影響IST的啟動:
B = 內核調度中斷和真正調用ISR的時間間隔。內核利用這一時間決定將要運行什么ISR,并保存在繼續(xù)之前必須保存的任何寄存器。
C = 在ISR返回到內核和內核實際停止處理中斷之間的時間。這是內核通過還原在ISR被調用之前保存的任何狀態(tài)(例如寄存器)來完成ISR操作的時間。
L = Kcall(內核調用)中的最長時間。
M = 調度線程的時間。
在ISR返回到內核并且內核執(zhí)行某些工作來開始執(zhí)行IST之后最高優(yōu)先級IST開始的啟動時間。在ISR返回并通知IST開始運行之后,IST啟動時間受所有ISR的總計時間的影響。下面的示例說明了所得到的啟動時間:
最高優(yōu)先級IST啟動時間 =
Windows CE和OEM都會影響執(zhí)行IST所需的時間。Windows CE控制變量B、C、L和M都是受限制的。OEM控制NISR和TISR(N),它們可以影響IST延遲。
Windows CE還對IST添加了以下限制:鏈接ISR和IST的事件處理只能用在WaitForSingleObject函數(shù)中。Windows CE防止ISR-IST事件處理被用在WaitForMultipleObjects函數(shù)中,這意味著內核可以擔保觸發(fā)事件的時間和釋放IST的時間有一個上限。
·計劃程序計時分析(OSBench):該工具允許您收集計時樣本,通過執(zhí)行調度性能定時測試,測量內核的性能。
·內核跟蹤程序(Kernel Tracker):此工具可以直觀顯示Windows CE .NET操作系統(tǒng)在目標設備上的執(zhí)行狀況。該工具可用于在實時環(huán)境下查看線程交互、內部關聯(lián)以及系統(tǒng)狀態(tài)信息。本文目的是檢驗線程和進程間的交互作用。
·調用評測程序(Call Profiler):此工具可用于確定代碼的算法瓶頸。
設備中存在許多影響實時性能的因素,如硬件、驅動程序和應用。在本例中,我們從應用級開始。運行于實時環(huán)境中的應用啟動時就應該分配所有資源。所有內核對象(進程、線程、互斥鎖、臨界段、信號和事件)都按照需要分配到虛擬內存中。按需分配內存是不確定的,因此,不能對操作系統(tǒng)完成操作的時間進行限制,所以它不能用于應用的實時執(zhí)行中。
遠程調用評測程序
實時系統(tǒng)不僅包括硬件和操作系統(tǒng),日益增多的應用邏輯也運行于相同的硬件之上。因此,嵌入式設計中的應用代碼可能存在失敗風險。Windows CE不會強行命令IST在設備驅動程序環(huán)境中運行,IST僅是一個特殊的線程,因此在應用環(huán)境中可以運行IST線程。既然如此,該如何檢驗應用代碼的瓶頸呢?當然,這可能會影響設備的整體性能。答案是:這正是Windows CE安裝的工具 - 遠程調用評測程序的功能。該工具可解答下列問題:何時執(zhí)行何種代碼?何謂軟件組件的交互?應用程序運行時,CPU在做什么?
為了證明這一點,我采用構建、運行在Windows CE上的“哲學家就餐問題”應用。以下是解決過程:現(xiàn)在,五位哲學家(線程)圍坐在圓桌前。每人面前放著一碗食物。哲學家們用一支筷子開始吃飯。哲學家就餐的前提是他必須有兩支筷子(因此,五位哲學家中必須有一人奉獻出一支筷子)。這時,哲學家就必須找到一種能夠共享筷子的方法,以保證大家都能吃到碗中的食物。
同樣地,當多線程程序中有一個以上的線程(哲學家)競爭資源(食物)時,就有可能發(fā)生死鎖或爭執(zhí),當然這要取決于哲學家的饑餓程度!如果多個線程都在等待使用稀缺資源,就會造成等待時間的不確定性,進而凍結所有應用。對實時應用而言,這并不是個難題,您可以選擇遠程調用評測程序運行應用就可以解決該問題。
遠程調用評測程序可以在不同視圖中顯示調用信息,包括直觀的調用圖表。它會顯示應用運行每個函數(shù)時花費的時間。顯而易見,這是處理視頻/音頻流的實時壓縮/解壓縮問題的最為有效的工具。下表顯示的是遠程調用評測程序應用中的視圖。
表1. 遠程調用評測程序中的視圖
下圖顯示的是哲學家應用的調用圖表視圖。此圖顯示,35%的應用時間花費在函數(shù)Eat( ) 上。也許應該了解一下函數(shù)的內容!
圖1. 遠程調用評測程序
您也許會問,要運行遠程調用評測程序,需要向應用代碼中添加什么。實際上,您根本無需更改所有代碼,而僅需要用其它標志函數(shù)(WINCECALLCAP=1)進行編譯。
調用評測庫為應用開發(fā)人員提供了一幅獨特的應用邏輯執(zhí)行過程細節(jié)圖。將該工具用于低速測試過程,以培養(yǎng)客戶對應用代碼的信任感。
內核跟蹤程序(Kernel Tracker):
遠程內核跟蹤程序可用于檢測運行設備上的進程、線程和中斷之間的交互作用關系。下面是一些內核跟蹤程序中集成的樣本代碼。實例中的應用運行的是Windows CE設備的文件系統(tǒng),其中一個文件夾在臺式機放置釋放文件,此應用為駐留在臺式機中的每個文件生成了一個KITL(內核獨立傳輸層)中斷。因此,我們可以在運行的操作系統(tǒng)鏡像中清晰地觀察應用與中斷間的交互作用,也可以確定應用線程運行與KITL中斷處理間的時間增量。
作為一個用戶界面,內核跟蹤程序被劃分為三個區(qū)域,左窗格顯示中斷和進程,中窗格顯示線程/進程間的交互作用,右窗格(未顯示字)中的內容是對中窗格使用的符號的解釋。我們可以在鏡像底部清楚地看到WalkTree應用正在運行,但看不到在應用和內核環(huán)境中花費的時間。
圖2. 遠程內核跟蹤程序用戶界面
內核跟蹤程序可以在事件間設置時間標記,并能在狀態(tài)欄上顯示不同的時間。內核跟蹤程序有一些預先定義的事件,如同步事件、混合事件和用戶定義事件等。此外,它還能顯示線程狀態(tài)(如運行、鎖定、休眠和移植等)。在下圖中,當從內核返回到線程執(zhí)行時,我們設置了第一個時間標記,而當從線程環(huán)境切換到內核時,我們設置了第二個時間標記。
圖3. 遠程內核跟蹤程序 — 時間增量
內核跟蹤程序工具可用于定位和檢測死鎖情況,還可以檢測花費在應用和驅動程序線程上的時間。運行內核跟蹤程序也許將使系統(tǒng)用時增加2%-3%,但不會影響操作系統(tǒng)的整體定時。
計劃程序計時分析
該程序為操作系統(tǒng)環(huán)境的擴展集提供了測試標準。該擴展集來自超出Protected Server Library (PSL)的內部調用,而這種調用則來自集成到操作系統(tǒng)其中一個進程的應用(如FileSys.exe、Device.exe等)。該測試分為以下7個基本組:
1.臨界段
2.事件設置-喚醒
3.信號發(fā)出-接收
4.互斥鎖
5.自動放棄率
6.PSL API調用開銷
7.互鎖API(遞減、遞增、測試交換、交換)
我們來看一下幾項測試結果:
===================================================================
| 0.01 | IP = NO | CS = NO | 1 IPS
-------------------------------------------------------------------
EnterCriticalSection traditional (blocking) without priority inversion :
Time from a higher priority thread calling EnterCS (blocked) to a lower
priority runnable thread getting run
-------------------------------------------------------------------
| Max Time = 13.409 μs
| Min Time = 7.543 μs
| Avg Time = 8.389 μs
====================================================================
===================================================================
| 0.02 | IP = NO | CS = NO | 1000 IPS
-------------------------------------------------------------------
EnterCriticalSection fastpath (uncontested)
-------------------------------------------------------------------
| Subtracting out base result of 12 ticks
| Max Time = 0.064 μs
| Min Time = 0.061 μs
| Avg Time = 0.061 μs
===================================================================
將這些測試結果與花費在處理EnterCrticalSection()函數(shù)調用上的時間進行比較。調用此函數(shù)的途徑有兩種。第一種方法較快捷,就是通過使用臨界段,實施向內核轉移,來解決資源爭用問題。第二種方法貫穿整個調用進程,其時因為不存在臨界段爭用問題,因而速度明顯提升。(此例可以解釋為什么臨界段是同步的首要考慮因素。)
中斷計時分析(ILTIMING)
中斷計時分析可以測量系統(tǒng)中的中斷延遲。該工具使用諸多OAL(OEM適配層)支持功能測量ISR和IST的中斷響應時間。這些數(shù)字對于了解系統(tǒng)的限制至關重要。
我們來看一看基于AMD K6 500Mhz的CEPC系統(tǒng)的數(shù)字。
表3. dwOEMTPoolSize = 16 (CEPC的出廠默認值)
在此插入文件結束標識>Windows CE和硬實時操作系統(tǒng)的OMAC定義吻合,它安裝了構建、測試和部署實時設備所需的工具及資源。所有這些工具:內核跟蹤程序、遠程調用評測程序、計劃程序計時分析和中斷計時分析協(xié)同工作,可以幫助您在自己的平臺上對Windows CE的實時能力進行評估。
如需了解更多信息,請閱讀:
.NET Compact Framework的實時性能
Maarten Struys
Michel Verhagen
PTS軟件
http://msdn.microsoft.com/library/en-us/dncenet/html/Real-Time_NETCF.asp
專用系統(tǒng),Windows CE 5.0實時x86處理器
http://download.microsoft.com/download/7/2/f/72fef3b0-9545-46a4-8886-a94f265df9c4/EVA-2.9-TST-CE-x86-01-Iss1.00.pdf
專用系統(tǒng),Windows CE 5.0實時ARM處理器
http://download.microsoft.com/download/7/2/f/72fef3b0-9545-46a4-8886-a94f265df9c4/EVA-2.9-OS-CE-01-I01.pdf
就Windows CE 5.0 Real-Time Podcast采訪Windows CE架構師John Eldridge
http://blogs.msdn.com/mikehall/archive/2005/09/01/459443.aspx
Windows CE的實時決定論(Real-Time Determinism)
網站首頁 |網站簡介 | 關于我們 | 廣告業(yè)務 | 投稿信箱
Copyright © 2000-2020 m.netfop.cn All Rights Reserved.
中國網絡消費網 版權所有 未經書面授權 不得復制或建立鏡像
聯(lián)系郵箱:920 891 263@qq.com