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.
- 4960 megtekintés
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
- A hozzászóláshoz be kell jelentkezni
illumos/opensolaris kernel nem jatszik? Alapbol van real time utemezesi osztaly.
- A hozzászóláshoz be kell jelentkezni
Mindezt milyen hardware produkálja ?
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Valami hasonló.
Hardverről beolvas a szoftver egy értéket, elvégzi a szükséges számolásokat, majd visszaírja a hardverre. Ez az egész nem tarthat tovább a fent megadott időknél. Szóval így nézve, akkor a maximum értékről van szó.
---
fedora user
- A hozzászóláshoz be kell jelentkezni
Hany szazalekban van most 100 ill. 50 usec felett ?
Magok szama (mindig?) tobb/egyenlo/kevesebb mint real time szalak szama ? (rovid ideig eloket is bele szamitva)
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
> 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…
- A hozzászóláshoz be kell jelentkezni
Eddig ezzel még nem próbálkoztunk, meg fogom nézni közelebbről. Köszi a tippet!
---
fedora user
- A hozzászóláshoz be kell jelentkezni
PCI busznál az 50us necces átlag PC-n a látens idők miatt.
Fürgébb csatoló kell PCIx vagy PCIe .
- A hozzászóláshoz be kell jelentkezni
PCI-Express kártyában van olyan ahol a teoretikus adatcsere 32 bit / 3 us. Még nem teszteltük, ezért nem tudom megerősíteni.
---
fedora user
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
+1 megfontolando
Mennyire bonyolult az a szamitas, amit el kell vegeznie a pc-nek?
--
Tudod te, mennyi lóvé fér egy Alstom-kocsi dobozába? :)) - laspalmas, VB
- A hozzászóláshoz be kell jelentkezni
Azért ez ennyire nem egyszerű, persze amit lehet azt az FPGA-ra bízzuk.
---
fedora user
- A hozzászóláshoz be kell jelentkezni
Értem.
(Ha nem titkos, milyen FPGA-t használtok? Hobbi szinten el szeretnék kezdeni velük foglalkozni.)
- A hozzászóláshoz be kell jelentkezni
tanulni ezt:
http://logsys.mit.bme.hu/
(korábbi oldalra menj)
Xilinx ISE ingyenes kell hozza.
(már bocs hogy idepofázok, gabu óta elkanászodtam:-)
- A hozzászóláshoz be kell jelentkezni
kösz
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
A 2000 euróssal sehogy, de nyilván vannak olcsóbbak/lassabbak. Leginkább uC-kel foglalkozok, de érdekel minden, ami a környékén van (az elektronika és a programozás is) :-)
- A hozzászóláshoz be kell jelentkezni
NI -nak lehet van egy masik termeke ami erdekelehet: Labview RT, de ez sem az olcsosagrol hires.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
LVRT-hez minimum az LV Full :D (Base-sel nemmegy) ami igy 1,3 misi csak az sw :)
(kb €4800)
- A hozzászóláshoz be kell jelentkezni
A cucc minőségileg is hagy kívánni valót maga után. És a "szimulátor hálózattal" se könnyen boldogul.
---
fedora user
- A hozzászóláshoz be kell jelentkezni
bővebben?
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
Nem vagy egyedül :-)
Sajnos nekem kötelező. Most épp egy MT19937-et kellett implementálnom, de netuddmeg...
Nem programozónak való, hanem villamosmérnöknek, böködni.
- A hozzászóláshoz be kell jelentkezni
valamely RIO cucc?
- A hozzászóláshoz be kell jelentkezni
Igen, vagy FPGA (ami host felé serial vagy usb-n at pofazik), vagy a linuxot tágabban értelmezitek.
- A hozzászóláshoz be kell jelentkezni
Vagy a Linux is az FPGA -n megy jobb perfiaria eleressel :) Mar ha van penzed akkora FPGA -ra :)
MicroBlaze
OpenRisc
PowerPC 405
...
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
sub
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
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).
- A hozzászóláshoz be kell jelentkezni
Vagy nem:)
- A hozzászóláshoz be kell jelentkezni
+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...
- A hozzászóláshoz be kell jelentkezni
Ha valaki egy kritikus taszkban malloc() hívást végez, az rögtön el is felejtheti ezeket a válaszidőket bármilyen rendszeren.
---
fedora user
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
Erre a válasz egyszerű. Drága. Ha készen kapunk valamit azzal sok pénzt spórolunk. Nem biztos, hogy a legjobb megoldás, de a menedzsereink így gondolkodnak.
---
fedora user
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Fel kell rakni a kritikus részt kernelbe. :)
- A hozzászóláshoz be kell jelentkezni
Hahó!
Valami ilyesmire gondoltál?
G.
============================================
"Share what you know. Learn what you don't."
- A hozzászóláshoz be kell jelentkezni