Een RT-kernel gebruiken (lage latentie)

Miguel Mayol, een geweldige volgeling en commentator van deze blog, heeft een artikel aanbevolen in Spaanspas over het gebruik van RT-kernels, die we hebben besloten te publiceren en uit te breiden in sommige delen ervan. De RT-pitten toestaan ​​een optimale prestatie in bepaalde bepaalde situatiesBijvoorbeeld audiobewerking of het gebruik van virtuele muziekinstrumenten.

Multitasking-kernel

De Linux-kernel is, net als die van de meeste moderne besturingssystemen, multitasking. Dit betekent dat er meerdere programma's tegelijkertijd draaien.

In werkelijkheid is dit niet precies het geval. Wat u doet, is de programma's in een wachtrij plaatsen en een voor een voert de microprocessor ze een bepaalde tijd uit. Zodra dit is uitgeput, onderbreekt de microprocessor de taak, laat deze halverwege en maakt plaats voor de volgende. Deze hoeveelheid tijd wordt een kwantum- of tijdschijf genoemd en hoeft niet constant te zijn.

Een goede analogie zou kunnen zijn dat de kok in een bar meerdere gerechten tegelijkertijd bereidt: een broodje lendenen, een broodje pens, een gemengde salade ... Nu breek ik het brood, zet ik de pan aan, terwijl hij aan het opwarmen is was ik de sla, enz.

Als het kwantum klein genoeg is, is de subjectieve indruk voor een langzame waarnemer, zoals de mens, dat in plaats van een snelle processor die afwisselend taken uitvoert, we een langzame processor hebben voor elk van hen (meerdere koks in dezelfde keuken doen langzaam elk een enkele bord).

Het wisselen van taken brengt kosten met zich mee

Multitasking is niet gratis: het gaat om processoroverhead. Het is inderdaad extra werk om de ene taak uit te zetten en de volgende in te laden. Deze bewerking wordt 'contextwisseling' of 'taakwisseling' genoemd. Het zou qua CPU kosteneffectiever zijn om de programma's één voor één volledig uit te voeren dan ze in 'plakjes' te snijden en van de een naar de ander te springen. Het systeem zou echter aan interactiviteit verliezen, we zouden niet meerdere vensters kunnen openen of, in het geval van een server, meerdere verzoeken tegelijk kunnen behandelen.

Latentie en prestaties

Stel dat onze kok 20 kilo garnalen moet schillen en 20 kilo olijven moet pitten. Hoe is het werk gepland?

In het uiterste geval schilde hij eerst alle garnalen, was hij zijn handen om te voorkomen dat smaken door elkaar gingen en pitte hij vervolgens alle olijven. We zullen het als volgt vertegenwoordigen:

GGGGGGGGGGGGGGGGGGGGGG ... C AAAAAAAAAAAAAAAAAAAAAA ...

Aan het andere uiterste, zou hij een garnaal schillen, zijn handen wassen, een olijf pitten, zijn handen wassen ... Garnaal, Olijf, Garnaal, Olijf ... We zullen het als volgt voorstellen:

GCACGCACGCACGCACGCACGCACGCACGCACGCACGCACGCACGCACGCACGCAC…

De 'C' staat voor de verandering in context: handen wassen, keukengerei verwisselen ...

Tegelijkertijd verzamelt een ober de verzoeken van de klanten: "Een met garnalen!" ... "Een met olijven!" ... en brengt ze naar de keuken.

Stel in het eerste geval dat een klant binnenkomt en om een ​​portie garnalen vraagt. Geen probleem, het wordt direct geserveerd. Maar wat als hij om olijven vraagt? De ober kon het pas serveren als alle garnalen waren gepeld. In dit geval zou de latentie, de tijd die verstrijkt vanaf het moment dat een verzoek wordt gedaan totdat het wordt beantwoord, erg hoog zijn.

In het tweede geval, wat de klant ook vraagt, het zal in korte tijd beschikbaar zijn, ook in beide gevallen praktisch hetzelfde. De latentie zal laag zijn, maar tegen een kostprijs: als gevolg van contextveranderingen zal de prestatie afnemen, begrepen als het deel van de tijd waarin de CPU direct productieve taken uitvoert, in plaats van ondersteunende taken.

In dit geval zou de ideale oplossing natuurlijk een middenweg zijn, die zou afhangen van de grootte van de rantsoenen en de statistische verdeling van de verzoeken. Wachtrijtheorie is de tak van de wiskunde die verantwoordelijk is voor het bestuderen van deze situaties en het geven van optimale oplossingen.

