Utilitzant un nucli RT (de baixa latència)

Miguel Mayol, gran seguidor i comentador d'aquest bloc, ens va recomanar un article publicat a Hispasònic sobre la utilització de nuclis RT, que hem decidit publicar i ampliar en algunes de les seves parts. Els nuclis RT permeten un òptim rendiment en algunes situacions partículares, Per exemple, l'edició d'àudio o la utilització d'instruments musicals virtuals.

kernel multitasca

El nucli de Linux, com el de la majoria dels sistemes operatius moderns, és multitasca. Això vol dir que s'estan executant diversos programes a el mateix temps.

En realitat això no passa exactament així. El que es fa és posar els programes en una cua i, un per un, el microprocessador els executa durant una certa quantitat de temps. Un cop esgotat aquest el microprocessador interromp la tasca deixant-la a mitges i dóna pas a la següent. A aquesta quantitat de temps se li denomina quantum o time slice, i no ha de ser constant.

Una bona analogia podria ser el cuiner d'un bar preparant diversos plats alhora: un bocata de llom, una de calls, una amanida mixta ... Ara part el pa, encenc la paella, mentre s'escalfa rento l'enciam, etc.

Si el quantum és prou petit la impressió subjectiva per a un observador lent, com l'ésser humà, és que en comptes d'un processador ràpid executant tasques alternativament tenim un processador lent per a cadascuna elles (diversos cuiners a la mateixa cuina fent lentament cadascun un sol plat).

La commutació de tasques té un cost

La multitasca no és gratis: implica una sobrecàrrega de el processador. En efecte, desallotjar una tasca i carregar la següent és una feina extra. Aquesta operació s'anomena 'canvi de context' o 'commutació de tasques'. Seria més rendible en termes de CPU executar els programes per complet, un per un, que partir-los en 'rodanxes' i anar saltant d'un a un altre. No obstant això, el sistema perdria en interactivitat, no podríem tenir diverses finestres obertes o, en el cas d'un servidor, atendre diverses peticions simultàniament.

Latència i rendiment

Suposem que el nostre cuiner ha de pelar 20 quilos de gambes i desossar 20 quilos d'olives. Com es planifica la feina?

En un cas extrem primer pelaría totes les gambes, es rentaria les mans per no barrejar sabors i després deshuesaría totes les olives. El representarem així:

GGGGGGGGGGGGGGGGGGGGGG ... C AAAAAAAAAAAAAAAAAAAAAA ...

A l'extrem oposat, pelaría una gamba, es rentaria les mans, deshuesaría una oliva, es rentaria les mans ... gamba, oliva, gamba, oliva ... El representarem així:

GCACGCACGCACGCACGCACGCACGCACGCACGCACGCACGCACGCACGCACGCACGCAC ...

La 'C' representa el canvi de context: rentar-se les mans, canviar d'estri ...

A el mateix temps, un cambrer recull les peticions dels clients: «una de gambes!» ... «una de olives!» ... i les trasllada a la cuina.

En el primer cas, suposem que entra un client i demana una ració de gambes. Cap problema, de seguida se li serveix. Però, ¿i si demana olives? El cambrer no podria servir-la fins que totes les gambes estiguessin pelades. En aquest cas la latència, que és el temps que passa des que es fa una petició fins que aquesta és atesa, seria molt alta.

En el segon cas, demani el que demani el client, estarà disponible en poc temps, a més pràcticament igual en tots dos casos. La latència serà baixa, però a un cost: a causa dels canvis de context es produirà una disminució de l'rendiment, entès com la part de el temps durant el qual la CPU està fent tasques directament productives, en lloc de labors de suport.

Evidentment en aquest cas la solució ideal seria un terme mitjà, que dependria de la mida de les racions i de la distribució estadística de les peticions. La teoria de cues és la branca de la matemàtica que s'encarrega d'estudiar aquestes situacions i de donar-los solucions òptimes.

