Océ doe-het-zelft met Linux

Reading time: 9 minutes

Author:

De fonkelnieuwe breedformaatkleurenprinter van Océ heeft een pinguïn onder de motorkap. Het apparaat is het eerste Venlose product dat general-purpose en hard realtime embedded applicaties naast elkaar op één pc draait. Een eigen versie van Linux leidt de volledige besturing in goede banen. ’Het gebruik van Linux maakt een hogere graad van integratie mogelijk‘, legt software-engineer Alex van der Wal uit. ’Normale en realtime toepassingen hoeven we niet langer geforceerd te scheiden. We hebben nu een platform waarop ze bij elkaar kunnen staan.‘

De huidige grote Océ-apparaten hebben eigenlijk allemaal nog twee besturingscomputers (zie kader ’Oud en nieuw‘). Een pc met een general-purpose OS draait de ’normale‘ applicaties, zoals de gebruikersinterface en de software om de afdrukopdrachten af te handelen. De tijdkritische taken, bijvoorbeeld voor de aandrijving van de printerengines, zijn in handen van een tweede computer. Die kan bestaan uit een of meer embedded processorborden of ook weer een hele pc. Het softwarebrein daar is het VXWorks-RTos van Wind River of Océs eigen Esra-framework (Embedded Software Reference Architecture).

Voor het breedformaatproject ging deze opbouw op de schop. ’Het moest goedkoper‘, aldus Van der Wal. ’We mochten niet langer twee pc‘s gebruiken. Aan de ene kant was dat een probleem, aangezien dit een van de eerste projecten was waarbij de embedded software niet alleen de apparaatbesturing moest doen, maar ook behoorlijk wat beeldbewerking. Dat vraagt om een Pentium-achtige. Simpele bordjes trekken dat niet, zelfs niet een Arm van een paar honderd megahertz. En de bordjes die het wel kunnen, zijn veel te duur. Aan de andere kant zouden twee pc‘s ook helemaal niet passen en bovendien te veel energie verbruiken.‘

Eigen pakket

Een paar jaar terug besloten Van der Wal en de zijnen de twee computers te laten versmelten. ’Daar zaten we al langer op te broeden. Zelfs als we de VXWorks-computer vol belasten, gebruikt hij maar 10 procent van de resources. Het grootste gedeelte van de capaciteit ligt daar gewoon ongebruikt. Het plan om de machine samen te voegen met de general-purpose pc was dan ook zo gek nog niet. In de praktijk bleek dat echter gemakkelijker gezegd dan gedaan.‘

Grootste uitdaging was het softwareplatform, dat nu zowel de tijdkritische als de niet-tijdkritische taken moest uitvoeren. ’Als eerste hebben we gekeken naar een RTos dat ook normale toepassingen aankon. Ons oog is toen gevallen op LynxOS van Lynuxworks, een realtime besturingssysteem waarop je via een Api Linux-programma‘s kunt draaien. Hier zijn we mee gestopt. Onze applicatieontwikkelaars wilden liever een echt general-purpose OS vanwege de beschikbare tooling en de ondersteuning van externe software. Bovendien waren er problemen met het pagingbestand om meer geheugen te kunnen adresseren dan er Ram beschikbaar is. Dat is later wel goed gekomen, maar toen waren wij ook al weer een stuk verder.‘

Met de injectie van vers bloed in het project kwam ook het idee om het eens te proberen met Linux. ’Natuurlijk zijn er meer oplossingen. We hadden ook een product kunnen kiezen waarmee we Windows hadden kunnen draaien onder VXWorks, maar het ecosysteem daarvoor was gewoon veel kleiner. We wilden iets dat redelijk mainstream is en waar voldoende support voor is. En dan zit je met Linux goed.‘

Halverwege 2005 stapten de Océ‘ers in realtime Linux. Als eerste bewandelden ze het commerciële pad, met versie 4.0 van het Montavista-platform. ’Dat werkte heel aardig, maar het miste net een beetje functionaliteit waardoor het niet al onze realtime-eisen kon garanderen. Zo ondersteunde het bijvoorbeeld geen priority inheritance mutexen, wat toch wel een voorwaarde is voor een RTos.‘ Heel snel zagen de Venlonaren daar ook geen verandering in komen. ’Die commerciële jongens releasen te weinig. Als ze één keer per jaar een oplevering doen, dan is het veel.‘

