J. U
łasiewicz Programowanie aplikacji współbieżnych 1
Miary-efektywno
ści-RTS3.doc
1 Ewaluacja systemów czasu rzeczywistego
1.1 Kryteria oceny systemów czasu rzeczywistego
Kryteria jako
ściowe stopniowalne oceny systemów czasu
rzeczywistego.
•
Bezpiecze
ństwo (ang. Safety)
•
Dyspozycyjno
ść – (ang. Dependability)
•
Przewidywalno
ść, nawet w przypadku wystąpienia błędów –
(ang. Behavioural predictability, even in error situations)
•
Prostota – (ang. simplicity - the simpler the better)
•
Niezawodno
ść - (ang. Reliability)
•
Odporno
ść – (ang. Robustness)
•
Tolerowanie b
łędów - (ang. Fault tolerance)
•
W
łasność stopniowej degradacji w przypadku wystąpienia
niesprawno
ści - (ang. Graceful degradation upon malfunctions)
•
Przeno
śność – (ang. Portability)
•
Elastyczno
śc – (ang. Flexibility)
Kryteria jako
ściowe binarne oceny systemów czasu rzeczywistego.
•
Spe
łnienie ograniczeń czasowych – (ang. ability to meet
deadlines)
•
Brak nieograniczonych w czasie opó
źnień i czasów wykonania
– (ang. no unbounded delays nor arbitrarily long executions)
•
Licencje bezpiecze
ństwa – (ang. safety license)
•
Poprawno
ść funkcjonalna – (ang. functional correctness)
•
Deterministyczne zachowanie – (ang. deterministic behaviour)
•
Spe
łnienie ograniczeń fizycznych – (ang. physical constraints
met)
•
Zapobieganie zakleszczeniom – (ang. deadlocks prevented)
Ogólne kryteria ilo
ściowe oceny systemów czasu rzeczywistego.
•
Najd
łuższy czas odpowiedzi na zdarzenie – (ang. Worst-case
response times to occurring events). Wyst
ępuje w różnych
odmianach w zale
żności od typu zdarzenia.
•
Najd
łuższy czas wykrycia i skorygowania błędów – (ang. Worst-
case time to detect and correct errors) Wyst
ępuje w różnych
odmianach w zale
żności od typu błędu
•
Koszt
PDF created with pdfFactory trial version
www.pdffactory.com
J. U
łasiewicz Programowanie aplikacji współbieżnych 2
Miary-efektywno
ści-RTS3.doc
1.2 Ilo
ściowe miary efektywności systemów operacyjnych
czasu rzeczywistego
Prezentowane dalej wyniki dotycz
ą systemów:
•
QNX6 Neutrino
•
Linux PREEMPT_RT
Linux PREEMPT_RT
Linux PREEMPT_RT jest projektem rozwijanym przez Ingo
Molnar’a (RedHat) oraz Thomas’a Gleixner’a. Jest to
łatka która
modyfikuje j
ądro Linux’a, w taki sposób aby stało się w pełni
wyw
łaszczane. Dokonano tego poprzez zamianę „spinlocków” w
j
ądrze na wywłaszczane „rtmuteksy”, przez co sekcje krytyczne
staja si
ę wywłaszczane. Wprowadza także obsługę Timerów
POSIX o wysokiej rozdzielczo
ści. Dzięki temu otrzymano
rygorystyczny system czasu rzeczywistego.
Testy wykonane na procesorze Intel Pentium IV Mobile o
cz
ęstotliwości 2 GHz.
1.2.1 Czas opó
źnienia przerwania
Czas opó
źnienia przerwania (ang. Interrupt Latency) jest to czas
pomi
ędzy wystąpieniem przerwania a wykonaniem pierwszej
instrukcji procedury obs
ługi tego przerwania (ang. Interrupt Service
Routine – ISR).
P1
ISR - Procedura
obslugi przerwania
Przerwanie
Start ISR
ISR
Interrupt
Latency
P1
Kontynuacj
a procesu
P1
Stop ISR
Rys. 1-1 Ilustracja czasu opó
źnienia obsługi przerwania
PDF created with pdfFactory trial version
www.pdffactory.com
J. U
łasiewicz Programowanie aplikacji współbieżnych 3
Miary-efektywno
ści-RTS3.doc
Czas opó
źnienia obsługi przerwania zależy od następujących
czynników:
1. Zablokowania przerwa
ń - przerwania w procesorze mogą być
chwilowo zablokowane przez inny w
ątek lub handler w celu
ochrony sekcji krytycznych.
2. Obs
ługi innych przerwań - kontroler przerwań może nie
dopu
ścić do przyjęcia przerwania gdyż przerwanie o wyższym
priorytecie jest w trakcie obs
ługi
Czas opó
źnienia przerwania zależy od aktualnego stanu systemu.
Przerwania w danym momencie czasu mog
ą być zablokowane lub
te
ż nie. W związku z tym definiuje się maksymalny czas
opó
źnienia przerwania.
Maksymalny czas opó
źnienia przerwania (ang. worst case
interrupt latency)
Maksymalny czas opó
źnienia przerwania to czas opóźnienia
przerwania otrzymany dla najmniej korzystnego przypadku.
W systemie operacyjnym czasu rzeczywistego najd
łuższy
czas w którym przerwania pozostaj
ą zablokowane powinien być
jak najkrótszy.
PDF created with pdfFactory trial version
www.pdffactory.com
J. U
łasiewicz Programowanie aplikacji współbieżnych 4
Miary-efektywno
ści-RTS3.doc
Rys. 1-2 Czas opó
źnienia przerwania dla różnych systemów
czasu rzeczywistego (Pentium 200 MHz) wg. Dedicated Systems
Przypadek
Maksymalny
czas [µs]
Średni czas [µs]
System nie obci
ążony
14,807
12,339
System obci
ążony
17,194
14,640
Rys. 1-3 Czas reakcji na przerwanie systemu QNX6 Neutrino -
praca dypl.
Łukasz Biały
PDF created with pdfFactory trial version
www.pdffactory.com
J. U
łasiewicz Programowanie aplikacji współbieżnych 5
Miary-efektywno
ści-RTS3.doc
Rys. 1-4 Histogram czasu reakcji na przerwanie w systemie QNX6
Neutrino – praca dypl.
Łukasz Biały
PDF created with pdfFactory trial version
www.pdffactory.com
J. U
łasiewicz Programowanie aplikacji współbieżnych 6
Miary-efektywno
ści-RTS3.doc
1.2.2 Czas prze
łączania kontekstu
Czas prze
łączania zadań (ang. task switch time) jest to czas, w
którym system operacyjny jest w stanie prze
łączyć aktualnie
wykonywane zadanie na inne zadanie w systemie o tym samym
priorytecie. Na ten czas sk
łada się czas potrzebny na zachowanie
kontekstu procesu bie
żącego P1 i odtworzenie kontekstu procesu
P2 podlegaj
ącego zaszeregowaniu.
D
ługość czasu przełączania zadań uzależniona jest od:
•
Z
łożoności struktur danych opisujących zadania
•
Efektywno
ści procedur zmieniających kontekst zadań.
•
Efektywno
ści algorytmu szeregowania
Poniewa
ż pomiar dokonywany jest dla zadań o równym
priorytecie, wymaga si
ę aby system realizował odpowiedni
algorytm szeregowania, który przydziela
ć będzie czas procesora
pomi
ędzy zadania o najwyższym priorytecie. Przykładem takiego
algorytmu jest FIFO (ang. First In First Out) lub algorytm
karuzelowy RR.
P1
Context
Switching
Latency
P2
Wznowienie
procesu P2
Zawieszenie
procesu P1
Rys. 1-5 Ilustracja czasu prze
łączenia kontekstu
PDF created with pdfFactory trial version
www.pdffactory.com
J. U
łasiewicz Programowanie aplikacji współbieżnych 7
Miary-efektywno
ści-RTS3.doc
Rys. 1-6 Czas prze
łączenia kontekstu dla różnych systemów
czasu rzeczywistego (Pentium 200 MHz) – wg. Dedicated Systems
System
Ilo
ść
w
ątków
Maksymalny
czas [µs]
Średni czas[µs]
2
7,527
0,722
10
9,149
0,734
QNX 6 Neutrino
128
10,737
0,745
2
45,906
2,234
10
46,244
2,270
PREEMPT_RT
128
47,802
2,286
Tab. 1-1 Wyniki pomiarów czasu prze
łączania wątków – praca
dypl.
Łukasz Biały
PDF created with pdfFactory trial version
www.pdffactory.com
J. U
łasiewicz Programowanie aplikacji współbieżnych 8
Miary-efektywno
ści-RTS3.doc
1.2.3 Czas wyw
łaszczania
Czas wyw
łaszczania (ang. preemption time) jest to średni czas
potrzebny na wyw
łaszczenie zadania o niższym priorytecie, przez
zadanie o wy
ższym priorytecie.
Rys. 1-7 Ilustracja czasu wyw
łaszczenia tp procesu T1 o niższym
priorytecie przez proces T2 o priorytecie wy
ższym
Na czas ten sk
łada się:
1. Czas opó
źnienia przerwania
2. Podj
ęcie decyzji szeregującej
3. Czas zachowanie kontekstu procesu bie
żącego i
przywrócenia kontekstu procesu wyw
łaszczającego
PDF created with pdfFactory trial version
www.pdffactory.com
J. U
łasiewicz Programowanie aplikacji współbieżnych 9
Miary-efektywno
ści-RTS3.doc
P1
Start procedury obslugi
przerwania
Przerwanie
System operacyjny
P2
Uruchomienie
procesu P2
Czas przel
ączenia kontekstu
Priorytet procesu P1 < Priorytet procesu P2
Czas
Rys. 1-8 Ilustracja czasu wyw
łaszczenia
1.2.4 Czas utworzenia i ko
ńczenia nowego zadania
Czas utworzenia nowego zadania (ang. Task creation and
termination
) to
czas potrzebny do stworzenia nowego zadania oraz
do usuni
ęcia istniejącego zadania. Są to dwie bardzo istotne
operacje dla wielozadaniowego systemu czasu rzeczywistego.
System
Maksymalny czas
[µs]
Średni czas[µs]
QNX 6 Neutrino
72,254
56,144
PREEMPT_RT
497,243
61,995
Tab. 1-2 Czas tworzenia i usuwania w
ątków
1.2.5 Czas inicjalizacji systemu
Czas inicjalizacji systemu (ang.
Initialisation time
) to czas
mierzony od momentu uruchomienia systemu do momentu
uzyskania przez system operacyjny pe
łnej funkcjonalności. W
przypadku awarii, restartu system powinien by
ć gotowy do pracy
tak szybko jak to tylko mo
żliwe.
PDF created with pdfFactory trial version
www.pdffactory.com
J. U
łasiewicz Programowanie aplikacji współbieżnych 10
Miary-efektywno
ści-RTS3.doc
1.2.6 Czas prze
łączenia semafora
Czas prze
łączenia semafora (ang. Semaphore shuffling time) to
średni czas pomiędzy zwolnieniem semafora przez aktualnie
wykonywane zadanie, a uruchomieniem pierwszej instrukcji
zadania oczekuj
ącego na ten semafor. Czas ten zależy głównie od
sposobu implementacji mechanizmu semaforów w danym
systemie operacyjnym. W systemie czasu rzeczywistego, gdzie
wiele aplikacji korzysta ze wspólnych zasobów, krótki czas
operacji semaforowych jest bardzo wa
żnym czynnikiem.
Rys. 1-9 Ilustracja czasu prze
łączenia semafora
System
Obci
ążenie
Maksymalny
czas [µs]
Średni czas[µs]
NIE
7,862
1,021
QNX 6 Neutrino TAK
10,653
1,049
PREEMPT_RT
NIE
53,135
10,167
Tab. 1-3 Wyniki pomiarów czasu operacji semaforowych - praca
dypl.
Łukasz Biały
PDF created with pdfFactory trial version
www.pdffactory.com
J. U
łasiewicz Programowanie aplikacji współbieżnych 11
Miary-efektywno
ści-RTS3.doc
1.2.7 Czas likwidacji inwersji priorytetów (ang. deadlock breaking
time)
Sytuacj
ę, w której zadanie o wyższym priorytecie wywłaszczy
zadanie o ni
ższym priorytecie, które przetrzymuje zasób
wymagany przez zadanie o wy
ższym priorytecie, nazywamy
inwersj
ą priorytetów. Czas likwidacji inwersji jest to średni czas, w
którym system sobie poradzi z inwersj
ą.
W3
odblokowanie
w
ątek W1
priorytet 1
w
ątek W2
priorytet 2
w
ątek W3
priorytet 3
zablokowany
T
Czas
t5
t1
t2
W3 mutex_lock()
t3
W2 wyw
łaszcza
W1
t4
W1 mutex_lock()
t0
1
W1 wznowiony
3
1
2
W2 blokuje si
ę
1
W1 mutex_unlock()
3
W3 mutex_unlock()
t6
t7
t8
Z1
Z2
Z3
priorytet 1 < priorytet 2 < priorytet 3
Rys. 1-10 Ilustracja czasu T likwidacji inwersji priorytetów
Czas likwidacji inwersji priorytetów to czas pomi
ędzy zażądaniem
zasobu przez w
ątek o najwyższym priorytecie a jego otrzymaniem.
Zale
ży on od jakości mechanizmu zapobiegania inwersji
priorytetów.
PDF created with pdfFactory trial version
www.pdffactory.com
J. U
łasiewicz Programowanie aplikacji współbieżnych 12
Miary-efektywno
ści-RTS3.doc
1.2.8 Czas opó
źnienia przesyłania komunikatów
Czas opó
źnienia przesyłania komunikatów (ang. intertask
message latency) to czas jaki mija pomi
ędzy wysłaniem
komunikatu przez jeden proces P1 a odbiorem komunikatu przez
inny proces P2. Przepustowo
ść komunikacji międzyzadaniowej
(ang. Datagram throughput ) to ilo
ść bajtów na sekundę, jakie
mog
ą zostać przesłane pomiędzy dwoma zadaniami przy pomocy
komunikatów (ang. Message passing).
P1
Czas opó
żnienia
komunikatu
P2
Procesu P2 odbiera
komunikat
Proces P1 wysyla
komunikat
Rys. 1-11 Czas opó
źnienia przesyłania komunikatów
PDF created with pdfFactory trial version
www.pdffactory.com
J. U
łasiewicz Programowanie aplikacji współbieżnych 13
Miary-efektywno
ści-RTS3.doc
Testy
Testy (ang. benchmark) to programy lub zestawy programów
1
,
które zosta
ły wybrane lub zaprojektowane w celu testowania i/lub
pomiaru wydajno
ści obliczeniowej systemów informatycznych.
Powinny one pomaga
ć podczas projektowania systemu lub w
podj
ęciu decyzji o zakupie danego systemu informatycznego.
Kelvin Obenland podzieli
ł zestaw kryteriów porównawczych,
istotnych dla systemów zgodnych z POSIX, na dwie kategorie.
•
Testy które mierz
ą determinizm danego systemu operacyjnego,
•
Testy które mierz
ą opóźnienia szczególnie ważnych operacji
Pierwsza kategoria oprogramowania mierzy czas odpowiedzi
systemu, rozstrzyga czy w
ątki działają w sposób przewidywalny.
Druga kategoria mierzy czas zmiany kontekstu pomi
ędzy wątkami
i procesami. Mierzy przepustowo
ść danych pomiędzy procesami i
w
ątkami oraz opóźnienie sygnałów POSIX.
Szerzej znane s
ą następujące testy:
•
Oszacowanie trójwymiarowe
•
Rhealstones
•
MiBench
•
Hardstones
PDF created with pdfFactory trial version
www.pdffactory.com
J. U
łasiewicz Programowanie aplikacji współbieżnych 14
Miary-efektywno
ści-RTS3.doc
1.2.9 Oszacowanie trójwymiarowe
Bierze si
ę pod uwagę:
•
MIPS1 - Liczba wykonanych operacji (w milionach na sekund
ę)
•
MIPS2 - Liczba obs
łużonych przerwań (w milionach na
sekund
ę)
•
NIOPS - Liczba wykonanych operacji we/wy (w milionach na
sekund
ę)
Wynik = (MIPS1 * MIPS2 * NIOPS)
1/3
PDF created with pdfFactory trial version
www.pdffactory.com
J. U
łasiewicz Programowanie aplikacji współbieżnych 15
Miary-efektywno
ści-RTS3.doc
1.2.10
Rhealstone
Rhealstone jest zestawem sze
ściu programów napisanych w
j
ęzyku C. Każdy z nich mierzy czas operacji charakterystycznej dla
systemów czasu rzeczywistego:
1. Czas prze
łączenia zadań - task-switch time,
2.
Czas wyw
łaszczenia - preemption time,
3.
Czas opó
źnienia przerwania - interrupt latency ,
4.
Czas prze
łączenia semafora - semaphore-shuffle time,
5.
Czas likwidacji zakleszczenia - deadlock-break time,
6.
Opó
źnienie przesyłania komunikatów - intertask message
latency.
Z otrzymanych czasów obliczana jest warto
ść średnia na
podstawie wzoru:
(
)
6
/
6
5
4
3
2
1
t
t
t
t
t
t
t
+
+
+
+
+
=
Czasy wyra
żone są w sekundach. Tak zwaną wartość Rhealstone
definiujemy jako odwrotno
ść wyliczonej średniej
t
1
Im wi
ększa jest wartość tym system szybszy.
Wady testu Rhealstones:
•
Mierzy warto
ści średnie a nie dla najgorszego przypadku.
•
Wynik jest sum
ą ważoną składników, nie ma jednoznacznych
ustale
ń co do wag.
1.2.11
MiBench
MiBench jest zestawem 35 aplikacji typowych dla systemów
wbudowanych. Zosta
ły one podzielone na sześć zestawów, z
których ka
żdy celuje w specyficzny obszar systemów
wbudowanych:
PDF created with pdfFactory trial version
www.pdffactory.com
J. U
łasiewicz Programowanie aplikacji współbieżnych 16
Miary-efektywno
ści-RTS3.doc
•
sterowania motoryzacyjnego i przemys
łowego,
•
urz
ądzeń konsumenckich,
•
automatyki biurowej,
•
sieciowy,
•
bezpiecze
ństwa,
•
telekomunikacyjny.
Źródła wszystkich programów dostępne są w standardowym
j
ęzyku C. Dzięki temu kod jest w pełni przenośny i może zostać
skompilowany prawie na ka
żdej platformie. Dostępne są również
dedykowane zbiory danych do poszczególnych testów. Do
testowania systemów rygorystycznych nadaje si
ę jedynie pierwszy
zestaw.
1.2.12
Hartstone
Test Hartstone zosta
ł zaprojektowany w celu sprawdzenia
wymogów czasowych rygorystycznych systemów czasu
rzeczywistego. Ca
łość napisana w języku ADA na uniwersytecie
Carnegie Mellon. Nazwa testu pochodzi od angielskiego
okre
ślenia systemów rygorystycznych „HArd Real-Time” .
Hartstone, zosta
ł określony jako duża liczba małych procesów z
dok
ładnie określonym obciążeniem procesora jak i terminami
zako
ńczenia. Interpretacja testu Hardstone pozwala na ocenę
ca
łej platformy, zarówno sprzętu jaki i oprogramowania
systemowego, przydatno
ści do użytku z aplikacjami czasu
rzeczywistego. Test Hartstone zosta
ł zaprojektowany z myślą o
pojedynczo-procesorowych systemach. W pó
źniejszym czasie
zosta
ł rozszerzony o możliwość pomiaru systemów
rozproszonych.
PDF created with pdfFactory trial version
www.pdffactory.com
J. U
łasiewicz Programowanie aplikacji współbieżnych 17
Miary-efektywno
ści-RTS3.doc
1.3 Certyfikaty
Certyfikaty stanowi
ą pewien rodzaj referencji i mogą pomóc przy
wyborze systemu operacyjnego.
Norma ISO 9001:2000
Dotyczy zarz
ądzania jakością oferowanych usług oraz produktów i
definiuje wszystko od odpowiedzialno
ści kierownictwa, przez
zarz
ądzanie zasobami aż do realizacji wyrobu. Certyfikat nadany
przez ISO gwarantuje ona powtarzalno
ść procesu produkcji, a
tak
że ciągłe ulepszanie produktów i usług na rzecz zadowolenia
klientów.
POSIX PSE52 Realtime Controller 1003.13-2003
Certyfikat ten nadawany przez IEEE oraz The Open Group
zapewnia zarówno przenoszalno
ść kodu a także spełnia kryteria
czasu rzeczywistego wymagane przez systemy militarne, sieciowe
oraz motoryzacyjne.
Common Criteria (ISO/IEC 15408) EAL4+
Common Criteria to norma pozwalaj
ąca w sposób formalny
weryfikowa
ć bezpieczeństwo systemów teleinformatycznych.
Udost
ępnia ona procedury pozwalające na zdefiniowanie zagrożeń
oraz zabezpiecze
ń, które na te zagrożenia odpowiadają, a
nast
ępnie przeprowadzenie formalnej weryfikacji ich faktycznego
dzia
łania w produkcie. Certyfikacją według normy CC zajmują się
niezale
żne, akredytowane laboratoria badawcze na całym świecie.
Wynikiem procesu certyfikacji jest tzw. "profil ochrony" (PP – ang.
protection profile), który definiuje zabezpieczenia stosowane przez
produkt oraz certyfikat, potwierdzaj
ący ich faktyczną skuteczność.
Proces certyfikacji mo
że być prowadzony według różnych
poziomów szczegó
łowości i weryfikacji formalnej (EAL – ang.
Evaluation Assurance Level), pocz
ąwszy od EAL1 (tylko testy
funkcjonalne) a
ż do EAL7 (formalna weryfikacja projektu oraz
testy).
System QNX Neutrino w wersji 6.4 posiada certyfikat na poziomie
EAL4+. Przeprowadzone testy dotyczy
ły jądra systemu,
przetwarzania wieloprocesorowego oraz bezpiecznego
partycjonowania.
PDF created with pdfFactory trial version
www.pdffactory.com
J. U
łasiewicz Programowanie aplikacji współbieżnych 18
Miary-efektywno
ści-RTS3.doc
IEC Safety Integrity Level (SIL)
Certyfikat nadawany przez IEC (ang. International Electrotechnical
Commision) w zakresie bezpiecze
ństwa systemu. Potwierdza on
najwy
ższą możliwą redukcję ryzyka osiągalną przy używaniu
systemu jednoprocesorowego w takich ga
łęziach przemysłu jak
motoryzacja, przemys
ł ciężki, górnictwo oraz w innym gdzie
bezpiecze
ństwo jest priorytetem. Dla zapewnienia wiarygodności
certyfikat jest regularnie weryfikowany.
System QNX Neutrino spe
łnia wymagania poziomie SIL3 (SIL –
ang. Safety Integrity Level).
1.4
Źródła
[1] Roman Gumzej, Wolfgang A. Halay; Real Time Systems
Quality of Service, wyd Springer 2010.
[2]
Łukasz Biały, Praca dyplomowa, Politechnika Wrocławska
2010.
[3] Micha
ł Stangret, Praca dyplomowa, Ocena wybranych
systemów operacyjnych czasu rzeczywistego, Wroc
ław 2009.
[4] Larisa Rizvanovic, Comparison between Real time Operative
systems in hardware and software. Mälardalens University.
PDF created with pdfFactory trial version
www.pdffactory.com