LinuxCNC késleltetési tesztek Intel D525MW alaplappal

Üdvözöllek kedves Látogató!

Az előző postban az RTLinux kernel sajátosságaival foglalkoztam, és ígértem, hogy valami közérthetőbb formában bemutatom a gyakorlatban mit is jelent mindez.

A teszt alanya egy Intel D525MW alaplap. Nagyon sokan dícsérik, nagyszerű kis cucc.

Amit érdemes tudni a "deszkáról" :

• Mini-ITX méretű alaplap (170mm X 170mm) 
• Passzív hűtés - nincs hangos, zörgő, beálló ventillátor
• Intel Atom 252 processzor
• Egy LPT port és egy PCI kártyahely - ideális kisebb LPT portos géphez, de akár a Mesa 5i25 kártyát is használhatjuk
• Egy rakat USB port, alaplapi VGA, max. 4GB RAM

A leendő vezérlés másik fontos eleme a Kingston 8GB SSD lemez:

Jelentősen gyorsabb mint a hagyományos merevlemezek, nincs mozgó alkatrész, kis helyen elfér és a kapacitása is bőven elég egy jó kis LinuxCNC rendszerhez.  A gyári CD-ről a már részletezett módon istalláltam az alaprendszert, majd volt egy uprade, egy két kisebb kényelmi dolog (Chromium böngésző, Midnight Commander) és még alig léptem túl a 4GB-t. 

Ezt a  konfigurációt a Pico PSU fogja teljessé tenni. A PC-s oldali konfiguráció így kis helyen elfér, üzembiztos és hatékony minden szempontból.

Akkor nézzük mit mutatnak sorban a késleltetési tesztek. Minden tesztet úgy futtattam, hogy ment egy Youtube-os (kötelezően CNC témájú) videó a Firefoxban, hasonlóan a Chromiumban is ment egy videó, a glxgears nyomta a 3D grafikát. Jelenleg 2GB RAM van az alaplapon.

Ahogy azt említettem, a Multithread (többszálú futtatás) funkcionalitást le kell tiltani a BIOS-ban a valós idejű feldolgozás érdekében. De azért nézzük mit mutat a teszt bekapcsolt Multithread mellett:

Természetesen itt még nincs dedikálva egyik processzornak a valós idejű feldolgozás (isolcpus=1 kernel paraméter jelentené azt). Amit érdemes megfigyelni: a Multithread miatt négy proci látszik, és nagyjából mindegyik hasonló leterheltséget mutat. Eddig ez nem annyira izgalmas, a lényeg inkább a késleltetési teszt eredménye:

a jitter 37,8 microszekundum. Ez nem olyan rossz, de jelentősen lehet rajta javítani.

Akövetkező eset, amikor nincs Multithread:

Érdekes, hogy a késleltetési teszt még rosszabb eredményt hozott. Itt már csak két CPU látszik, de még mindig nincsenek leválasztva a valós idejű folyamatok.

És most vessünk egy pillantást arra, amiért az egész kernel tuningra szükség volt:

Jitter: 6,7 és 8,2 mikroszekundum !!! Ez már úgy történt, hogy a boot folyamat elején a kernel az isolcpus=1 paramétert megkapta, így a legnagyobb számú processzor a valós idejű feladatokkal foglalkozik csak. Igaz a CPU1 ki van hajtva majdnem 100%-ra, de ettől nekünk a LinuxCNC vígan elmegy böngészés és minden más feladat mellett. 

A teljesség kedvéért legyen itt annak a tesztnek az eredménye, amikor bekapcsolt Multithread funkcionalitásnál lefoglaltam egy CPU-t a valós idejű feladatokra:

Jól látszik ismét, hogy négy CPU dolgozik, de ha egyik csak a valós idejű feladatokkal van lefoglalva, akkor a nagy pontosságot igénylő léptetési frekvenciát duplájára lehet felvinni.

Akit esetleg érdekel,  további teszteket itt lehet megtekinteni.

A végére még egy megjegyzés ami a kernel témaköréhez tartozik:

Nincs "gyári" 64 bites kernel a LinuxCNC-hez, nem is tervezik annak kiadását, ugyanis semmiféle haszonnal nem járna a CNC vezérlés szempontjából. Használd bátran a 32 bites verziót, egy megfelelő alaplappal és jó beállításokkal bőven elég.  

RTLinux - a valós idejű rendszermagról néhány szóban

A valós idejű rendszermag szükségességének megértéséhez meg kell vizsgálni, hogyan működik az általános linux rendszermag (kernel). A Linux rendszermag szétválasztja a hardvert a felhasználói szintű feladatatoktól. A rendszermag időzítő algoritmusokat ún. ütemezőket használ és minden elvégzendő feladathoz hozzárendel egy prioritást úgy, hogy a lehető legjobb átlagos teljesítményt és áteresztőképességet biztosítsa. Tehát a kernel fel tudja függeszteni bármely felhasználói feladat végrehajtását amennyiben az kifut a rá kimért időszeletből.  Az ütemezők,  az eszközmeghajtók, a nem megszakítható rendszerhívások, a megszakítások letiltása és a virtuális memória használata a kiszámíthatatlanság forrásai. Ezen okok miatt nem hajtódhatnak végre a valós idejű feladatok akadályok nélkül.

