Aktuální vydání

celé číslo

05

2021

Perspektivy automatizace, umělá inteligence v automatizaci; prostředky automatizace v době lockdownu
celé číslo

Porovnávací test operačních systémů reálného času

Automa 8/2000

Ing. Petr Šumbera,
Artisys s. r. o.

Porovnávací test operačních systémů reálného času

V článku je představena metoda porovnávacích testů deterministického chování operačních systémů pracujících v reálném čase a jsou uvedeny a komentovány výsledky získané testováním operačních systémů Free BSD 3.1, Red Hat Linux 6.0, Lynx OS 2.5, Solaris 5.7 a Windows NT 4.0 ve verzích pro procesor Intel.

Operační systém reálného času
Použijeme-li označení operační systém reálného času, popř. zkratku RTOS (Real Time Operating System), máme na mysli operační systém pracující v reálném čase. Nejzákladnějším požadavkem kladeným na takový operační systém je jeho včasná odpověď za všech možných okolností.

Obecně lze systém reálného času definovat jako informační systém, který zpracovává asynchronní vstupy a produkuje odpovědi v pevně stanoveném čase. Doba, kterou má systém k dispozici pro provedení úlohy, je známa předem. Na počtu vstupů a jimi vyvolané pracovní zátěži systému přitom nezáleží.

Volnější definice, která je blízká skutečným systémům, zní: Systém reálného času je takový informační systém, který zpracovává asynchronní vstupy a produkuje odpovědi v rozhodnutém a ohraničeném čase. Tato definice odráží skutečnost, že potřebný čas může být vypočítán ze zátěže systému. Navíc musí být tento čas ohraničený, což  odpovídá pojmu nejdelší možná doba odezvy.

V praxi není vždy nutné použít plně deterministický systém. Proto se systémy reálného času dělí na tzv. tvrdé (systémy hard RT) a měkké (systémy soft RT).

Abstraktní definice systému hard RT je např. takováto: Praktická využitelnost hodnoty výpočtové aktivity klesá u systému hard RT k nule v okamžiku, kdy je dosažena nebo překročena požadovaná doba odezvy. Konkrétní definice zní takto: Požadavky hard RT nutí systém vždy splnit známý časový termín. Systému hard RT (např. systému řízení létajícího prostředku, jaderného reaktoru i mnoha jiných a běžnějších systémů) jsou tedy zadány časové krajní meze, které musí splnit, aby nenastala katastrofická selhání, jako je ztráta životů nebo zařízení.

Naproti tomu v systému soft RT mohou být konkrétní časové okamžiky zmeškány. Příkladem systému soft RT může být systém optimalizující spotřebu paliva v motorovém vozidle.

Princip porovnávacího testu
Použitý porovnávací test byl koncipován jako soubor testovacích úloh, které prověřovaly především komunikační a synchronizační prostředky operačních systémů (OS). Ve snaze o co největší objektivitu testu byl zvolen princip jeden počítač, obdobné nastavení OS, stejné testovací úlohy.

Jeden počítač
Aby byly jejich výsledky vzájemně porovnatelné, byly všechny testy vykonávány na tomtéž počítači s procesorem AMD K6-2 taktovaným frekvencí 300 MHz a s RAM 64 MB.

Nastavení testovaného OS
Všechny testované OS pracovaly v obdobném nastavení. To znamená, že v době testu byl na počítači v chodu pouze testovací program. Samotné testy byly spouštěny v textovém režimu. U systémů Unix/POSIX tedy nebyl v provozu žádný grafický server (např. Xfree86) a u Windows NT byl zapnut celoobrazovkový textový režim. To bylo nutné zvláště kvůli případnému technickému zpomalení (přenos dat po sběrnici), jehož příčinou by mohla být např. grafická karta v portu AGP.

Stejné testovací úlohy
Vzhledem k vzájemným nekompatibilitám testovaných OS (především Windows NT oproti „klonům“ Unixu) nebylo možné mít jeden unikátní testovací program (zdrojový soubor) pro všechny systémy. Vnitřní struktura všech použitých testovacích programů nicméně byla stejná. Rozdíly spočívaly pouze v jiných funkcích rozhraní pro komunikaci, synchronizaci a popř. nastavení priority. Všechny testovací úlohy byly provozovány s maximální možnou prioritou, která byla v rámci systému k dispozici.