Daarom startte het ontwikkelteam een parallel traject om de publiek beschikbare Linux-kernel te gebruiken. ’We zagen dat de community hard bezig was om de kernel realtime te maken. Zo‘n type als Ingo Molnar, die eet en drinkt Linux. Die is bijna vierentwintig uur per dag achter dat toetsenbord te vinden. In de herfst van 2006 zijn we ermee aan de slag gegaan. Op basis van de Fedora 6-distributie hebben we toen ons eigen pakket samengesteld rond kernelversie 2.6.16 met de realtime PreEmpt_RT-patch. In een week of twee hadden we het draaien. Af en toe ging het nog wel de mist in, maar we hadden in ieder geval een proof-of-concept waaraan we konden zien dat we op de goede weg waren. We zijn de gemeenschap blijven volgen, blijven aanhaken bij de laatste kernelversies en blijven verbeteren, net zo lang tot de software goed genoeg was.‘

Geen file-I/O

Het belangrijkste probleem waarop de Océ-ontwikkelaars stuitten, was het optreden van page faults. Van der Wal: ’Veel besturingssystemen, waaronder Linux, maken gebruik van een virtuele adresruimte die groter is dan het fysieke Ram. Wanneer een programma dan een stuk virtueel geheugen benadert dat niet is gekoppeld aan een fysieke locatie, geeft dat een page fault. Vervolgens gaat het OS proberen een koppeling te leggen. Is het hele fysieke Ram vol, dan moet er geheugen worden vrijgemaakt door wat te kopiëren naar het pagingbestand op de harde schijf. In het ergste geval verwijst het virtuele adres ook nog eens naar een locatie die al is overgebracht naar de disk en moet de processor die eerst terughalen naar het fysieke geheugen. Deze hele tijd staat het programmaproces met al zijn threads stil. Het oponthoud kan honderden milliseconden duren. Voor een tijdkritische toepassing als de onze is dat onacceptabel.‘

Om dit soort geheugenfouten te voorkomen, zetten de Venlonaren een bovengrens op de hoeveelheid geheugen die hun realtime applicatie mag gebruiken. ’Zo veel heeft de toepassing maximaal tot zijn beschikking en nooit meer. Dat kunnen we van tevoren forceren in Ram. Daar zijn Api‘s voor. Aan de kernel vertellen we dat deze een eenmaal gemaakte koppeling mag pas weggooien als het bijbehorende proces ophoudt te bestaan. Alle dynamische allocaties doen we binnen dat vastgezette stuk. Dit betekent wel dat we niet meer virtueel geheugen kunnen hebben dan er fysiek Ram aanwezig is. Heeft een applicatie meer nodig, dan vallen er geen garanties meer te geven voor de prestaties. Zo gebruiken we verschillende printertalen die allemaal een ander stukje werkgeheugen gebruiken. Het totaal is meer dan er aan Ram beschikbaar is, zodat we bij het wisselen van taal wel aan paging moeten doen om te voorkomen dat we meer geheugen moeten toevoegen en daarmee de kostprijs opdrijven. Wat onze oplossing echter speciaal maakt, is dat we zowel de general-purpose als de realtime applicaties pagen.‘

Niet al het oponthoud is te voorzien. ’Veel bestaande bibliotheken zijn niet ontworpen met realtime in het achterhoofd. Neem zoiets simpels als een standaard printf-statement om één regeltje op de console weer te geven. Normaalgesproken kost dat een paar microseconden, maar onze applicatie is erop stukgelopen doordat de aanroep soms honderden milliseconden bleek te duren. Geen idee waarom. Misschien dat de library een buffer aan het legen was. Zo kan iets veilig lijken, maar toch geniepige problemen veroorzaken. Zeker als je de implementatie niet kent. Eigenlijk zou je voor elke call in de source moeten kijken, maar dat kost te veel tijd.‘

