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