Een stopwatch is gebouwd met één obsessie: meten zonder dat de meting zelf ontspoort. Je drukt op start, en vanaf dat moment wil je geen bijgeluiden, geen extra weerstand, geen “hapering” die nét op het verkeerde moment door je mechaniek loopt. In de wereld van real-time software blijkt precies hetzelfde te gebeuren, alleen niet met tandwielen en hefbomen, maar met interrupts en high-resolution timers.
Het artikel TimerShield: Protecting High-Priority Tasks from Low-Priority Timer Interference beschrijft een probleem dat veel mensen pas zien als het misgaat: een hoog-prioriteit real-time taak kan merkbaar worden vertraagd door timer-interrupts die eigenlijk bedoeld zijn voor laag-prioriteit werk. Die vertraging heet in het paper heel treffend “timer interference”.
Het ‘vals alarm’-probleem in Linux-tijd
Linux heeft high-resolution timers (hrtimers) waarmee processen heel precies kunnen slapen of periodiek kunnen wakker worden, bijvoorbeeld met clock_nanosleep(). Dat is krachtig, maar er zit een valkuil in: timers leiden tot interrupts, en interrupts komen binnen alsof ze belangrijk zijn, ongeacht wie de timer heeft gezet. Het systeem handelt ze af, ook als de timer afkomstig is van een proces dat in de normale scheduling-logica laag-prioriteit heeft.
De crux die het artikel blootlegt is pijnlijk simpel: het standaard timermechanisme houdt timers bij op basis van “wie verloopt het eerst?”, niet op basis van “wie is belangrijk?”. In Linux worden hrtimers in een red-black tree bijgehouden in volgorde van expiratie, zodat de eerstvolgende timer snel te vinden is. Maar die structuur kent geen prioriteitsbegrip.
En dan krijg je een situatie die je ook uit de horlogerie herkent: één onderdeel dat “even iets doet” op een onhandig moment, kan de hele nauwkeurigheid van het systeem vervuilen. In software zie je dat als jitter, slechtere response times, en soms zelfs lagere throughput van je hoog-prioriteit taak.
TimerShield doet iets dat eigenlijk verrassend logisch voelt: het maakt timers prioriteitsbewust. Bij TimerShield krijgt elke timer een prioriteit mee (de scheduling-prioriteit van het proces dat de timer aanmaakt of herprogrammeert). Vervolgens geldt: zodra een proces op een bepaalde prioriteit draait, worden timers van lagere prioriteiten automatisch “masked” bij het bepalen welke timer de hardware moet programmeren. Met andere woorden: die lagere timers mogen best bestaan, maar ze mogen niet meer dwars door een hoog-prioriteit taak heen breken.
Het stopwatch-gevoel: interfereer niet met de meting
De evaluatie in het paper draait om twee dingen: wat kost het, en wat levert het op. TimerShield voegt wat overhead toe aan timer-operaties en aan context switches (logisch, want daar gebeurt het “masken” en opnieuw programmeren), maar het punt is dat die kosten klein blijven vergeleken met de winst wanneer je veel laag-prioriteit timers hebt.
De hele evolutie van stopwatch- en chronograafmechaniek is één lange les in “doe je functie, maar verstoor het lopende werk niet”. Starten en stoppen is een ingreep. Reset is een ingreep. En elke ingreep kan energie wegnemen, frictie toevoegen of een tik geven die je meting beïnvloedt. Daarom zie je in goede ontwerpen steeds hetzelfde streven terug: functies moeten betrouwbaar zijn, maar het lopende werk moet zo min mogelijk last hebben van de bediening.
TimerShield is in feite hetzelfde principe, maar dan in een kernel. Timers zijn nodig—zoals je in een stopwatch een start/stop/reset nodig hebt—maar als die timers van “onbelangrijk” werk de boel mogen onderbreken, meet je niet meer wat je denkt te meten. TimerShield zet er een schild tussen: eerst de kritieke meting, daarna de rest.
Wat ik sterk vind aan dit artikel is dat het laat zien hoe fragiel precisie is. Niet alleen in messing en staal, maar ook in software. Je kunt de beste real-time taak schrijven, met perfecte periods en netjes clock_nanosleep(), en tóch krijg je rommel in je timing omdat “iets kleins” zijn eigen belletje blijft rinkelen.
Precies dat is ook waarom een goede mechanische stopwatch zo’n aantrekkelijk object is: het is een geconcentreerde oplossing voor een universeel probleem. Hoe zorg je dat een meting zuiver blijft, terwijl er ondertussen van alles gebeurt.
Reactie plaatsen
Reacties