Hlavní navigace

GNU/Linux pro řízení a rychlost jeho odezvy

Pavel Píša

Linux je nasazován v řídicích aplikacích, například robotech, autonomních i klasických automobilech. Proto je potřeba znát dosažitelné reakční doby jádra. Možnosti si předvedeme na Raspberry Pi.

V tomto článku bude popsané, jak je možné jádro Linux upravit tak, aby byla reakční rychlost použitelná pro řešení řídicích aplikací. V dalším návazném článku pak bude demostrováno, jak zkonfigurovat a sestavit jednoduchý zpětnovazební systém s destičkou Raspberry Pi pro řízení stejnosměrného motoru s minimálním počtem přidaných komponent. Hardware je vybraný tak, aby byl snadno dostupný, levný a celý návrh je koncipovaný tak, aby byl vhodný a dostatečný pro výuku. Pokud bude zájem, na dvojici článků mohou navázat další, již zaměřené na řešení přibližující se postupně návrhu systémů použitelných v reálním nasazení.

Předkládané dva články přibližně odpovídají a shrnují obsah prezentací a demonstrací na konferencích InstallFest (Je Raspberry Pi použitelné pro řídicí a robotické aplikace?) a LinuxDays (Řízení stejnosměrných a bezkartáčových motorů).

Rychlost odezvy linuxového jádra

Jádro systému Linux původně vzniklo v roce 1991 „jen“ jako projekt pro zábavu a poučení. Díky příspěvkům velkého množství nadšenců se stalo klíčovým prvkem infrastruktury mnoha firem (Facebook, Google). K projektu se přidaly velké korporace (IBM, Intel, Oracle) a mnoho firem založilo na podpoře systému GNU/Linux a Android (s jádrem Linux) své podnikání. Systém v současné době podporuje okolo 30 odlišných procesorových architektur a dosáhl takového stupně obecnosti, že je použit ve více než 90 % z 500 nejvýkonnějších počítačů světa (Top500 Operating Systems) i v převážné většině inteligentních televizí, levných síťových prvcích pro ADSL a WiFi připojení a dnes i v inteligentních „žárovkách“.

Pro svou všestrannost a schopnost komunikace, vzdálené správy a možnost vytvoření servisního webového serveru jevily o Linux zájem i firmy zabývající se oblastí řídicích aplikací. Většina z těchto firem a prvních uživatelů pokládala za nemožné, že by jádro obecného operačního systému mohlo být použito pro aplikace reálného času (dále jen RT – real-time), a proto navrhovali a vyvinuli několik řešení, která využívala Linux pro správu systému, ale na odezvu kritické části byly přesunuty do procesů nadřazeného plánovače (případně celého systému), který pouze ve zbývajícím čase přenechal procesorový čas pro jádro Linux a pod ním běžící aplikace. Jedná se o koncepci, která je obvyklá i v mnoha „Soft-PLC“ řešeních určených pro jiné operační systémy. Takovéto řešení přináší komplikace. Vývoj RT aplikací vyžaduje programování pro jiné nebo omezené aplikační rozhraní, než které nabízí obecný systém pro běžné aplikace. Přitom je v dnešní době vyžadováno propojení složitějšími komunikačními rozhraními a protokoly. Často jsou využívané protokoly TCP/IP, část výpočtů se přenáší na grafické karty (například v případě zpracování velkých objemů prostorových radarových dat), data se získávají z periferií implementovaných v FPGA a k přenosům je využit kanál DMA. Programování v omezeném prostředí RT nadstavby systému se tím stává komplikovanější a dosažení součinnosti s využitím některých kanálů dohromady s hlavním operačním systémem téměř nemožné.

