Dotaz: Jak napsat aplikaci realtime bez realtime kernelu?

[Jiri K.]

Ahoj,

chápu to správně, že můžu napsat realtime aplikaci, pokud ji nějakým způsobem dostanu do na roveň modulů, tedy že moduly běží realtime? Chci docílit toho, psát podle potřeby realtime aplkiace aniž bych musel použít realtime kernel. Jaká existuje nejjednodušší cesta k tomu to provést?

Příklad: ovládat třeba realtime gpio na Raspberry Pi - např. udělat si vlastní komunikační protokol mezi dvěmi RPi přes GPIO (ať už softwarově, nebo HW, to je jedno, prostě to musí běžet realtime).

Díky

Odpovědi

[NN]

Zajimavy clanek ohledne RTC na RPi..

[Jiri K.]

Super díky.

[rADOn]

Nechápeš to správně. Specializované realtime kernely existují proto že jinak to udělat nejde. Pokud nemáš moc velké nároky a rychlý HW – což by dnes neměl být problém – tak se dá předpokládat že moc prodlev nebude a přiměřené robustní protokol se s tím nějak vypořádá. Ale není to totéž jako mít jistotu že prodlevy prostě nebudou.

[luky]

Nechápeš to správně. Specializované realtime kernely existují proto že jinak to udělat nejde.

Ale samozrejme ze to jde - v linuxu si vypne pozadovany pocet jader a pusti si na nich real-time aplikaci napsanou primo pro to zelezo bez kernelu. Celkem bezny postup v embedded.

[Radovan]

Co považuješ za "rychlý HW"? Americké jaderné elektrárny řídí a minimálně do roku 2025 budou řídit PDP-11, a řekl bych že tam je potřeba být zatraceně realtime

Stále také shánějí lidi kteří to dokážou programovat v assembleru, práce zajištěná na roky dopředu...

[rastos]

Realtime neznamená "proklatě rychle". Realtime znamená, že je garantovaná odozva do času T. Či je čas T=10ms alebo 1 minuta, o tom realtime nehovorí.

[OldFrog {Ondra Nemecek}]

Akporát rychlém HW ale je větší pravděpodobnost, že se to stihne...

[mimi.vx]

tu nejde o pravdepodobnst ze se to stihne ale o zarucnou odpoved do daneho casu ....

[OldFrog {Ondra Nemecek}]

tu nejde o pravdepodobnst ze se to stihne ale o zarucnou odpoved do daneho casu ....

Já vím - pouze rozvádím co napsal výšed rADOn (že lze na RT rezignovat).

[Sid]

Zda sa, ze naozaj to nechapete. bud potrebujete nieco co povacsine funguje do urciteho casu (a nic sa nestane ak nie) alebo potrebujete nieco co urcite funguje v nejakych casovych mantineloch. To co napisal on hore je v kontexte RT (ziadatel asi chape preco chce RT a nie nieco ine) samozrejme blbost. Ked na tom zariadeni bude zavisiet nieco dolezite tak uz vidim ako to skladate stylom tak dame tam silnejsi procak snad sa to stihne vzdy vykonat.

[OldFrog {Ondra Nemecek}]

Vím co je RT.

[Filip Jirsák]

Když budete mít mezi brzdovým pedálem v autě a brzdami realtime aplikaci, nebudete chtít vysokou pravděpodobnost, že brzdy zareagují rychle (a nízkou pravděpodobnost, že to bude trvat pár sekund, když budete mít opravdu smůlu, i desítky sekund), ale jistotu, že vždy zareagují nejdéle do x milisekund.

[Erbureth]

Takže po x milisekundách se čas reakce krátí?

[luky]

Vsechno se dela na vysokou pravdepodnobnost, na jistotu to nikdo neumi.

[Jiri K.]

Když děláš třeba na ARM, tak tam má Linux kernel dán frekvenci 100Hz pro scheduler, oproti Desktopu, kde je default 1000Hz. Těch 100Hz je málo, když potřebuješ něco řídit, v mém případě kvadrokoptéru.