Nagyon egyszerű példát használva, ha egy MP3 fájl lejátszása történik és elfogy a feladatra kirótt időszelet, akkor a kernel felfüggeszti a lejátszást és átadja a CPU-t a soron következő feladatra, például a böngészőnek vagy a grafikai megjelenítésnek. Ekkor a lejátszás folytonossága megakad, mert az ütemező megpróbállja igazságosan elosztani a rendelkezésre álló erőforrást.

A valós idejű kernelnek garantálnia kell az alatta futó folyamatok időzítési követelményeit. Ezt úgy valósítja meg, hogy eltávolítja a fent említett  kiszámíthatatlansági tényezőket. Úgy is felfoghatjuk a valós idejű Linux kernelt, mint ami a hardver és az általános Linux kernel között foglal helyet. A Linux kernel úgy látja a valós idejű szintet mint a hardvert. A felhasználó most már hozzárendelhet minden feladathoz külön-külön prioritást saját igényei szerint,  elérheti a folyamatok  megfelelő időzítését az ütemező, a prioritások, a végrehajtás gyakorisága és más tényezők figyelembevételével.

A valós idejű rendszermag a legksiebb prioritást rendeli az általános Linux kernelhez, a felhasználói szintű folyamatok pedig valós időben kerülnek végrehajtásra. 

A valós idejű végrehajtás a hardver megszakítások eltérítésével oldható meg. Csak a valós idejű kernel megszakításai kerülnek feldolgozásra, minden más megszakítást visszatart a rendszer és mint szoftveres megszakítást továbbad az általános Linux kernelnek amikor a valós idejű kernel éppen szabad, így az, ebben a szabad időben feldolgozhatja  a megszakítást.

A valós idejű feladatok privilegizáltak, azaz közvetlenül hozzáférnek a hardverhez, és emellett nem használnak virtuális memóriát. Ezek a valós idejű feladatok Linux modulként kerülnek megírásra és dinamikusan töltődnek be a memóriába.

A valós idejű Linux kernel együtt él az általános Linux kernellel, azt érintetlenül hagyva. Viszonylag egyszerű módosításokkal megoldott, hogy a meglévő Linux rendszermag valós idejűvé válik, nem befolyásolva a Linux további fejlesztését.

Érdemes megjegyezni, hogy egy nagyszerű magyar programozó, Molnár Ingó nevéhz fűződik a Linux ütemezőjének továbbfejlesztése, munkája nagyon nagy mértékben hozzájárult a valós idejű ütemező jelenlegi képességeihez.

A fentiek csak egy rövid betekintést nyújtanak a valós idejű rendszermag filozófiájába, valószínű, hogy ennyi elégséges a hétköznapi LinuxCNC felhasználónak.

A gyakorlatban a legtöbb esetben az alábbi beállításokat érdemes megtenni:

A)  A hyperthreading (többszálú végrahajtás) opciót a BIOS-ban ki kell kapcsolni, ezzel javulhat a rendszer válaszideje, csökkenhet a késleltetési idő (latency time)

B)  A valós idejű kernel inításakor az "isolcpus=1" opciót kell megadni. Ezzel a valós idejű feladatokra dedikáltan hozzárendeljük a legnagyobb sorszámú processzort (a sorszámozás 0-tól kezdődik), jelentősen javítva a rendszer válaszidején

Ennek a lépései a következőek:

Sajnos nincs egyszerű és minden Linux verzióra működő megoldás, mert a bootloader-től és annak verzójától is függ a dolog. Ami itt leírásra kerül az A GRUB2-re érvényes (a 10.04-es Ubuntu-ban ez van):

Nyissuk meg a  /etc/default/grub fájlt:

sudo gedit /etc/default/grub

keressük meg a sort ami tartalmazza ezt:

GRUB_CMDLINE_LINUX_DEFAULT 

Nálam ez így nézett ki:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

és írjuk át erre:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash isolcpus=1"

Mentsük el és olvastassuk fel a GRUB-bal a változást:

sudo update-grub

Bootoljunk újra és teszteljük a rendszert!

A késleltetési teszt futtatásakor indítsuk el a böngészőt és nézzünk rajta egy videót, futtassunk parancssorból a "glxgears" programot és egyáltalán nyúzzuk a gépet, legalább 15 percig.

 A Linux CNC-t (régi nevén EMC vagy EMC2) _NE_ futtassuk a teszt alatt!!!

Rövidesen teszek fel teszteket képernyőképekkel, hogy ne legyen ennyire száraz a téma.