Latenza e Sistemi Operativi: Linux Real-Time

Come già più volte ricordato nel corso del presente lavoro è stata fatta la scelta di utilizzare esclusivamente software libero, e concordemente in questo paragrafo si considereranno tra i sistemi operativi real-time solo quelli appartenenti alla famiglia ‘Linux’. Sul mercato esistono in realtà molte alternative possibili, ma nessuna presenta i rilevanti vantaggi di economicità, disponibilità e modificabilità dei sorgenti, e quindi personalizzabilità offerte dalle soluzioni aperte. Tali vantaggi sono stati ritenuti tanto significativi per lo sviluppo del nuovo protocollo Standard che altre possibilità non sono semplicemente state considerate. Ci concentreremo quindi nel seguito sul mondo dei sistemi operativi Real-Time Linux based.

Brevemente ricordiamo una definizione di sistema Real-Time tra le tante disponibili.

Un sistema real-time è un sistema nel quale la correttezza delle elaborazioni non dipende solo dalla loro esattezza logica ma anche dall’istante in cui i risultati vengono prodotti. Se in vincoli temporali associati al sistema non vengono rispettati, allora il sistema è comunque in uno stato di errore.

In altre parole il sistema deve essere deterministico e garantire un certo comportamento rispetto ai tempi di output anche al variare del carico. E’ importante notare che la definizione

appena introdotta non parla di prestazioni velocistiche, ed infatti il real-time non è una questione di velocità: è una questione di predicibilità.

Ad esempio usando un processore aggiornato è facile ottenere tempi di risposta di pochi microsecondi, ma occasionalmente in un sistema per utilizzo generale si hanno tempi di risposta enormemente più lunghi, anche dell’ordine di un secondo. E proprio qui è il problema fondamentale: il sistema non è che non sia sufficientemente veloce o efficiente, però il suo comportamento non è deterministico, ovvero non predicibile.

Nel caso del presente lavoro è utile ottenere la massima predicibilità possibile per task che svolgono funzioni real-time sulla macchina, ad esempio gestione di dati per il controllo distribuito, e preparazione, invio e ricezione di messaggi che consentano di realizzare efficacemente tale controllo. Per ottenere questo risultato e contemporaneamente consentire l’esecuzione di ulteriori task dedicati ad altre applicazioni o alla gestione del sistema è chiaramente indispensabile un sistema di priorità assegnabili articolato, oltre ad una lunga serie di altri accorgimenti a cui verrà nel seguito fatto cenno. Nella Figura 6.5 a titolo di esempio sono mostrati i livelli di priorità associati ad un kernel real-time in rapporto ai livelli tipici di un kernel mainstream.

Dalla figura è immediatamente evidente che i livelli del kernel real-time sono un superset di quelli ‘normali’. Ciò è molto utile in quanto si può fare in modo che all’interno del sistema una applicazione real-time giri con priorità maggiore delle applicazioni normali, senza che ci sia bisogno di alcuna modifica ne ricompilazione di queste ultime.

Applicando un concetto simile anche alla gestione del traffico possiamo ottenere sistemi che conciliano un buon comportamento per quanto riguarda il controllo real-time anche distribuito con la possibilità di svolgere i ‘normali’ compiti associati a sistemi di elaborazione delle informazioni.

In realtà la possibilità di utilizzare Linux come sistema operativo per applicazioni embedded con tutti i requisiti tipicamente ad esse collegati, è da tempo perseguita dall’industria e dagli ambienti di ricerca.

Alcune delle ragioni di tale interesse sono quelle più volte citate, come ad esempio la mancanza di royalties da pagare e la disponibilità di librerie, tool di sviluppo e applicazioni per una amplissima casistica di situazioni. Però esistono anche motivi di natura strettamente tecnica, ad esempio l’abilità di gestire task real-time e ‘best effort’, ovvero di tipo tradizionale, sulla stessa macchina, come evidenziato in dettaglio qualche riga più sopra.

Figura 6.5: Livelli di priorità del kernel real-time

Come risultato molti vendor e anche università [60] stanno supportando attivamente Linux nel suo percorso di ‘avvicinamento’ al real-time, oppure sviluppando distribuzioni o interi ambienti real-time commerciali [58], [59], [61] partendo da una base Open Source.

Il metodo più diffuso sinora di aggiungere capacità real-time a Linux si potrebbe definire l’approccio ‘doppio kernel’, nel quale le applicazioni real-time sono gestite da un kernel dedicato che vede un altro kernel standard come uno dei suoi task. In pratica i due kernel sono come innestati uno nell’altro.

Più di recente ha iniziato ad emergere un approccio alternativo, ovvero di migliorare direttamente le capacità in termini di real-time del kernel standard di Linux, grazie agli sforzi del progetto ‘RT Patch’ [62], [63]. Al momento quest’ultimo approccio è caratterizzato da prestazioni inferiori, che potrebbero non essere sufficienti per alcune classi di applicazioni di nicchia con stringenti specifiche. Però ha vantaggio di avere una struttura concettuale e implementativa più lineare e quindi semplice da implementare e mantenere, ed inoltre è già

ora di interesse per applicazioni con specifiche meno stringenti quali quella oggetto del presente documento, che non richiede un real-time ‘hard’, ma piuttosto di tipo ‘soft’.

I vantaggi citati potrebbero diventare molto rilevanti con il procedere dello sviluppo, ed in particolare visto che una parte della RT Patch è in corso di integrazione con il kernel standard, e quindi almeno una parte delle sue funzionalità saranno disponibili in tute le distribuzioni. Inoltre ciò probabilmente imprimerà una accelerazione nello velocità e qualità dello sviluppo, a tutto vantaggio delle prestazioni ottenibili in futuro. Oltre a ciò la ‘RT Patch’ già ora offre il grande vantaggio di essere stata integrata in una importante distribuzione commerciale [61], e nei suoi derivati free, aprendo la possibilità di sfruttare contemporaneamente sia buone prestazioni in termini di real-time che nell’immediato uno sterminato parco software applicativo e di sviluppo, sia libero che commerciale.

In effetti nel corso del presente lavoro proprio quest’ultima possibilità è stata scelta è utilizzata estensivamente, e viene quindi brevemente introdotta nel seguente paragrafo.