Již okolo roku 1995 však profesor Doug Niehaus a jeho skupina experimentovali s možností úpravy jádra Linux tak, aby bylo možné zaručit včasné přeplánování a odezvy aplikací běžících ve standardním/plnohodnotném uživatelském prostředí. Vznikl tak projekt KURT (Kansas University Real-Time). Základem projektu bylo využití podpory jádra Linux pro víceprocesorové systémy. Jádro v základní podobě nedovolovalo přeplánování procesů během doby zpracování neblokujících úseků systémových volání na daném procesoru. Postupně však byla rozšiřována možnost paralelního běhu i v době zpracování systémových volání v jádře pro případ nasazení na víceprocesorovém systému (SMP). Serializace zpracování kritických sekcí, ve kterých se v danou dobu směl nacházet pouze jeden procesor, pak byla a je chráněna zámky s aktivním čekáním (spin-lock). Pro účely RT varianty jádra bylo možné zajistit plný souběh a možnost přeplánování v jádře tak, že byl původní model SMP mapovaný na koncepci neomezeného počtu myšlených procesorů. Pro každou k běhu připravenou úlohu tak byl vždy jeden takový myšlený procesor připravený a fyzické procesory pak byly přidělované podle potřeby/priority těmto myšleným CPU. Na běh na více procesorech bylo jádro již připravené. Úseky s potřebou vyloučení souběhu pak místo spin-locků začaly využívat RT mutex s podporou dědění priority pro zamezení inverze priorit. Přitom většinu kódu nebylo nutné přímo měnit, protože náhrada spin-locku za RT-mutex byla provedena na úrovni hlavičkových souborů. Podpora RT-mutexů byla zpřístupněna i pro uživatelské aplikace (PI-futexes).

Přesto množství potřebných úprav bylo značné. Většinou se ovšem jednalo o úpravy, které s předstihem opravovaly chyby a úzká místa, která by stejně blokovala rozvoj Linuxu i v nasazení na mnohaprocesorových systémech (v dnešní době čítají největší systémy spouštějící nad společným paměťovým prostorem jednu instanci jádra Linuxu již více než 8000 procesorových jader). Přesto projekt úpravy jádra pro plnou podporu preemptivního plánování stále do hlavního vývojového stromu po 10 letech vývoje současného modelu tohoto řešení ještě začleněn nebyl. Hlavními vývojáři, kteří přispěli, jsou Ingo Molnar a Thomas Gleixner. V současné době koordinuje vývoj a testuje RT varianty linuxového jádra organizace OSADL. V její testovací laboratoři se nachází více jak 100 kontinuálně testovaných systémů, ke kterým jsou publikována data, a dále i další systémy, u kterých si zadavatelé testování nepřáli veřejné vystavení výsledků.

Na rozdíl od jader a mikrojáder určených pro kritické bezpečnostní aplikace není možné provést pro jádro sestávající se z více jak 15 miliónů řádek zdrojových kódů analytický rozbor veškerých sekvencí vykonávaného kódu a deklarovat maximální latence výpočtem. Zároveň použití vyrovnávacích pamětí a souběh mnoha procesorů takový realistický výpočet také vylučuje. Pro mnoho aplikací je ovšem dostatečné znát maximální latence zachycené za měsíce testování a právě dokumentování časové charakteristiky systémů při cyklickém testování sadou rozmanitých zátěží OSADL realizuje.

Výsledkem vývoje a úprav je RT varianta jádra, která je v současných verzích (např. 3.18.11-rt7) schopná aktivovat na základě vnější události zpracování v testovací aplikaci do doby kratší než 100 μs, a to bez jediné registrované výjimky za měsíce běhu. Toto platí pro výkonný hardware na bázi procesorů x86, a to i pro mnohaprocesorové stroje. Podmínkou je kvalitní základní deska, jejíž BIOS nevykazuje defekty ve zpracování SMI přerušení. Také implementace periferií a především grafické karty nesmí neoprávněně blokovat systémové sběrnice. Testování v rámci laboratoře OSADL pak tyto vlastnosti pro daný hardware může ověřit.

V oblasti vestavných systému se ovšem často používají jiné, levnější a úspornější architektury. I ty RT verze podporuje. Asi nejrozšířenější takovou architekturou v současné době je architektura ARM. Pro průmyslové nasazení se pak hodí například procesory z rodin FreeScale i.MX53 a i.MX6 nebo Texas Instruments AM335×, AM437×, AM572×. I pro mnoho kvalitně navržených vestavných procesorů a modulů RT varianta jádra vykazuje latence s maximální odezvou menší než 200 μs.

