door Ismael Ripoll Over de auteur: Behaalde een graad aan de Polytechnische Universiteit van Valencia in 1996. Professor in operating systemen op het departement van DISCA. Onderzoeksgebieden omvatten onder andere real-time scheduling en operating systemen. Linux gebruiker vanaf 1994. Hobbies: met de rugzak door de Pyreneën, skiën en hobby electronica. Inhoud: Wat is Real-Time? Wat is de relatie tussen Operating System en Real-Time? POSIX RT Uitbreidingen Real-Time Linux Installatie van RT-Linux De toekomst van RT-Linux Afronding

Real-Time Linux (RT-Linux)

Kort:

Basis concepten van Real-Time (RT). Harde real-time met RT-Linux.

Wat is Real-Time?

"Een Real-Time systeem is een informatiesysteem waarbij het correct functioneren niet alleen afhangt van de uitvoer van een algoritme maar ook van het tijdstip waarop deze uitvoer wordt gegenereerd"

Het is dus niet voldoende dat de uitvoer correct is, deze uitvoer moet ook worden gegenereerd binnen een specifiek tijdsinterval. Merk op dat uit deze definitie niet automatisch volgt dat het systeem ook snel is, een snel gemaakte fout. Voorbeeld: het geleidesysteem van een schip lijkt geen real-time systeem te zijn door de lage snelheden, waardoor men gewoonlijk "genoeg" tijd heeft (in de minuten) om een besturingsbeslissing te nemen. Per definitie is dit echter een RT-systeem.

Merk op dat we een "Real-Time Systeem" hebben gedefinieerd en geen "Systeem in Real Time". Dergelijke systemen zijn doorgaans snel en in staat om een indruk van "echtheid" te geven. Meest simulaties en interactieve spellen geven de gebruiker het gevoel van voortschrijdende tijd. De snelheid om plaatjes te genereren kan dit het beste bewerkstelligen.

Laten we eerst eens ingaan op het begrip temporele restrictie. Stel, we willen de snelheid van een motor besturen die variabel wordt belast en we willen dit doen met een PIA aansturing (Proportioneel Integrale Afgeleide). De PIA, in onze visie, is een functie met een aantal parameters --in dit voorbeeld de snelheid van de motor-- die de waarde van het stuursignaal teruggeeft wat op de motor moet worden toegepast --de hoeveelheid stroom die de motor moet krijgen. De theorie achter het ontwerp van PIA algoritmen, die trouwens behoorlijk veelomvattend is, gaat uit van de aanname dat de tijd om de berekening uit te voeren verwaarloosbaar is. Onder normale omstandigheden kan een systeem wel een kleine vertraging hebben. Een ander kenmerk van dit type aansturing is dat het periodiek moet worden uitgevoerd oftewel, het PIA algoritme moet regelmatig uit worden gevoerd. Wanneer de tijd tussen twee aanroepen van het PIA algoritme te lang wordt kan de motor een ongewenste snelheid krijgen. Samenvattend: de PIA functie kan worden gezien als een periodiek te executeren programma (Pi); tussen begin en einde van het algoritme kan slechts een interval zitten die niet groter is als het maximum, zoals aangegeven in het ontwerp van de PIA (Di). Het executeren van de PIA-code neemt verder een bepaalde tijd, afhankelijk van de snelheid van de processor (Ci).

Pi: Interval van taak i.

Di: Deadline van taak i.

Ci: worst case rekentijd voor taak i.

Als het systeem slechts die ene taak heeft dan is dit geen probleem voor real-time: de processor kan het in de gestelde tijd berekenen of niet. Voor het geval dat de processor niet snel genoeg is moet deze gewoon worden ingeruild voor een snellere.

Het RT probleem gaat spelen als het systeem meerdere taken uit moet voeren en er dus een manier moet worden gevonden om de processortijd (of processoren tijd) over de taken te verdelen. Het gebruik van een algemeen systeem op basis van de tijd, zoals Linux, is dan uitgesloten. Het is uiteraard overbodig om voor te stellen dit te proberen onder Windows. Sterker nog, het advies kan beter zijn dat je helemáál geen programma's op dat platform moet maken.

