SUSE Linux Enterprise Real Time 10

Novell

A Novell bejelentette a SUSE Linux Enterprise Real Time 10 - "a piacon jelenleg egyetlen, nyílt forrású, vállalati-szintű, valósidejű operációs rendszer" - termékének elérhetőségét. A bejelentés itt.

( MBence | 2007. 11. 28., sze – 18:15 )

Lehet, h láma kérdés meg minden, de mi az a "valósidejű operációs rendszer"? Miben különbözik egy "rendes" oprendszertől (pl. Ubuntu Linux, WinXP)? Különbözik egyáltalán?

Kereskedelmi termékről beszélünk szerintem. Nem tudom, hogy van-e a Red Hat-nak, vagy az Ubuntu-nak "dobozos" real-time OS-e. Persze a cégek nyilván szeretnek a sajtóhírekben egy kicsit túlozni. Szerintem a Novell-t kellene megkérdezni, hogy mire alapozza ezt az állítást. Nincs kizárva, hogy igaza van.

--
trey @ gépház

A linuxcnc.org-on találsz RTAI patchelt kernellel Ubuntu bootcd-t. Sok sikert hozzá!
:-)

Persze attól még lehet, hogy se nem vállalati, se nem Real Time OS.

Van még ezen kívül egy-két konkuráló Real Time kiegészítés/folt a linux kernelhez. A Google tudja.

Mindenesetre igyekszem a "vállalatnál" elterjeszteni, mert a Win98-on futtatott DOS-os vezérlőszofver kezd az agyamra menni, azon túl hogy nem tréfadolog egy elszabadult, több ezres fordulaton pörgő tokmány, meg az a pár száz kilós fémtömeg körülötte.

szerk.:
Itt van még két hasznos hivatkozás:
http://en.wikipedia.org/wiki/RTAI
http://en.wikipedia.org/wiki/Xenomai

Ha jól sejtem ez egy CNC eszterga lehet, vagy legalábbis valami szerszámgép. Nos, tényleg ijesztően néz ki rajta a win, de nem kell félni, az üzemi paramétereket nem az állítja elő. Általában egy (vagy több) meglehetősen robusztus mikrovezérlő mozgatja a vasat. Sőt, néha még ez is szét van szedve feladatonként, pl. az interpolátor teljesen önálló vason fut, a motorvezérlés (valójában szabályozás), és az interfészkezelés szintén. Ezeknek vannak saját (akár hardveresen is!) megvalósított öndiagnosztikai/biztonsági elemei is. A win az csak egy UI ebben az esetben, igaz, kétségtelenül ronda. Kipróbálhatod, vannak olyan gépek, hogy elindítod a megmunkálást, akkor a kezelőfelületet ki is kapcsolhatod, attól ő még működik (értelemszerűen a vészleállítás és a fontosabb kezelőszervek ilyenkor is működőképesek).

valaha még mikrokerneles operációs rendszereket lehetett igazi realtime rendszernek hívni. qnx ill integrity voltak a legismertebbek. gondolom a mostanában gombamód szaporodó low latency linux kernel patchek lehetővé teszik a realtime képességeket normál gnu/linux rendszeren is, persze egy mostani gyors processzorral párosítva.
kíváncsi vagyok, hogy pl egy nagy felbontású videofilet le lehet e játszani szaggatás mentesen ezen a susen úgy, hogy közben jó sok szálon számításigényes feladatokkal terhelem a processzort.
imho a gnu/linux világban a DROPS sokkal közelebb áll a valódi realtimehoz, persze ez még csak kísérleti rendszer. ez a suse variáns inkább egy marketing realtime os :)

( asm v | 2007. 11. 28., sze – 19:57 )

En ugy tudom, hogy a napjainkban hasznalatos komplex architekturak kizarjak a real-time viselkedest.
De sw szinten is bonyolult a helyzet, hiszen mar maga a "malloc" parancs sem real-time, azt meg nem hiszem, hogy az osszes mallocot lecsereltek volna vmi masra :)

Itt gondolom arrol van szo, hogy tettek a kernelbe vmi uj "fair" utemezot...

Visszamenőleg nem tudom, melyik verziószám óta került egyáltalán szóba, de a linux kernel "soft-realtime". A 2.6-os ütemezője egy kicsit feszesebb tud lenni ezen a téren, de nem "hard-realtime".
Létezik RTlinux, hogy abban mennyi változás van a kernelben, nem tudom.
Amúgy tényleg QNX és tsai.