Zoals u kunt zien, zijn latentie en prestaties tegenpolen. Om deze reden is het niet correct om te zeggen dat rt-kernels betere prestaties leveren. Integendeel, het verlagen van de latentie vermindert de machineprestaties en is daarom een ​​slechte keuze voor systemen die geen supersnelle reacties vereisen, zoals web- of databaseservers.

Integendeel, kernels met lage latentie zijn ideaal in situaties waar de maximale reactiesnelheid op externe stimuli nodig is, zoals industriële besturingssystemen of interactieve multimediatoepassingen, wetende dat we een deel van de kracht van de machine opofferen om te garanderen dat snelle reactie.

prioriteiten

Een interessante optie bij multitasking-systemen is om verschillende prioriteiten aan de taken te geven, zodanig dat de belangrijkste meer tijd van de processor krijgen en de minder belangrijke minder. In een normale kernel doe je dit met het 'nice' commando. Als onze kok verwacht meer porties garnalen te serveren dan olijven, doet hij er natuurlijk goed aan om meer tijd aan de eerste te besteden.

Kernel RT (of lage latentie)

Het probleem met normale kernels is dat taken nergens kunnen worden onderbroken, je moet wachten tot ze bepaalde uitvoeringspunten bereiken waar ze kunnen worden gestopt om naar een andere over te schakelen. Dit introduceert wat we latentie noemen.

Simpel gezegd, RT-kernels staan ​​onderbrekende taken op meer plaatsen toe dan normale kernels. Ze kunnen als het ware dunnere tijdsbestekken doen, zodat de huidige taak sneller zal worden verdreven en onze prioriteitstaak sneller toegang heeft tot de CPU. Daarom zal de latentie lager zijn.

Laten we zeggen dat een RT-pit ons in staat stelt om een ​​half gepelde garnaal achter te laten als wat op dat moment dringend nodig is, is om zo snel mogelijk een olijf te kuilen, terwijl het bij een normale pit nodig zou zijn om de garnaal af te pellen.

Naast het dunner maken van plakjes, hebben RT-kernels een veel strikter prioriteitssysteem, waarbij prioriteitstaken elkaar genadeloos slaan (preempting) om controle over de CPU te krijgen, en andere programma's zo nodig vertragen voldoen aan uw eisen.

Wanneer is het belangrijk om een ​​RT-kernel te gebruiken?

In twee gevallen:

1) Wanneer we zeer lage latenties nodig hebben, dat wil zeggen, zeer snelle reacties van de machine. Het duidelijkste voorbeeld is de uitvoering van virtuele instrumenten, waarbij u het instrument onmiddellijk moet laten klinken wanneer u een toets op een MIDI-toetsenbord indrukt.

2) Wanneer we zeer strikte prioriteiten nodig hebben, dat wil zeggen dat onze taak met hoge prioriteit door niets ter wereld wordt onderbroken (tenzij in het catastrofale geval dat de CPU zo overbelast is dat deze meer dan 100% benut wordt). We nemen bijvoorbeeld een audiosessie op met Ardor en kijken hoe de faderindicatoren op en neer gaan. Het maakt niet uit of we een verversingsframe van de faders verliezen, zolang het geluidstransport van de microfoon naar de harde schijf niet wordt onderbroken. Een RT-kernel vertraagt ​​het vernieuwen van de fader zo lang als nodig is, zolang er geen enkele audio-sample verloren gaat.

Dat gezegd hebbende, hebben de nieuwere niet-RT-kernels over het algemeen hun planningssysteem en prioriteitsbeheer aanzienlijk verbeterd. Als je de CPU niet aan de limiet van zijn mogelijkheden hebt (zeg minder dan 50% gebruik) of als je het niet erg vindt dat er van tijd tot tijd een kleine micro-cut (klik) in het geluid zit (de veel gevreesde xruns), een kernel normaal geeft perfect acceptabele prestaties.

Welke latentie is aan te raden?

Persoonlijk is alles onder de 10 ms prima voor mij en vanaf 20 ms begin ik de vertraging al duidelijk op te merken. Er zijn meer veeleisende mensen.

Installatie

Over Ubuntu en afgeleiden:

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

Bij het opstarten heb je beide opties (de normale kernel en de lage latentie).

In Arch en afgeleiden:

yaourt -S linux-rt
sudo update-grub

bron: Spaanspas