Jaké latence lze předpokládat od Raspberry Pi

Pro výukové účely a experimenty na univerzitách je ovšem zajímavé, jaké vlastnosti vykazují i systémy na druhém konci spektra. To jsou levné desky, při jejichž návrhu byla téměř jedinou prioritou cena. Takovým mezi nadšenci velmi rozšířeným systémem je i procesorová destička Raspberry Pi.

Počítač Raspberry Pi je ve verzi 1 založený na čipu Broadcom BCM2835. Jeho procesorové jádro (ARM1176JZF-S) využívá již v době návrhu starou architekturu ARMv6. Důsledkem je například nutnost rekompilace distribuce systému Debian/Raspbian, protože oficiální binární balíčky současného portu ARMhf projektu Debian vyžadují alespoň architekturu ARMv7-A s hardwarovou jednotkou pro výpočty v plovoucí řádové čárce alespoň ve verzi VFPv3-D16. To znamená architekturu procesorů ARM na bázi jádra Cortex-A, které je běžné například i v dnešních chytrých mobilních telefonech bez rozdílu značky – Android, iPhone i MS Nokia. Na systémovém čipu použitém v Raspberry Pi není integrované rozhraní ETHERNET a ani výkonná sběrnice pro jeho připojení ve formě externího řadiče. Proto se využívá čipu převodníku USB↔ETHERNET. Systém nenese na desce žádné trvalé úložiště dat. K dispozici je pouze relativně nespolehlivé médium SD-card a přístup k němu zatěžuje značně procesor systému. O grafický výstup se pak stará akcelerátor VideoCore IV GPU, ke kterému dlouho dobu neexistovala plná otevřená podpora. I rozšiřující konektory pro připojení vlastních periferií a experimentů byly na původním návrhu umístěny bez rozmyslu. Varianta B+ již tuto chybu ve vetší míře napravuje a verze Raspberry Pi 2 se systémovým čipem BCM2836 přináší architekturu ARM Cortex-A7, která je již se současnými distribucemi pro aktuální ARM Cortex-A kompatibilní. Přesto ostatní nevýhody pro seriózní nasazení například v průmyslových aplikacích zůstávají.

Přes veškeré výše popsané nedostatky však i takto nevýkonný a problematický systém vykazuje s RT variantou jádra překvapivě stabilní výsledky. Histogram latencí převzatý z výstupu laboratoře OSADL za jeden testovací běh je vynesen na obrázku (OSADL RPi 1 profil).

Histogram doby reakce na přerušení z časovače na desce Raspberry Pi 1

Maximální latence je menší než 200 μs. Dlouhodobé testování pak dokumentuje, že otestování původního jádra a poté přidání aktuální verze RT úprav se latence také dlouhodobě pohybuje v oblasti pod 250 μs. Naše vlastní testy s využitím testovacího programucyclictest také tyto výsledky s přehledem potvrzují.

Zaznamenané histogramy/profily latencí za měsíce běhu

Shrnutí

Přesto, že pro linuxové jádro nelze analyticky určit maximální doby odezvy na události,  po popsaných úpravách vykazuje parametry a spolehlivost, která pokrývá velké množství oblastí, které byly dříve řešitelné pouze s využitím specializovaných operačních systémů/exekutiv reálného času (RTOS). Pokud je pak potřeba řešit aplikace, ve kterých je pro určité procesy nutné reagovat ještě rychleji (pod 40 až 10 μs), tak jsou často systémové procesory doplňované DSP jádry a mikrokontroléry (například Ti PRU a Cortex-M na AMxxxx), na kterých neběží operační systém, ale jenom řídící smyčka a hlavní systémový procesor řeší koordinaci a vyšší úroveň řízení. Pro řízení s časováním pod 1 μs již většinou ani toto řešení není použitelné a často se nasazuje kombinace procesoru a programovatelného obvodu na jednom čipu (například Xilinx Zynq, Altera SoC).