Testované vlastnosti RTOS
Z vlastností RTOS byly testovány komunikační a synchronizační prostředky, signály a prostředky pro řízení činnosti programu. Byla měřena doba, kterou systém potřeboval k vykonání dále jednotlivě specifikovaných úloh.

Komunikační prostředky
Prostředky určené pro přenos zpráv byly testovány v rámci komunikace mezi dvěma procesy, kdy proces „potomka“ zasílal zprávy „rodičovskému“ procesu. Celkem byl zaslán jeden milión zpráv, každá po 100 bytech. Tento postup byl uplatněn při testu všech prostředků, jak jsou uvedeny v tab. 1.

Tab. 1. Seznam testovaných komunikačních prostředků

Prostředek Definice podle Obousměrný přenos Poznámky
roury Posix 1003.1, Win32API ne  
pojmenované roury Posix Posix 1003.1 ne  
pojmenované roury Win Win32API ano pracují i po síti
BSD schránky BSD ano test přes socketpair
zprávy SV System V ano  
fronty zpráv Posix 1003.1b ano  

Obr. 1.

Synchronizační prostředky
Ze synchronizačních prostředků byly testovány číselné semafory (System V, Posix 1003.1b, Win32API) a binární semafory – mutexy (Posix 1003.1b, Win32API). Test v obou případech postupoval stejným způsobem tak, že v rámci jednoho procesu bylo opakováno zamykání a odemykání (celkem deset miliónů opakování).

Signály
Signály (Posix 1003.1) a signály RT (Posix 1003.1b), které se používají ke komunikaci i k synchronizaci, byly testovány pomocí dvou procesů a zasílání signálů mezi nimi způsobem syn -> otec, otec -> syn, syn ->otec atd. (obr. 1). Každý proces zaslal při testu celkem pět set tisíc signálů.

Prostředky pro řízení činnosti programu
V této kategorii byly testovány procesy a vlákna. U procesů byla testována rychlost vytváření, a to pomocí tzv. klonování. Proces se rozdvojil a stejně tak se choval i nově vytvořený proces potomka (obr. 2). Toto se opakovalo až do hloubky zanoření 100. Z popsaného principu je zřejmé, že tento test nemohl být uskutečněn u Windows NT, kde v rámci Win32API není k dispozici klasická funkce rozdvojení (fork).

Obr. 2.

U vláken byla testována rychlost jejich přepínání. Aktivní vlákno v  procesu se dvěma vlákny předčasně předává činnost ve prospěch ostatních vláken (např. pomocí funkce sched_yield). Tímto způsobem byl realizován jeden milión přepnutí.

Výsledky
Porovnávacímu testu byly podrobeny operační systémy Free BSD 3.1, Red Hat Linux 6.0, Lynx OS 2.5, Solaris 5.7 a Windows NT 4.0. Ve všech případech šlo o verzi systému pro procesor Intel.

Výsledky testování jsou seřazeny do tří samostatných tabulek, zvlášť pro komunikační prostředky (tab. 2), pro synchronizační prostředky (semafory, mutexy – tab. 3) a pro signály, procesy a vlákna (tab. 4).

Tab. 2. Výsledky srovnávacího testu komunikačních prostředků
(pozn.: pojmenované roury Win32API nejsou totožné se standardem POSIX, jsou obsáhlejší)

  Roury Pojmenované roury Zprávy System V Fronty zpráv POSIX Schránky BSD
Free BSD 3.1 čas (s) 12,886 29,360 31,539   9,109
rozptyl (%) 84,79 48,13 9,82   77,12
RH Linux 6.0 čas (s) 3,290 3,408 4,960   10,372
rozptyl (%) 6,36 10,90 0,43   1,51
Lynx OS 2.5 čas (s) 6,065 6,289 6,126 3,573 6,160
rozptyl (%) 0,13 0,80 3,94 1,61 1,90
Solaris 5.7 čas (s) 9,159 9,133 10,151 24,296 33,304
rozptyl (%) 0,17 0,08 0,81 0,13 1,93
Windows NT 4.0 čas (s) 19,116 39,952      
rozptyl (%) 14,42 7,01      

Tab. 3. Výsledky srovnávacího testu číselných a binárních semaforů (mutexů)
(pozn.: jádro testované verze Free BSD neobsahovalo semafory System V)

  Semafory System V Semafory POSIX Semafory Win32API Mutexy