Niet alle RT systemen zijn gelijk. Het verschilt nogal om een ABS systeem van een auto te besturen of een brandstofinjectie systeem van een vliegtuig of het uitpakken en projecteren van een mpeg bestand. In het eerste geval kan een kleine vertraging in de uitvoering van het programma het verlies van mensenlevens of grote materiële schade betekenen; in het laatste geval is er slechts sprake van kwaliteitsverlies (het plaatje bevriest of een aantal plaatjes raakt verloren). Het eerste type systeem staat ook wel bekend als Harde Real-Time Systemen, de tweede als Zachte Real-Time Systemen. In dit artikel gaat het over harde RT systemen.

Het ontwerp van een RT systeem doorloopt meerdere fasen: allereerst wordt vastgesteld welke taken er uit moeten worden gevoerd en wat hiervan de temporele restricties zijn. Ten tweede wordt de code geschreven en tenslotte wordt de looptijd voor iedere taak gemeten en er wordt een verdeeltest gedaan om er zeker van te zijn dat de taak niet ná de deadline afloopt in een actief systeem. Deze test bestaat uit het doen van een aantal tests op alle taken. Pas als dit goed gaat kan men garanderen dat geen enkele taak de deadline zal missen. Wanneer de testen falen wordt het een kwestie van geheel opnieuw ontwerpen, een snellere processor nemen of andere algoritmen bedenken voor de taken.

Samenvattend: De taken kan men definiëren middels drie tijdwaardes: Pi, Di en Ci. Doel van het systeem is te garanderen dat alle taken (binnen alle executiepaden)de deadline halen. Om dit te kunnen garanderen moet het systeem voorspelbaar zijn. Verklaren dat een systeem real-time is of dat een systeem voorspelbaar is, is bijna hetzelfde.  

Wat is de relatie tussen Operating System en Real-Time?

Het OS moet de uitvoer van de taken indelen en daarbij tevens de onderbrekingen (interrupts) afhandelen. Het OS moet het volgende bieden:

• Het algoritme voor het indelen van de taken.
• Het mechanisme voor inter-proces communicatie (semaforen, berichten etc.).
• Afhandelen van interrupts.
• Taken activeren in hun respectieve tijdssloten.

Een OS dat 10 tijdseenheden doet over een context omschakeling met uitschieters naar 12 tijdseenheden, is verre te prefereren boven een OS dat er 3 tijdseenheden over doet met af en toe uitschieters naar 20 tijdseenheden.

Het mag dan ook niet verbazen als je erachter komt dat RT Operating Systemen trager kunnen zijn dan een normaal OS. In bepaalde gevallen is het zelfs nodig om een cache uit te schakelen om zodoende een meer voorspelbaar gedrag te krijgen. Dit gaat natuurlijk ten koste van de snelheid. Cachegeheugen en processoren met pipeline- en sprong-voorspellende mechanismen staan duidelijk op gespannen voet met de voorspelbaarheid en daarmee dus ook met RT Operating Systemen.

POSIX RT Uitbreidingen

Het werk (definiëren van Posix) wordt verdeeld over diverse werkgroepen die zijn samengesteld uit vertegenwoordigers van fabrikanten, software bedrijven, overheid en uit computer goeroes. Iedere groep gaat hierbij over een bepaald aspect van het OS. Zo gaat de groep Posix.4 bijvoorbeeld over het real-time gedeelte.

De Posix.4 uitbreiding --omgedoopt tot 1003.1b sinds 1993-- geeft een OS de mogelijkheid om een RT omgeving te ondersteunen. Het gaat hierbij uiteraard vooral om uitbreidingen met betrekking tot time management en prioriteitsstelling van processen. Verder zijn er systeemaanroepen voor de ondersteuning van inter-proces communicatie.

De Posix uitbreidingen zijn ontworpen voor meer controle over de resources (hulpmiddelen of mechanismen) van een OS.

Linux 2.0 heeft een groot aantal Posix uitbreidingen voor real-time geïmplementeerd. maar dit aspect van Linux zullen we in een later artikel bespreken. Versie 2.2 zal hoogstwaarschijnlijk 100% ondersteuning bieden voor Posix 1003.1b.  

Real-Time Linux