Množství i na časování citlivých aplikací, které lze řešit použitím hlavního procesoru a operačního systému GNU/Linux bez programování v assembleru je velmi široké a v navazujícím článku bude ukázané, jaké jsou limity výukového systému Raspberry Pi.

Našli jste v článku chybu?

11. 5. 2016 6:58

Ano, měl jsem na mysli ty dva široké pásy. Nechci být pedant, ale zmíněno to nebylo a přehlédnout to jaksi nešlo.

[A] Předpokládám, že frekvence je měřena ve smyslu příchozích požadavků přímo na měřeném RT/non-RT.

Nejsem si ale jistý, jestli je to pak rebootem + nějakými operacemi. Jde o to, že u rebootu - tedy dočasnému DOS - by tam frekvence musela být 0 a ne poloviční.
Prostě v nějakém čase by musel být plný výpadek. Buď to v grafu není a pak se nepodařilo zajistit naplnění Shannon-Kotělnik…

11. 5. 2016 0:05

Obrázek přidala redakce a neměl jsem příležitost to řešit. Jinak s Kukou máte nejspíše pravdu, dříve určitě Windows CE používali. Jestli se něco od té doby změnilo nevím. Vím ale o mnoha velkých firmách, které RT variantu Linuxu používají buď veřejně nebo se o tom mezi odborníky mluví.

DigiZone.cz: SES zajistí HD pro M7 Group

SES zajistí HD pro M7 Group

Vitalia.cz: To nejhorší při horečce u dětí: Febrilní křeče

To nejhorší při horečce u dětí: Febrilní křeče

120na80.cz: Rovnátka, která nejsou vidět

Rovnátka, která nejsou vidět

120na80.cz: Boreliózu nelze žádným testem prokázat

Boreliózu nelze žádným testem prokázat

DigiZone.cz: R2B2 a Hybrid uzavřely partnerství

R2B2 a Hybrid uzavřely partnerství

Vitalia.cz: Láska na vozíku: Přitažliví jsme pro tzv. pečovatelky

Láska na vozíku: Přitažliví jsme pro tzv. pečovatelky

Podnikatel.cz: E-Ježíšek si zařádí: nákupy od 2 do 5 tisíc

E-Ježíšek si zařádí: nákupy od 2 do 5 tisíc

Měšec.cz: Za palivo zaplatíte mobilem (TEST)

Za palivo zaplatíte mobilem (TEST)

120na80.cz: Horní cesty dýchací. Zkuste fytofarmaka

Horní cesty dýchací. Zkuste fytofarmaka

Vitalia.cz: Nejlepší obranou při nachlazení je útok

Nejlepší obranou při nachlazení je útok

Root.cz: Certifikáty zadarmo jsou horší než za peníze?

Certifikáty zadarmo jsou horší než za peníze?

Podnikatel.cz: Vládu obejde, kvůli EET rovnou do sněmovny

Vládu obejde, kvůli EET rovnou do sněmovny

120na80.cz: Pánové, pečujte o svoje přirození a prostatu

Pánové, pečujte o svoje přirození a prostatu

Měšec.cz: Exekuční poradna: ptejte se online

Exekuční poradna: ptejte se online

Lupa.cz: Obchod budoucnosti je bez front, košíků i pokladen

Obchod budoucnosti je bez front, košíků i pokladen

Vitalia.cz: Proč vás každý zubař posílá na dentální hygienu

Proč vás každý zubař posílá na dentální hygienu

Podnikatel.cz: Udávání a účtenková loterie, hloupá komedie

Udávání a účtenková loterie, hloupá komedie

Vitalia.cz: Jak vybrat ořechy do cukroví a kde mají levné

Jak vybrat ořechy do cukroví a kde mají levné

Lupa.cz: Propustili je z Avastu, už po nich sahá ESET

Propustili je z Avastu, už po nich sahá ESET

DigiZone.cz: Česká televize mění schéma ČT :D

Česká televize mění schéma ČT :D