Real-time Linux kiválasztása

Fórumok

Sziasztok!

Real-time rendszerhez keresünk megfelelő operációs rendszert (kernel), lehetőleg Linuxot. Jelenleg a legutóbbi Ubuntu LTS verziót használjuk RTKernal patch-el. Ez a rendszer így viszont 1 ms és 500 us közötti válaszidővel rendelkezik. Ezt a reakció időt viszont le kell szorítanunk 50 us-ra.Jó pár tanulmányt és ajánlatot kaptunk. Ami a Linuxokat illeti Red Hat és a Suse Enterprise rendelkezik realtime tulajdonságokkal. A tanulmányok szerint a Red Hat ugyanazzal a kernel-patch-el dolgozik, mint az Ubuntu. Suse viszont rendelkezik saját fejlesztéssel ebben az irányban.

Van esetleg valakinek a témában tapasztalata? Esetleg valami más lehetőség amit meg kellene még vizsgálnunk?

A költségek csökkentése miatt választottuk a Linuxot, természetesen vannak komoly nagyvállalati megoldások, amik egyszerűen teljesítik a követelményeket, ezek viszont nagyon sokba is kerülnek. A licenszenkénti 2-3 ezer euró a maximum amivel számolunk.

Hozzászólások

subscribe

Mire fogjátok használni? (ha publikus)

Lucent/Alcatel-nél tudtommal plan9-t használnak. Esetleg abba is érdemes lenne belenéznetek.

http://doc.cat-v.org/plan_9/real_time/

persze csak ha nem fontos a linux

---------------------------------------------------------------------------------------
Unix is simple. It just takes a genius to understand its simplicity. — Dennis Ritchie

illumos/opensolaris kernel nem jatszik? Alapbol van real time utemezesi osztaly.

További infók:

A szoftver maga HiL-szimulátor(ok) vezérlését végzi. Régi verzióban un. VME Single-Board Computer végezte a vezérlést. Ezt a rendszert már nem fejlesztik tovább és emellett igen költséges is.
Ügyfél kérésére az új rendszereknél radikálisan csökkentenünk kell a költségeket, persze az egyéb komponensek fejlesztése mellett. Így döntöttünk úgy, hogy az egész rendszert átültetjük PC-architektúrára. 1. fázisban a cél 1 ms-os válaszidő volt, amit a linux real-time-kernel. teljesít is.

A következő fázishoz viszont már komolyabb reakció idők kellenek (min 200 us), a cél a 50 us-os reakció idő. Kernel átírással ezt Ubuntu alatt is meg tudjuk oldani, de mielőtt ebbe invesztálnánk, elvileg létező rendszerrel olcsóbban kijönnénk.

Azt hiszem ennél már nem mehetek bele mélyebben, de remélem a lényeg ebből is érthető.

---
fedora user

Szoval valami cel hardvare lesz beleteve a gepbe, ami megszakitast general esemenykor (nagy priolitasu vonara regisztalja magat).
Egy _real-time_ priolitassal rendelkezo user process erre az esemenyre var egy rendszerhivasban.
Esemenyre mondjuk kiir valmit az eszkozre aztan ujra var.

Te a magszakitas es az iras kezdese kozotti atlagos idot mered ugye ? Vagy a maximumot ? Vagy teljesen mas a szituacio ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nem minden tasknak kell ebben a "felbontásban" futnia. Jelenlegi taskok user módban futnak, persze real-time prioritással. Átlagosan olyan max 300 us alatt. Viszont a probléma a jelenlegi kernellel, hogy processzoronként (igazából magonként) futnak kernel taskok, amikkel akármit is csináltunk eddig a scheduler beütemezte őket. Ezzel ha jól emlékszem 200 ms-onként egy kiugró értéket produkálva. Pontos értékre fejből nem emlékszem, de több volt mint 200 ms, és ez bizonyos rendszereknél azonnali leálláshoz vezet.

---
fedora user

> amikkel akármit is csináltunk eddig a scheduler beütemezte őket.

Erről jutott eszembe:

isolcpus — Isolate CPUs from the kernel scheduler.

isolcpus= cpu_number [, cpu_number ,...]

Remove the specified CPUs, as defined by the cpu_number values, from the general kernel SMP balancing and scheduler algroithms. The only way to move a process onto or off an "isolated" CPU is via the CPU affinity syscalls. cpu_number begins at 0, so the maximum value is 1 less than the number of CPUs on the system.