( turul16 v | 2007. 11. 29., cs – 08:51 )

Mar csak arra kell rajonni mire jo egy RTOS egy mezei nagy valalatnal. :)

iHawk/RedHawk vagy mifenet lattam hirdetve , de azt olyan gepekkel szállítottak amiben komoly specialis I/O hardware is volt.

az enterprise a következőket jelenti a Linux termékeknél, legyen az bármilyen disztró:
- garantált fejlesztési ciklusok
- garantált támogatás x ideig + karbantartás y ideig
- worldwide support
- garantált API készlet x ideig

vagyis egy nagyvállalat hosszabb távon tervezhet egy kiadással kapcsolatban.
röviden ennyi

Van egy linux szervered, mely a nukleáris rakéta kilövését és célba juttatását irányítja.
Egyik államfő megharagszik a másikra, indítja a rakétát. Visszaszámlálás közbe jön a másik politikustól egy kisebb összegű (néhány milliárd :P) pénzt békülés céljából. Leüti a kollega a nagy piros stop gombot az utolső pillanatba, de sajnos a rendszer épp el volt foglalva mással, nem reagált (időben) az inputra, rakéta elindul.... Na ez real time esetén nem fordulhat elő.
A lényeg, hogy meghatározott időn belúl garantáltan processzoridőhoz jut a program.

Olyan ez, mint a Token Bus és Token Ring..... A mai napig (bár már nagyon kevés helyen) gyártósoroknál még mindig token-es hálót használnak a gépek közötti kommunikációra.
--
Discover It - Have a lot of fun!

vagy nem
attól függ, hogy a megszakításokat hogyan maszkolják, illetve feltételesen hogyan engedélyezik.
x86 esetében ezeket nem ismerem, de egyéb beágyzott eszközöknél pl nem egyértelmű, hogy mindíg pikk-pakk megy. már PIC-ek esetében is prioritásos megszakításkezelés van, szóval egy interrupt is várhat...

Van egy garantalt maximalis valaszido (altalaban legfeljebb parszaz ms), amelyen belul mindenkeppen vezerlest kapnak a programok, fuggetlenul attol, hogy a rendszeren futo tobbi cucc mennyire reszeli pl. az IO/VM alrendszereket. Messze nem trivialis, nem egy NMI szintu dologrol van szo. A melohelyemen rendszeren tesztelnek RT teljesitmenyt, egyelore a Solaris nyeresre all az RT patch-es tuningolt linux elleneben. Mondjuk nem meglepo, mert utobbi a nevevel ellentetben inkabb preempt patch, mint realtime.

Ha kvázi az az egy alkalmazás fut akkor igen.
Abba se vagyok biztos, hogy a berkéző csomag kikerülhet a swapre míg a kernel-nél van, de ha kikerülhet akkor is tuti elhanyagolható eséllyel (kb. OOM killer inditasan tanakszik a kernel:)).

Mésrészt nem értem miért van swap a rendszerbe ilyenkor ? (Vagy mikoze a kernelnek ahhoz, hogy 100Gb DB dolgozol 2Gb RAMmal es a valaszhoz 10Gb -t kell atnyalni ?)
see: MAP_NORESERVE

O_DIRECT write után érkezés sorendbe kurva hamar.O_DIRCET nelkül megvárja még kikivákozó csomag mérete eléri egy normál csomag méretet (higher throughput vs. low latency).

(e)poll, async i/o ,selcet,read ..stb késleltetései sincsenek az egekben, tudomásom szerint hamar eljut az infó a várakozó processekhez, legkesőbb az idő szeletük normál kezdetén.
Ha tranzakció kezelő gépen magonként egy nagyobb feladat fut akkor az kvázi azonnali, mert mást nem is igen tehet a rendszer :)

Ahhoz, hogy egy alkalmazás inputra reagáljon, be kell jönnie az inputnak , fel kell dolgozni ki kell küldeni az outputot. Az I/O gyors lezajlása még nem jelnti azt, hogy gyors lessz a válasz, mert a feldolgozás alatt az ütemző elveheti tőle a CPU -t. (Ha nem egy idő szelet alatt tudja az eszközd megadni a választ akkor miről beszélünk ?, Inputkor hiába kapná meg azonnal CPU-t, (mennyi időre is szeretnéd a CPU-t az azonnali válaszhoz? , mit csináljon, ha közben újabb I/O van.. ?, mennyi időt kapjon a másik folyamat.. és harmadik ...) )
Linux kernel-nek másodpercenként 100..1000 szer szokása dönteni, hogy melyik folyamté legyen a köv. idő szelt.

