Real-time modifikace Linuxu - 1 (RTLinux a RTAI) (diskuse)

[Michal Čihař]

A co Xenomai? V současné době probíhá vývoj spíš v něm než u RTAI. Myslím že také podporuje víc architektur.

[belisarivs]

Xenomai je tam zmineno. Doslo ke slouceni se RTAI. RTAI se tak odchylilo od sveho puvodniho smeru a uz nevyuziva nanojadro, ale je to jenom pridavny modul. Ten projekt se ted jemuje RTAI/fusion. Je to tam zmineno. Ale na druhou stranu jakekoliv pripominky si cenim. A taky je planuji zaclenit do svoji Bakalarske prace.

[Michal Čihař]

To je ale stará informace . Viz třeba tento mail. Xenomai 2.0 je to, co původně mělo být RTAI/fusion 1.0.

[belisarivs]

Hmm, tak to jsem nezaregistroval. Nicmene muj projekt se tykal RTLinuxu, RTAI a Realtime Preempt patche. Mel byt na 20 stran a ja ho i bez Xenomai napsal pres 30 stran dlouhy. Vsechno jsem to tam dat nemohl. Zvlaste kdyz to RTAI nebylo primarni. Pojednani o tom patchi, bude pro svou relativni obsahlost v dalsi kapitole.

[moira]

To dovoluje přeprogramovat čítač pouze dvěma I/O instrukcemi, což trvá přibližně 3 ms.

To je nejak dlouho na dve instrukce, ne?

[Pavel Píša]

Nemohu potvrdid ani vyvrátit tento odhad. Ale je si dobré uvědomit, že to co se tváří jako 8254, se nachází v southbridgi. CPU k tomu přistupuje přes IO instrukce, musí se protlouct přes rozhraní CPU north bridge, přes arbitraci s dalšími PCI zařízeními, pak se po PCI dostane do south bridge a poté do jeho části, která emuluje ISA periferie. Nejsem si jistý, jestli u některých čipsetů není dokonce 8254 až na čtyřbitové LPC (Low Pin Count) sběrnici připojené k south bridgi. Seriové kanály a paralelní port jsou někdy až na ní. Takže bych se té strašlivé době ani nedivil.

To jsou ovšem problémy dané slepencovitou architekturou PC. Na embedded zařízeních přístup k časovači takový problém není.

Protože i Intel a AMD uznali, že pro synchronizaci multimédií je toto řešení nepoužitelné, jsou novější chipsety pro PC vybaveny HPET timery, které Linux umí využít. Toto řešení by mělo být i o řády výkonější a flexibilnější než používání archeologické vykopávky, která přežila z roku 1980.

[belisarivs]

To je pravda. Ja jsem v podstate delal vycuc a preklad z anglickych materialnu, takze to muze vyt chyba vznikla pri vyrobe. Dobra poznamka. Vysledne latence se pohybuji v radech mikrosekund, a tak jsou ty 3 ms podle me spatne. Mrknu se na to. Diky za poznamku.

[Pavel Píša]

V noci jsem přehlédl to ms, nějak jsem to automaticky bral jako usec, což odpovídá mému odhadu. Ale i to je při častějším použití strašlivá doba. Při 50kHz vzorkovací frekvenci je to 18% z periody jen na přeprogramování timeru, což je strašné. Ale aplikace na 20 az 50 kHz i s 8254 chodí.

[amnesiac]

Asi je to lehce OT, ale jak je to se spravou pameti ? Mam na mysli situaci, kdy je RT Linuxem rizeno nejake vyrobni zarizeni a dojde fyzicka pamet a musi se swapovat. A jak by to vypadalo pri vycerpani i virtualni pameti ? A vypina se OOM killer ?

Diky

[Pavel Píša]

RT-Linux nevolá z kontextu real-time threadu žádné funkce pro zprávu paměti Linuxu. Funkce kmalloc a vmalloc jsou volané pouze během vytváření RT-Threadů a to je možné pouze z ne-real-time kontextu (při zavádění RT modulů, aplikací, či při zpracování nějakého volání z Linuxového user-space). Starší verze RT-Linuxu nenabízely vůbec možnost dynamické alokace paměti z real-time threadů. V rámci projektu OCERA byl navržený velmi kvalitní alokátor paměti TLSF s omezenou dobou volání a komplexitou O(1), který je nyní součástí vývojové větve RT-Linux GPL. Memory pool pro tento alokátor je však naalokován pouze při zavádění modulů RT-Linuxu a Linuxové jádro ho nemůže měnit.

Shrnutí, out of memory killer může pozabíjet i všechny aplikace běžící v Linuxovém kontextu, ale funkčnost již běžících real-time threadů tím není ovlivněna a real-time část běží například i poté, co jádro Linuxu bídně zhyne na Oops či Panic. RT část se tedy ještě může při detekci tohoto stavu postarat o bezpečné zastavení aplikace, vlaku atd.

Ještě poznámka k Posixovým signálům, RT-Linux GPL implementuje funkce pro generování i zpracování signálů. Oproti standardu však specifikuje, že signál bude řešen nad kontextem toho threadu, který ho registroval. To je pro real-time aplikace výhodnější, protože pomalé zpracování signálu nemůže náhodně zneužívat priority některého z vysoce prioritních threadů.

[nardew]

aky je vlastne rodiel medzi real time, hard real time a nereal time? prosil by som trosku take laickejsie vysvetlnenie...

dik

[belisarivs]

Tehle otazky jsem si vsimnul az ted, ale treba to bude nekoho zajimat.

Rozdil mezi real-time a nereal-time je ten, ze v real-time je snaha za kazdou cenu eliminovat nahodny vyskyt velkych prodlev.

V nerealtime se tytpo vyskytnout mohou.

Pak se real-time deli podle nasazeni na hard a soft.

Je to rozdeleni podle toho, jak vazne by mohly byt dusledky. Pokud muze dojit "pouze" ke zpomaleni provozu, je to soft. Pokud by se ale mohlo stat, ze v pripade vyskytu prodlevy dojde k urazu, poskozeni nebo zniceni neceho, je to hard realtime.

[nardew]

aky je vlastne rodiel medzi real time, hard real time a nereal time? prosil by som trosku take laickejsie vysvetlnenie...

dik