This option is the preferred way to isolate CPUs. The alternative, manually setting the CPU mask of all tasks in the system, can cause problems and suboptimal load balancer performance.

Plusz ez:

http://rt.et.redhat.com/wiki/index.php?title=RHEL-RT_AffinityHowto&prin…

Lehet, hogy hülyeség, de ha ilyen kis reakcióidők kellenek, nem lenne jobb/egyszerűbb valamilyen mikrovezérlőre vagy FPGA/CPLD-re bízni?

Linux kernel helyett esetleg FreeRTOS vagy QNX?

National Instrumenttől vannak az FPGA-k. A Cesys board-jával. http://www.cesys.com/fpga/virtex/pciev4base_en.html

Hardver nem ez én területem, ezért nem is ismerem ki magam igazán. Legutóbbi rendeléskor, majd 2000 euróba került a kártya bevethető állapotban. Csak kíváncsiságból, hogyan lehet hobbiból ilyennel foglalkozni? Vagy én értettem félre, és nem arra gondoltál, hogy maga a hardver érdekel?

---
fedora user

Ez megint nem igazán az én területem, így nem tudok részleteket. Amiről én tudok, hogy a "kis" szimulátorokon is szenvedés volt elérni vele amit akartak. Aztán a komplex rendszereknél, ahol több kisebb szimulátor van "hálózatba" kapcsolva már semmire sem mentek vele.

Nekem azt az utasítást adták, hogy még véletlenül se gondoljak az LV-re. Viszont nekem ami igazi argumentum, hogy az ügyfelek se akarják látni.

Sajnos konkrét adatokat, példákat nem tudok, szerencsére én soha nem dolgoztam vele. De a cégnél mindenki utálja.
---
fedora user

A linuxcnc.org-on megtalálható emc2-vel kísérleteztem. A látencia mérőjével nekem olyan 30us körüli látencia jött ki egy sima irodai PC-vel. Ott azt írják, hogy a látenciát főleg annak a jitterét nagyon meg tudja dobni az alaplapi VGA. Egy egyszerű akár AGP grafikus kártya sokat segíthet.

Ez a látencia növekedés csak a PCI csatolós inegrált vga-k, ethernet és hang chipekre igaz.
Ráadásul ez az idő nem konstans hanem a gép PCI terhelésének függvényében változik.
Erősen függ még a chipkészletben megvalósított PCI buffer kezelésétől is.(a bios-ban a látencia elvileg állítható.)
A PCI bus az shared bus.
A PCIe az point to point bus.
Az AGP olyan speciális PCI bus ami nem shared. Ezért javít a jitteren.

Egy megjegyzés: a real-time az informatikában NEM azt jelenti, hogy "gyors", hanem azt, hogy a rendszer válaszideje egy jól meghatározott idő alatt marad.

Ha a válaszidőt akarjátok csökkenteni, akkor nem "real-time-abb" kernel kell nektek, hanem gyorsabb gép (illetve skálázhatóbb architektúra a programotokhoz, ha elosztható a terhelés).

+1
En is ugy tudom, hogy egy komplex multitaskos OS-t aligha lehet igazan RT celokra hasznalni. Lehet mindenfele schedulerekkel bohockodni, de barmikor tortenhet egy olyan esemeny, ami hatasara megno a valaszido, hiszen mar egy malloc() valaszideje sem garantalt.
Szoval ha kritikus helyre kell RT cucc, akkor mindenkepp celeszkozt kell ra kesziteni...

Ez pontosan így igaz, csak ahogy én értelmeztem a probléma leírását náluk még a hard-realtime feltétel sem igazán teljesül, azaz hiába raknak alá gyorsabb vasat, attól még néha befigyel egy-egy megnövekedett válaszidő.

Azt sem igazán értem, hogy miért kész disztróval próbálkoznak, amikor ehhez a feladathoz nekik kéne egy realtime kernelt összeállítani célzottan a feladataikhoz, majd erre felépíteni a minimálisan szükséges környezetet.

A probléma nem ezzel van. Egyébként a hardver: speciális alaplapon 2x 2.4 GHz-es 4 magos CPU, 8 GB RAM.

A probléma azzal van, hogy ha ciklusonként pl. 100 us 1 bit-et írunk a hardverre, ez elég gyors, hogy ne történjen fenn akadás. De bizonyos időköznéként a scheduler újra ütemezi a processzeket. Amivel eddig próbálkoztunk, azok nem működtek. A fent említett "isolcpus"-ról én még nem hallottam, de majd utána nézek, lehet ez már segít nekünk.
---
fedora user