Free BSD 3.1 čas (s)       18,307
rozptyl (%)       0,05
RH Linux 6.0 čas (s) 33,036     9,291
rozptyl (%) 0,12     0,01
Lynx OS 2.5 čas (s) 32,823 3,127   1,364
rozptyl (%) 0,07 0,00   0,00
Solaris 5.7 čas (s) 50,318 55,058   3,369
rozptyl (%) 0,05 0,00   0,01
Windows NT 4.0 čas (s)     49,852 56,773
rozptyl (%)     11,43 34,35

Pro jednotlivý operační systém a testovaný prostředek jsou v tabulkách uvedeny vždy dvě hodnoty. První hodnota je doba trvání testovací úlohy v sekundách (u testu procesů v tab. 4 v milisekundách). Jde o aritmetický průměr ze souboru pěti nezávislých měření. Druhá hodnota je odhad rozptylu naměřeného souboru údajů, vyjádřený v procentech průměrného času. Prázdné políčko znamená, že příslušná vlastnost není v daném systému k dispozici.

Tab. 4. Výsledky srovnávacího testu signálů, přepínání vláken a vytváření procesů

  Signály RT signály Vlákna Procesy
Free BSD 3.1 čas (s; ms) 25,203   148,058 71,473 ms
rozptyl (%) 2,32   0,08 10,47
RH Linux 6.0 čas (s; ms) 13,406 17,032 66,392 55,759 ms
rozptyl (%) 10,98 5,01 0,06 10,34
Lynx OS 2.5 čas (s; ms) 11,546 13,247 21,506 61,864 ms
rozptyl (%) 1,46 8,09 0,01 2,76
Solaris 5.7 čas (s; ms) 64,097 68,493 58,409 341,320 ms
rozptyl (%) 2,33 1,62 0,01 1,31
Windows NT 4.0 čas (s; ms)     20,964  
rozptyl (%)     7,16  

Na vysvětlenou k průběhu testů je vhodné připojit několik poznámek:

  • všech OS Unix/POSIX byla pro měření času použita funkce gettimeofday;
  • u OS Windows NT byly použity funkce, které zjišťují počet tiků časovače od spuštění počítače a počet tiků za sekundu (Query Performance Counter, Query Performance Frequency);
  • odhad rozptylu byl vypočten pomocí vztahu
    [nSxi2 – (Sxi)2]/[n(n – 1)]
    kde
    n je počet měření,
    xi jsou naměřené doby trvání (i = 1 až n);
  • v operačním systému Free BSD byla k nastavení priority RT použita funkce setrtprio, protože prostředky podle normy POSIX nebyly v době testování v tomto systému ještě k dispozici.

Hodnocení výsledků testu
Na zpracované výsledky je možné pohlížet ze dvou základních hodnoticích hledisek – podle rychlosti a podle rozptylu.

Dosažená rychlost (doba trvání testu) informuje o efektivnosti vnitřní implementace testovaného prostředku, zatímco velikost rozptylu naznačuje stupeň determinismu dosažený při implementaci testované vlastnosti operačního systému.

Od OS pracujících v reálném čase jsou většinou vyžadovány dobré parametry z obou hledisek. Extrémně pomalý OS s plně deterministickým chováním by patrně nenašel uplatnění.

Z hlediska deterministického chování testu absolutně nevyhověl OS Free BSD. Rozptyly časů naměřených při testu komunikačních prostředků jsou u něj bezkonkurenčně největší. Tento systém vznikl původně na univerzitní půdě bez ambicí na použití v tvrdých aplikacích reálného času. Je ovšem nutné podotknout, že test OS Free BSD nebyl vykonán s použitím plánování reálného času podle normy POSIX, jehož implementace v tomto OS byla v době testů teprve dokončována. V současné době je tento prostředek v jádru tohoto OS již standardně zabudován. Dodatečné zkoušky naznačují, že při použití prostředků plánování reálného času podle normy POSIX by se dosáhlo řádově menších hodnot rozptylu.

Z hlediska determinismu nejsou výsledky OS Windows NT 4.0 také příliš uspokující. Jeho hodnoty rozptylu v testu synchronizačních prostředků jsou zarážející.

Obr. 3.

Rozptyly u zbylých tří OS jsou v pořádku. Zvláště u systémů Solaris a Lynx OS. Za povšimnutí stojí skutečnost, že specializovaný systém reálného času Lynx OS je na tom z hlediska velikosti rozptylu o něco hůře než Solaris.