Ha nem futtatsz 100 quake-t tranzakció kezelés közben, miért jönne össze akkor 200ms késleltetés ?

Vicces hozzaszolas... most komolyan. Nem fognak minden egyes alkalmazashoz kulon gepet dedikalni. Epp errol szol az RT kernel: tobbe-kevesbe fuggetlenul attol, mas alkalmazasok mennyire tekerik pl. IO-ban a rendszert, egy adott alkalmazas veges idon belul megkapja a szukseges eroforrasokat. Ebbe nem fer bele az, hogy a kernel VM/ IO/ stb. alrendszerei meddig molyolnak, es kozben minden mas blokkolva van. Alapvetoen mashogy kell felepiteni egy RT OS kernelet.

Viccess :D
Még is több folyamotos rendszerben akkarsz specko RTOS kernelel tranzakciot (gondlom 5/s azert joval tobbet) kezelni egy mezei alkalmazassal, a 0.2s miatt.
Biztos még javaban is :)

Az RTOS kernel nem arrol szol, hogy minden(bármennyi) (tetszőleges)alkalmazast "kiszolgálunk" garantált időn belül _MINDEN_ esetben, mert ez lehetetlen!!!

szerk:
man sched_setscheduler

SZVSZ meg mindig fogalmad sincs, mirol beszeltem fentebb, sebaj. Talan majd egyszer latsz kozelrol par igazi enterprise rendszert, es megvilagosodsz... Persze az is lehet, hogy a kollegaim (biztos total amator banda, a Morgan Stanley unix engineering csoportja amugy) es a teljes RedHat fejlesztocsapat egyuttveve nem olyan penge, mint te, biztos ezert nem tudunk realtime mukodest osszehozni a par ezer szerverunkon.

:)

Most neztem page fault bol szarmazo idoket MAP_PRIVATE|MAP_ANONYMOUS lapoknal, hat kurva nagyok. Nalatok hanyad resze ugy kb.? (Meg allitok par dolgon, par merest nezek)

Ha mondasz szamadatokat, hogy mibol mennyi kell idok, kapacitas .. stb, milyen jelegu lekerdezesek, adat frissitesek , mennyi HUF van -ra, mennyi a fejlesztesre szant ido, mondok neked alternativ megoldast, valoszinuleg a vassal kezdem.. :D
passwd : Virtex5 (Nalam az igazi RealTime valahol itt van)

szerk:
Virtex5-re hegeszto emberek joval dragabbak szerintem.
Es az ugynevezett igazi enterprise -hoz nem szeretnek kozel kerulni, reszben az "okos" megoldasok miatt.
szerk2:
Miert kell 200ms MAXIMUM ? Mihez kapcsolodik ?

Bocs, reméltem kapok adatokat, ha kicsit aggreszív vagyok, hogy jobban el tudjam képzelni az igényeket.

Amit én használnék szoftvert (1000 gépböl találgatva, hogy miről lehet szó :)) többségén futó valamit én nem nevezném UNIX szerű OS -nek (még, ha kód részek kerülnének bele a Linuxból akkor sem), de, ha minden képpen, be kéne sorolni akkor RTOS-nak besorolhatám, de leginkább cél specfikus gányolás :)

"Nem fognak minden egyes alkalmazashoz kulon gepet dedikalni." még mindig nem tudom hova tenni, ha 1000 gépről van szó, ami ezt az egy dolgot hivatott megoldani.

A RedHat valóban nem "penge": rendesen kiszorultak a nasdaqtól (elegük lett abból, hogy az RT garanciát akkora túlméretezéssel biztosítják, hogy a rendes load 1%-nyi a teljes kapacitásnak). Ahogyan Bryan Cantrill mondta: a legjobb linuxos engineering csoport nem a RedHat-nál van. Egyébként pont tegnap tartott előadást Josling a sr-001-el kapcsolatban, meg az RT solaris és a rajta ülő VM-ről.

( godot v | 2007. 11. 29., cs – 11:45 )

Monta Vista Linux??

Egy ket Cisco cuccban ez fut pl. ACE

( 2Geza | 2007. 11. 30., p – 14:22 )

Jo jo, relatime, de fut VMWare-ben? :)