De oplossing binnen RT-Linux verschilt radicaal van de andere oplossingen. In plaats van het aanpassen van de Linux kernel om hem voorspelbaar te krijgen, wordt er een mini- kernel direct op de processor (i386) gebouwd --onafhankelijk van de Linux kernel-- met een scheduler (= verdeler van processortijd over de taken). De Linux-kernel draait hier weer bovenop, waarmee de processor wordt gedeeld met andere RT taken. Om precies te zijn is Linux nu een achtergrondtaak die de processor krijgt toegewezen als er geen andere RT taken lopen.

Ik kan me voorstellen dat er nu een aantal lezers in verwarring zijn gebracht. Waarschijnlijk dachten die dat het OS altijd de baas was en er niet mee geknoeid kon worden.

Het is misschien nog verrassender om te weten dat deze scheduler dynamisch kan worden geïnstalleerd en weer weggehaald omdat hij gecompileerd is als een module.

De code van de Linux kernel (net als ieder ander OS) zal normaal gesproken interrupts uitschakelen voor bijvoorbeeld synchronisatiedoeleinden of voor het uitvoeren van kritieke code. Als in dit soort gevallen een interrupt van de klok binnenkomt dan wordt deze geblokkeerd en is er dus een verlies aan temporele precisie. RT-Linux heeft hiervoor een elegante oplossing: alle aanroepen naar cli, sti en iret (assembler aanroepen die de werking van interrupts beïnvloeden) worden vervangen door aanroepen naar S_CLI, S_STI en S_IRET die ze emuleren. Hierdoor kan Linux ze niet meer blokkeren.

De standaard scheduler van RT-Linux werkt preemptive (= het kan lopende taken onderbreken en processoren vervolgens toewijzen aan andere taken) en met vaste prioriteitsstelling. Het beschouwd Linux als een taak met de laagste prioriteit. Wanneer dus RT- taken alle processortijd opeten dan zal de Linux taak geen tijd toegewezen krijgen en krijg je de indruk dat Linux gestopt is.

Met RT-Linux hebben we dus niet alleen een real-time systeem maar ook een klassiek OS. We kunnen over het web surfen terwijl ondertussen andere apparaten aan worden gestuurd.  

Installatie van RT-Linux

Om een Linux systeem naar RT-Linux te "transformeren" moeten we een kleine reparatie op de broncode van de kernel uitvoeren en deze opnieuw compileren. Hier is het recept. Ik neem even aan dat de file rtlinux-0.6-2.0.33.tgz in de directory /usr/src staat en uitgepakt in de directory /usr/src/rtlinux-0.6. Tevens neem ik aan dat de juiste kernelopties al zijn geconfigureerd (make config). Vervolgens:

# cd /usr/src/linux
# patch       -p1 <../rtlinux-0.6-2.0.33/kernel_path
# make dep; make clean; make zlilo; make modules; make modules_install
# reboot

Naast de voorbeelden uit de distributie (in de directory testing) kun je nog een voorbeeld ophalen, voorgekookt door Oleg Subbotin, wat een executie-chronogram van de taken op het scherm tovert. Eén bestand uit deze demo is een gemodificeerde scheduler die, buiten zijn normale taak, ook nog eens informatie genereert over de beslissingen die hij neemt. Deze informatie wordt opgeslagen in een bestand, wat later grafisch kan worden weergegeven. Het resultaat hiervan is dat we kunnen zien in welke volgorde de taken worden uitgevoerd en hoe hogere prioriteit taken de lagere prioriteitstaken onderbreken en voorrang krijgen. De Linux taak staat er niet bij.

Iedere taak wordt gepresenteerd middels een horizontale as. De rechthoeken geven de tijden aan waarop een taak de processor heeft gebruikt (op ieder moment kan er slechts één taak actief zijn omdat het systeem slechts één processor heeft). In dit voorbeeld is de deadline voor iedere taak gelijk aan z'n periode. De periode van iedere taak wordt aangegeven door een tijdsinterval (weergegeven met: ) gedurende welke de taak moet worden geëxecuteerd. De taken in het bovenste gedeelte hebben hogere prioriteit en kunnen daarmee andere taken onderbreken en de processor afnemen zoals bijvoorbeeld gebeurt op moment 600.  

De toekomst van RT-Linux

Een paar weken geleden is het maken van de handleiding gestart.  

Afronding

Het volgende artikel in deze reeks zal diverse voorbeelden van RT applicaties behandelen alsook hoe deze zelf te maken.

2000-01-10, generated by lfparser version 1.1