Zcela jiný výsledek je zřetelný při porovnání OS podle rychlosti. Systémy Free BSD, Windows NT a Solaris na tom s rychlostí moc dobře nejsou. Windows NT je sice na špici v testu na přepínání vláken, ale ostatní testy jsou horší až nejhorší. Solaris pro změnu za svou časovou stálost tvrdě platí malou rychlostí. Nejrychlejším se podle testů jeví Lynx OS společně s OS Linux. Testovaná verze Linux Red Hat 6.0 překvapila svou velkou rychlostí u obou typů rour.

Charakteristika testovaných OS
Závěrem se, na základě získaných výsledků, pokusíme charakterizovat testované OS z hlediska jejich použití v systémech reálného času. Je přitom třeba upozornit, že tato charakterizace není zdaleka definitivní a že lze předpokládat další vývoj.

Free BSD
U OS Free BSD bylo až donedávna naprosto vyloučeno jakékoliv použití v aplikacích reálného času. Výsledky testů tomu plně odpovídají. Implementace plánování reálného času podle normy POSIX pozici tohoto OS z hlediska použití v prostředí reálného času výrazně zlepšila. OS Free BSD samozřejmě není v žádném případě vhodný pro systémy hard RT (absence řešení inverze priorit, kromě plánování není podporována norma Posix 1003.1b). Za určitých okolností ale může být využit pro méně náročné úlohy reálného času. Pro rychlost a rozsáhlejší podporu standardu POSIX je vhodnější dát před OS Free BSD přednost OS Linux.

Linux
Použít OS Linux v aplikacích, ve kterých je očekávána plně deterministická odezva (systémy hard RT), není vhodné. OS Linux doposud neobsahuje všechny prostředky podle standardu Posix 1003.1b. Kromě toho nemá ani žádné prostředky pro řešení problému inverze priorit. Prezentované výsledky testů nasvědčují také tomu, že v OS Linux zůstávají pasáže vedoucí k nedeterministickému chování. Některé prostředky jsou naopak implementovány velmi efektivně. Současný stav určuje OS Linux k použití v rámci systémů soft RT.

Lynx OS
Jde o specializovaný OS, určený k použití v hard RT. Tomu odpovídají plná přítomnost standardu Posix 1003.1b, široká škála priorit, dědičnost priorit (řeší problém inverze priorit) a efektivní implementace.

Nyní, kdy se rozdíly mezi specializovanými a běžnými OS stírají, je pro OS velmi obtížné udržet si své postavení. Proto nastupuje trend, podle kterého se firmy vyvíjející specializované RTOS snaží využít potenciál vývojových pracovníků konkurenčních systémů. Například Lynx OS i konkurenční QNX se začaly přibližovat k systému Linux.

Solaris
Solaris, podobně jako Lynx OS, obsahuje plnou implementaci standardu Posix 1003.1b a dědičnost priorit. Podle výsledků testů je tento OS dokonce lepší z hlediska deterministického chování. Jediným nedostatkem omezujícím jeho použití v systémech hard RT se jeví pomalost některých prostředků, jak ji ukázaly realizované testy.

Windows NT
Nevhodný způsob implementace plánování reálného času a nedeterministický způsob obsluhy přerušení vylučují tento OS z jakéhokoliv použití v systémech hard RT. Příliš vhodný se nejeví ani pro případné využití v systémech soft RT (pomalé prostředky, malý počet úrovní priority).

Použít OS Windows NT je výhodné ve vizualizačních stanicích zobrazujících různé řídicí nebo technologické procesy. Ovšem při omezení pouze na případy, kdy zobrazování a reakce na změnu stavů nevyžadují plně deterministické chování systému. Výhodou OS Windows NT, který se při vhodném použití plně využije, je nejznámější a asi nejpropracovanější vizuální grafické rozhraní. Další jeho nespornou výhodou je existence mnoha vývojových systémů, které umožňují maximálně rychlý a efektivní vývoj aplikací.

Poděkování
Popsaná technika porovnávacího testu byla vypracována jako součást autorovy diplomové práce [1]. Vlastní testy OS byly uskutečněny ve spolupráci s firmou Artisys s. r. o.

Literatura:

[1] ŠUMBERA, P.: Porovnání RT vlastností operačních systémů. (Diplomová práce.) Brno, Ústav informatiky a výpočetní techniky FEL VUT 2000.