Ale první příspěvek už mi dal zajímavé řešení přes časovače. Domnívám se, že nevýhoda realtime aplikace bez realtime kernelu je, že se nedokáží realtime využívat různé běžící služby, jako např. pro odesílání paketů po wifi. Ale spustit realtime třeba přečtení dat z I2C sběrnice by jít mohlo.

[mimi.vx]

tak default je i u desktopu 100Hz .. ale vetsina jader je distribuci/uzovatelem nakonfigurova jinak a nic ti nebrani si jadro pro tvuj arm prelozit s vlastnim nastavenim ...

ale mam pocit ze vubec netusis co RT znamena ..

[Jiri K.]

Když napíšu "Ovládat třeba realtime GPIO mezi dvěma RPi" tak asi vím co znamená RT.

[Michal Kubeček]

Domnívám se, že nevýhoda realtime aplikace bez realtime kernelu je, že se nedokáží realtime využívat různé běžící služby, jako např. pro odesílání paketů po wifi. Ale spustit realtime třeba přečtení dat z I2C sběrnice by jít mohlo.

To není tak úplně pravda, problém je i v tom, že bez realtime jádra nemůžete mít ani jistotu, že vám jádro v nevhodnou chvíli neodscheduluje váš proces na dobu delší, než by se vám líbilo. Pomineme-li poněkud extrémní triky typu výše zmíněného dedikovaného procesoru, dá se to riziko omezit nastavením realtime priority, ale pak je potřeba být velmi opatrný. (Oblíbená zábava je nastavit realtime prioritu procesu, který vůbec nespí, a pak se divit, proč je celý systém mrtvý.)

[luky]

Oblíbená zábava je nastavit realtime prioritu procesu, který vůbec nespí, a pak se divit, proč je celý systém mrtvý.

A toto se vam stalo nebo jste si to vymyslel? Kernel totiz bude tu RT aplikaci postupne prerusovat. Vizte kernel.sched_rt_period_us a kernel.sched_rt_runtime_us a taky RTFM!

[Michal Kubeček]

A toto se vam stalo nebo jste si to vymyslel?

Mně ne, protože realtime priority používám jen výjimečně a dávám si pozor, abych je nepřiřazoval CPU intensive procesům. Ale několika našim zákazníkům se to podařilo (a to vím jen o těch, u kterých se to coby bugreport dostalo ke mně; ve skutečnosti jich asi bylo víc).

Vizte kernel.sched_rt_period_us a kernel.sched_rt_runtime_us a taky RTFM!

Takhle jednoduše to bude fungovat na jednoprocesorovém systému. Na víceprocesorovém si může "vypůjčit" nevyužitý čas z ostatních procesorů. Ve výsledku sice udusí "jen" jeden procesor, ale protože na něm spolehlivě odblokuje kernel threads, dříve či později to znefunkční celý systém nobo jeho podstatnou část, např. jakmile někdo zavolá schedule_on_each_cpu() nebo něco podobného.

[Michal Kubeček]

Na víceprocesorovém si může "vypůjčit" nevyužitý čas z ostatních procesorů.

Viz balance_runtime() and do_balance_runtime().

[luky]

pravda, ve vanilce bezi worker thready v SCHED_OTHER, IMO pekna pitomost, zejmena koncept softirq.

[luky]

Tak ze zvedavosti jsem to zkusil na vanilce pro 1 - 6 (pocet jader) FIFO vlaken s prioritou 99 a konzole se (az na lagovani umerne nastaveni) dala normalne pouzivat. Umrela ale sit.

[Michal Kubeček]

Pokud to spustíte na všech procesorech, tak už není odkud půjčovat, takže začne účinkovat ten 95% limit. Problémová je situace, kdy běží např. jen jeden takový realtime proces "utržený ze řetězu". Různé věci v systému (od kterých by to člověk na první pohled nečekal) se pak postupně začnou blokovat.