Com es pot veure, latència i rendiment són oposats. Per aquesta raó no és correcte afirmar que els nuclis rt donen més rendiment. Tot el contrari, a l'abaixar la latència empitjoren el rendiment de la màquina i, per tant, són una elecció pèssima per a sistemes que no necessitin respostes superrápidas com, per exemple, servidors web o de bases de dades.

Per contra, els nuclis de baixa latència són ideals en situacions on es necessiti la màxima velocitat de resposta als estímuls externs, com sistemes de control industrial o aplicacions multimèdia interactives, sabent que estem sacrificant part de la potència de la màquina en garantir aquesta ràpida reacció.

Prioritats

Una opció interessant en sistemes multitasca és donar diferents prioritats a les tasques, de manera que les més importants rebin més temps de l'processador i les menys importants menys. En un nucli normal això es fa amb el comandament 'nice'. Si el nostre cuiner espera servir més racions de gambes que d'olives faria bé en dedicar-li més temps a les primeres, lògicament.

Kernel RT (o de baixa latència)

El problema dels nucli normals és que les tasques no es poden interrompre en qualsevol lloc, cal esperar que arribin a certs punts d'execució on ja es poden aturar per commutar a una altra. Això introdueix el que anomenem latència.

Per posar-ho d'una forma simplificada, els nuclis RT permeten interrompre les tasques en més quantitat de llocs que els nuclis normals. Poden fer, per dir-ho, rodanxes més fines de temps, així que la tasca actual serà desallotjada més ràpidament i la nostra tasca prioritària podrà accedir abans a la CPU. Per tant la latència serà més baixa.

Diguem que un nucli RT ens permet deixar una gamba a mig pelar si el que es necessita en aquest moment, urgentment, és posar-se a desossar una oliva com més aviat millor, mentre que en un nucli normal caldria acabar de pelar la gamba.

A més de fer rodanxes més fines, els nuclis RT tenen un sistema de prioritats molt més estricte, on les tasques prioritàries peguen cops de destral sense misericòrdia a les altres (preempting) per fer-se amb el control de la CPU, alentint els altres programes el que sigui necessari per complir els seus requisits.

Quan és important fer servir un nucli RT?

En dos casos:

1) Quan necessitem latències molt baixes, és a dir, reaccions molt ràpides de la màquina. L'exemple més clar és l'execució d'instruments virtuals, on necessites que a l'prémer una tecla d'un teclat MIDI l'instrument soni immediatament.

2) Quan necessitem prioritats molt estrictes, és a dir, que la nostra tasca d'alta prioritat no s'interrompi per res de món (llevat en el cas catastròfic que la CPU estigui tan sobrecarregada que se superi el 100% d'utilització). Per exemple, estem gravant una sessió d'àudio amb Ardour i observant com pugen i baixen els indicadors dels faders. Tant se val si perdem algun quadre de refresc dels faders per tal que el transport de so de l'micròfon a el disc dur no es vegi interromput. Un nucli RT s'alentirà el refresc dels faders tot el que sigui necessari per tal que no es perdi ni una mostra d'àudio.

Dit això, en general els nuclis no RT més recents han millorat molt el seu sistema de planificació de tasques i la seva gestió de prioritats. Si no tens la CPU a el límit de les seves possibilitats (diguem per sota de l'50% d'utilització) o si no us fa res que de tant en tant es produeixi un petit microtall (clic) en el so (els tan temuts xruns), un nucli normal dóna unes prestacions perfectament acceptables.

Què latència és aconsellable?

A mi personalment qualsevol cosa per sota de 10 ms ja em va bé ia partir de 20 ms ja començo a notar el retard clarament. Hi ha gent més exigent.

Instal·lador

En Ubuntu i derivats:

suo apt-get install linux-headers-lowlatency
suo apt-get install linux-lowlatency
sudo update-grub

A l'arrencar es podrà disposar de les dues opcions (el nucli normal i el de baixa latència).

En Arch i derivats:

yaourt -S linux-rt
sudo update-grub

font: Hispasònic