SCHED_DEADLINE v6 - videó demó

 ( trey | 2012. október 29., hétfő - 14:31 )

Juri Lelli nemrég bejelentette a SCHED_DEADLINE (github) patchkészlet v6-os verzióját az LKML-en. A SCHED_DEADLINE nem más, mint az Earliest Deadline First (EDF) ütemezési algoritmus Linux kernelhez készült implementációja. A kód egyelőre még kísérleti és folyamatosan fejlesztés alatt álló, de már most teljesen működőképes valós idejű (real-time) alkalmazások GNU/Linux környezetben való támogatásához. A fejlesztők pozitív visszajelzést kaptak már most az Ericsson-tól, Wind River-től, Porto (ISEP), Trento, Lund és Malardalen egyetemektől.

A fenti videón egy Linux PC vezérel egy invertált ingát, két mérlegkart golyókkal és egy grafikus monitorozó alkalmazást egy időben. További részletek itt.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

2:21-től. Állat.

--
trey @ gépház

Engem a felhasznált kinematika is érdekelne a csuklós-karos/scara robotnál...vajon saját maguk számolták vagy valami modellt használhatnak...?
--------
HOWTO: Zentyal+Zarafa+Setup+Outlook+Thunderbird+mobilephone sync

Na ez tényleg durva. Ahogy elindítja az egyensúlyozást,....és hogy mással is foglalkozik közben, be**arás.

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.

Először mindig a scheduler-t rakom át (elevator).

Honnan hova?

--
trey @ gépház

cfq -> deadline

Na jó, de azok IO ütemezők. Hogy jönnek ide?

--
trey @ gépház

ugy, hogy fogalma sincs, mirol szol a cikk.

Itt leestem a székről.

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.

Akkor valtanod kene deadline utenezore, mer' azzal meg a palca se esett le.

Te is túlnőtted a megengedett súlyhatárt mint NagyZ? :D

rajottel, hogy te sem tudtad felfogni?

pedig mar vartam, hogy benyogje valaki, hogy atvalt erre a schedulerre ubanton, mert hatha gyorsabb lesz a compiz

--
NetBSD - Simplicity is prerequisite for reliability

Majd' én e'. Hátha nem fog akadni a pulseaudio.

olyan isten nincs hogy a pulseaudio ne akadjon....az így jó és kész...így olyan minimál dubsteppes lesz minden :D

A pulseaudio-nak az a baja, hogy szoftverből akarják megcsinálni, amit a hardvernek kellene tudnia. Nálam a harmadik legtöbbet fogyasztó folyamat. Kár hogy ilyen szarul csinálták meg. :)

sed -e 's/, \([^ ]*\).*\. K/, \1 K/ ' -e 's/K.* \([^ ]*\) \([^ ]*\)\./\2\1/'
->
A pulseaudio-nak az a baja, hogy megcsinálták. :-)

Ez szép :-)

A pulseaudio-nak az a nagy előnye, hogy szoftverből megoldotta, amit hardverből nem lehet ;)

Azt nem ertem ebben, hogy az ingas problema egy viszonylag lassu fizikai folyamat, ehhez kepest egy mai PC iszonyu gyors.
Ha van 3 process (monitorozo+2 inga), es 1000 a HZ, egy eleg egyszeru utemezo is 3ms-enkent adna 1ms-et az egyik szabalyzora (feltetelezve, hogy minden max. prociidot ker, es nem sleepel ha nem kell mar neki), ehhez kepest hatalmas kilengeseket produkal. (szandekosan nyilvan lehetne irni szar utemezot is, ami kieheztet, de itt nem az a feladat)
Ha meg egy negymagos gepre jut 3 process (ahogy a kepen latszik), plane.

--
My gold plated butt-plug business is being sued by Apple.
Apparently they have a patent for overpriced crap for arseholes.

Ez az egyik, a másik meg, hogy szerintem egy bonyolultabb feladatnál adott algoritmus futásánál a ciklikus idők nem feltétlen egyformák (nem feltétlen ugyanannyi lépésből fog állni a következő paraméter előállítása), tehát hiába real-time az ütemező és hiába kapja meg a process a cpu szeletet mindenképpen - nem ennek az egyenletességétől fog függeni a művelet elvégezhetősége adott időn belül.

A mérlegnél mi volt a szabályozás lényege? Mert olyan túllövések voltak, hogy öröm nézni.

a "részeg pincér" algoritmus implementációja lehet