Jeden z prvních příkladů, který jsem na toto téma viděl, vypadal tak, že se na jednom CPU proces s realtime prioritou točil v nekonečné smyčce a vedle druhý zavolá mlock(). (Původní testcase byl komplikovanější, oni tam volali v nekonečné smyčce ten mlock() a spustili to dvakrát, ale tahle zjednodušená verze je názornější.)

[luky]

Asi jsem to nenapsal dost jasne, udelal jsem 6 testu postupne pro 1 az 6 procesu a ani jeden z nich nezpusobil "zasek" systemu (konzole byla porad pouzitelna).

Pouzivat libovolne syscally z RT procesu neni dobry napad, protoze v kernelu se casto pouzivaji mutexy, ktere nepodporuji priority inheritance a ani priority ceiling, takze to nemuze nikdy dost dobre fungovat. Rozumne reseni je RT procesem ovladat HW a syscally delat pres jiny thread.

[Michal Kubeček]

udelal jsem 6 testu postupne pro 1 az 6 procesu a ani jeden z nich nezpusobil "zasek" systemu (konzole byla porad pouzitelna)

Já taky netvrdil, že okamžitě nebude fungovat vůbec nic. Místo toho se postupně budou zasekávat různé procesy, které měly tu smůlu, že potřebovaly počkat na blokovaný procesor. Koneckonců, sám jste pozoroval, že při vašem testu začala zlobit síť - to může být u serveru docela zásadní problém.

Pouzivat libovolne syscally z RT procesu neni dobry napad,

Ten druhý proces, který volá mlock(), nemusí být realtime. Podstatné je, že se zasekne, protože čeká na worker z jiného CPU, který tam realtime CPU hog (ten žádný syscall volat nepotřebuje) nepustí na procesor. Skutečný problém je přiřazení realtime priority CPU intensive procesu. Realtime slouží k zajištění nízkých latencí, ne k tomu, aby CPU intensive proces mohl vyždímat procesor do poslední kapičky; od toho jsou úplně jiné nástroje.

[luky]

Psal jste "celý systém mrtvý", ale ono vytuhne jen to, co potrebuje per core workery, coz treba konzole neni, takze neni problem ten RT proces z te konsole zabit.

System s RT procesy je lepsi nastavit tak, aby jaderna vlakna s omezenou afinitou mela vetsi prioritu nez pouzivane RT procesy. Ve vanilce je dokonce kompilacni volba, ktera umozni nastavit jadernym vlaknum prioritu vetsi, nez je mozne konfigurovat z uzivatelskeho prostoru.

[Michal Kubeček]

coz treba konzole neni, takze neni problem ten RT proces z te konsole zabit.

Jen pokud se k ní lze snadno dostat, což nemusí být vždy pravda. A i když ano, je problémem už to, že je to vůbec potřeba. Nebo taky dřív nějaký watchdog odstřelí celý systém, protože nebude dostupná klíčová služba.

aby jaderna vlakna s omezenou afinitou mela vetsi prioritu nez pouzivane RT procesy … kompilacni volba, ktera umozni nastavit jadernym vlaknum prioritu vetsi, nez je mozne konfigurovat z uzivatelskeho prostoru

To už jsou jen berličky, které umožňují omezit následky, neodstraňují problém. Navíc mnohdy nemusejí být ani žádoucí, protože pak může dojít k opačnému problému - kernel thread nepustí aplikaci na procesor tak rychle, jak by potřebovala.

[Jiri K.]

Počkat, prioritu přece nastavuješ od -20 do 19, -20 je nejvyšší. Kde jsi teda nastavoval prioritu 99?

[luky]

bavime se o SCHED_FIFO, ne o SCHED_OTHER

[luky]

ctete man sched_setscheduler

[Jiri K.]

Tak nastavit prioritu procesu na nejnižší jsem zkoušel bez jakékoliv změny v její frekvenci vykonávání a bez jakékoliv změny v tom, že frekvence nebyla vždy stabilní, protože se spustil nějaký jiný proces. Moje zkušenost je, že to nevyvolalo žádnou změnu.

[Jiri K.]

*resp. na nejvyšší