Het advies van Van der Wal is hier: als het riekt naar I/O, pas dan op. ’Je kunt geen file-I/O doen, want alleen het openen van een bestand kan al een page fault geven. File-I/O gebruiken we daarom niet rechtstreeks. In plaats daarvan hebben we er een tweede, niet-tijdkritische binary naast gehangen die dat allemaal verzorgt. Deze zogenoemde communicatieserver hebben we met de realtime applicatie verbonden via sockets, die geen page faults veroorzaken. Wanneer we nu een bestand willen openen of iets op het scherm willen zetten, gaat er een commando naar de communicatieserver, die dat dan afhandelt. Omdat die toepassing niet tijdkritisch is, hebben de realtime taken er geen last van als daar een geheugenfout optreedt.‘

Een ander probleem is de klok die Linux gebruikt. ’De laatste versie van de kernel rekent weliswaar met de hardwareklok en is daarmee zo accuraat als die hardware toelaat, maar doordat de software de tijd standaard synchroniseert via het Network Time Protocol, is het tijdsverloop op microsecondeniveau erg grillig. Ook het verzetten van de klok kan niet zonder meer. Een plotselinge tijdsprong van bijvoorbeeld een uur verstoort alle timers in onze realtime applicatie. Daarom hebben we die functionaliteit moeten uitzetten. Nadeel daarvan is dat we de gebruiker nu niet kunnen laten zien hoe laat het precies is. Een tweede klok ernaast zetten, is in de huidige Linux-versie nog niet mogelijk. De Posix-Api‘s daarvoor zijn er wel, maar werken nog niet naar behoren.‘

Actief in de gemeenschap

Uiteindelijk hebben de Venlonaren zo alle obstakels uit de weg geruimd. ’Ik kan gewoon eerlijk zeggen dat we geen problemen meer hebben. Realtime Linux werkt als een zonnetje. Onze gemiddelde interruptvertraging is 5 microseconden. Alleen bij het opstarten wil die nog wel eens boven de paar honderd microseconden uitkomen, maar dat komt door onze applicatie en daar kunnen we mee omgaan. Bovendien gebruiken we nog niet de nieuwste kernel. We draaien nu 2.6.20-RT8, de eerste versie waarin alle realtimegerelateerde plooien zijn gladgestreken. Binnenkort trekken we bij naar 2.6.24, waarin de functionaliteit van de realtime patch volledig is geïntegreerd. Daar verwacht ik veel van.‘

Vanwege de uitschieters in latency zou Van der Wal realtime Linux niet direct in een vliegtuig stoppen, maar voor de producten van Océ is het een prima oplossing. ’We hebben nu een platform waar we zeker op verder gaan bouwen. Dat betekent echter niet dat VXWorks langzaam uit onze apparaten gaat verdwijnen. Realtime Linux is geen silver bullet en maakt andere RTos‘en ook zeker niet overbodig. Het voegt wat toe aan het landschap. Voor elk project kiezen we de juiste match.‘

Tot slot heeft Van der Wal nog wat adviezen voor wie ook wil overstappen op realtime Linux. ’Zorg ervoor dat je Linux-kennis in huis hebt, en als het even kan zelfs kernelkennis. Profiteer van de ervaringen van de PreEmpt_RT-community, maar geef ook iets terug door actief te participeren in de gemeenschap. Voor X86 is de realtime kernel zo volwassen dat je best een bestaande distributie als basis kunt nemen. Denk bijvoorbeeld aan de commerciële oplossingen van Montavista, Red Hat, Suse en Wind River of aan de gratis pakketten Fedora en Ubuntu. Identificeer ook de juridische aspecten in een vroeg stadium. Het is niet moeilijk om de bedrijfseigen code buiten de GPL te houden, maar let er wel even op. Zorg ervoor dat de voorzieningen die op applicatieniveau nodig zijn om het realtime gedrag te garanderen vroeg beschikbaar zijn en instrumenteer de code zodat deze zelf zo veel mogelijk van het tijdkritische gedrag controleert.‘