J. U
łasiewicz Programowanie aplikacji współbieżnych 1
Miary-efektywno
ści-RTS1.doc
1 Ewaluacja 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 all
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)
Kryteria ilo
ściowe oceny systemów czasu rzeczywistego.
•
Najd
łuższy czas odpowiedzi na zdarzenie – (ang. Worst-case
response times to occurring events)
•
Najd
łuższy czas wykrycia i skorygowania błędów – (ang. Worst-
case time to detect and correct errors)
•
Średni czas między uszkodzeniami - MTBF,
•
Rezerwa mocy przetwarzania
•
Koszt
PDF created with pdfFactory trial version
www.pdffactory.com
J. U
łasiewicz Programowanie aplikacji współbieżnych 2
Miary-efektywno
ści-RTS1.doc
1.1 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.1.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 obs
ługi przerwania
PDF created with pdfFactory trial version
www.pdffactory.com
J. U
łasiewicz Programowanie aplikacji współbieżnych 3
Miary-efektywno
ści-RTS1.doc
Czas opó
źnienia 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.
Rys. 1-2 Czas opó
źnienia przerwania dla różnych systemów
czasu rzeczywistego (Pentium 200 MHz) wg. Dedicated Systems
PDF created with pdfFactory trial version
www.pdffactory.com
J. U
łasiewicz Programowanie aplikacji współbieżnych 4
Miary-efektywno
ści-RTS1.doc
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
8
9
10
11
12
13
14
15
16
0
100
200
300
400
500
600
700
800
900
1000
Numer próbki
C
z
as
[ µ
s
]
Rys. 1-4 Czas reakcji na przerwanie systemie QNX 6 Neutrino bez
obci
ążenia - 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-RTS1.doc
10
11
12
13
14
15
16
17
18
0
100
200
300
400
500
600
700
800
900
1000
Numer próbki
C
z
a
s
[
µ
s
]
Rys. 1-5 Czas reakcji na przerwanie systemie QNX 6 Neutrino pod
obci
ążeniem - praca dypl. Łukasz Biały
Rys. 1-6 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-RTS1.doc
1.1.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ń.
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-7 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-RTS1.doc
Rys. 1-8 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-RTS1.doc
1.1.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-9 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
1.1.4 Opó
źnienie szeregowania (ang. Scheduling Latency)
Opó
źnienie szeregowania (ang. scheduling latency)
Opó
źnienie szeregowania jest czasem który upływa pomiędzy
wykonaniem ostatniej instrukcji procedury obs
ługi przerwania a
wykonaniem pierwszej instrukcji przerwanego w
ątku lub też
nast
ępnego gotowego wątku w kolejce.
PDF created with pdfFactory trial version
www.pdffactory.com
J. U
łasiewicz Programowanie aplikacji współbieżnych 9
Miary-efektywno
ści-RTS1.doc
W tym czasie system wykonuje nast
ępujące czynności:
1. Szeregowanie w
ątków.
2. Wznowienie przerwanego lub te
ż innego wątku.
P1
ISR - Procedura
obslugi
przerwania
Przerwanie
ISR
P2
Wznowienie
procesu P2
decyzja
szereguj
ąca
Zawiadomienie
Czas szeregowania
Rys. 1-10 Ilustracja czasu szeregowania
Procesor
Opó
źnienie
przerwania
[
µ
s]
Opó
źnienie
szeregowania
[
µ
s]
166 MHz Pentium
4.3
3.1
100 MHz Pentium
4.4
3.9
100 MHz 486DX4
5.6
8
33 MHz 386EX
22.5
26
Tabela 1-1 Niektóre parametry czasowe systemu QNX6 Neutrino
1.1.5 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.
PDF created with pdfFactory trial version
www.pdffactory.com
J. U
łasiewicz Programowanie aplikacji współbieżnych 10
Miary-efektywno
ści-RTS1.doc
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.1.6 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 11
Miary-efektywno
ści-RTS1.doc
1.1.7 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-11 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 12
Miary-efektywno
ści-RTS1.doc
1.1.8 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-12 Ilustracja czasu T likwidacji inwersji priorytetów
Czas likwidacji zakleszczenia 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.
1.1.9 Przepustowo
ść komunikacji międzyzadaniowej
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).
PDF created with pdfFactory trial version
www.pdffactory.com
J. U
łasiewicz Programowanie aplikacji współbieżnych 13
Miary-efektywno
ści-RTS1.doc
1.2 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-RTS1.doc
1.1.10
Oszacowanie trójwymiarowe
Bierze si
ę pod uwagę:
•
MIPS1 - Liczba milionów operacji na sekund
ę
•
MIPS2 - Liczba milionów przerwa
ń na sekundę
•
NIOPS - Liczba milionów operacji we/wy na sekund
ę
Wynik = (MIPS1 * MIPS2 * NIOPS)
1/3
1.1.11
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
PDF created with pdfFactory trial version
www.pdffactory.com
J. U
łasiewicz Programowanie aplikacji współbieżnych 15
Miary-efektywno
ści-RTS1.doc
(
)
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.1.12
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:
•
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.
PDF created with pdfFactory trial version
www.pdffactory.com
J. U
łasiewicz Programowanie aplikacji współbieżnych 16
Miary-efektywno
ści-RTS1.doc
1.1.13
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. Zostały one podzielone na pięć serii testowych
sk
ładających się z kilku eksperymentów. Każda seria uruchamia
inne procesy:
1. Cykliczne zadania, harmoniczne cz
ęstotliwości,
2. Cykliczne zadania, nieharmoniczne cz
ęstotliwości,
3. Cykliczne zadania, harmoniczne cz
ęstotliwości z niecyklicznym
przetwarzaniem,
4. Cykliczne zadania, harmoniczne cz
ęstotliwości z
synchronizacj
ą,
5. Cykliczne zadania, harmoniczne cz
ęstotliwości z niecyklicznym
przetwarzaniem i synchronizacj
ą
Dla ka
żdej serii został określony „zestaw podstawowych
zada
ń”, ze ściśle określonym obciążeniem obliczeniowym,
ograniczeniami czasowymi oraz d
ługością okresu. Przy każdej
nast
ępnej iteracji, zmieniane są parametry lub zwiększane jest
obci
ążenie procesora. Raz uruchomiony test działa, dopóki nie
zostanie przekroczony który
ś z terminów albo przewidziany czas
odpowiedzi. Wynikiem poszczególnej serii testów, jest zestaw
parametrów, dla których program zako
ńczył swoje działanie oraz
najwy
ższe zarejestrowane obciążenie obliczeniowe.
PDF created with pdfFactory trial version
www.pdffactory.com
J. U
łasiewicz Programowanie aplikacji współbieżnych 17
Miary-efektywno
ści-RTS1.doc
Dok
ładna interpretacja tak otrzymanych wyników pozwala na
ocen
ę całej platformy, zarówno sprzętu jaki i oprogramowania
systemowego, przydatno
ści do użytku z aplikacjami czasu
rzeczywistego. Podczas gdy Hartstone zosta
ł zaprojektowany
z my
ślą o pojedynczo-procesorowych systemach. W późniejszym
czasie zosta
ł rozszerzony o możliwość pomiaru systemów
rozproszonych.
1.2
Ż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.
PDF created with pdfFactory trial version
www.pdffactory.com