Comparazione tra RTOS Linux

Esistono diverse versioni di Linux nel panorama commerciale ed è difficile stabilire quale presenta le migliori caratteristiche tecniche. Quali sono gli indicatori che permettono di stabilire quando un sistema operativo è migliore rispetto ad un altro? In questo articolo vi presenteremo due studi condotti in ambito universitario.

Esistono diversi studi che si propongono di dare delle valutazioni prestazionali di sistemi operativi più diffusi nel panorama commerciale e, per i nostri scopi, vogliamo porre in risalto solo quelli in ambito Linux, o derivati, tralasciano quelli che non sono open-source, come per esempio VxWorks (VRTXsa è stato messo a confronto da uno studio condotto dalle prestazioni. Uno studio comparativo condotto da due studenti dell’università La Sapienza di Roma ha posto in evidenza le prestazioni di RTLinux, RTAI e VRTXsa. Lo studio ha misurato  i tempi di latenza su una chiamata che scrive un blocco dati dil’università La Sapienza di Roma). Efficienza e predicibilità sono alcuni dei parametri che sono utilizzati per stabilire le prestazioni di un sistema operativo, specie se real-time.  I due lavori universitari, con le test suite associate, tentano di dare delle informazioni oggettive per quantificarne 4 byte in una coda FIFO, oltre al tempo impiegato per scrivere e leggere un blocco dati di 4 byte da e verso una coda FIFO. Altri test hanno posto in evidenza i tempi di latenza su chiamate che scrivono blocchi di 16 byte in una mailbox e il trasferimento di messaggi da una mailbox ad un’altra. Lo studio di Roma ha infine, preso i tempi di latenza di un interrupt su PowerPc. Per fare queste valutazioni è stato messo a punto un banco di test e un software appositamente realizzato. Accanto a questo studio ne esiste un altro interessante denominato “Benchmark and comparison of real-time solutions based on embedded Linux’ presentata come tesi a Ulm. In quest’ultimo studio i sistemi  operativi posti a confronto sono stati RTAILinux, Xenomai e Real-time Preemption Patch tralasciando ogni riferimento a sistemi commerciale non presenti nella comunità open-source.

Ambiente di test

Lo strumento principale per condurre un test di tipo prestazionale è senza dubbio l’oscilloscopio; infatti, in questo modo otteniamo tempi precisi misurando  il tempo di latenza associato. Inoltre, l’equipe dell’Università La Sapienza ha approntato delle piccole modifiche hardware nella configurazione sotto test; si è utilizzato, infatti, un piccolo bridge tra il led LD13 e il pin C11 (system expansion connector).  Il pin C11 è il pin IRQ (interrupt request) ed è connesso con il segnale IRQ 6 (DP6/CSE0/IRQ6#). Il collegamento creato tra LD13 e il pin C11 è di fondamentale importanza; infatti, per mette di rispondere all’evento esterno e consente la gestione dell’interrupt.  Il programma di test utilizza il pin associato al led LD13 per generare  il livello di tensione di +5V/0V. In questo modo è sufficiente mettere a punto una routine apposita, interrupt service routine, per la gestione dell’interruzione #6. Applicando il probe dell’oscilloscopio sulla linea è possibile analizzare l’onda prodotta e, quindi, stimare con una buona precisione  il tempo che intercorre tra l’evento e la sua relativa gestione.  Il tempo include la latenza associata all’hardware e all’interruzione. La figura 1 mostra una possibile forma d’onda prodotta.

Figura 1: esempio di forma d’onda visibile sull’oscilloscopio.

Figura 1: esempio di forma d’onda visibile sull’oscilloscopio.

La configurazione hadware utilizzata dall’equipe dell’Università romana comprende un processore PowerPC 8275 su Motorola Freescale PQ2FADS-VR a 200 MHz con un bus 66 MHz. La board dispone di 32 Mb di ram e 8 Mb di flash. Viceversa, la tabella 1 mostra i vari ambienti  di test utilizzati, con le toolchain associate, delle prove condotte dal gruppo tedesco.

Tabella 1: ambienti di test del gruppo di ricerca tedesco

Tabella 1: ambienti di test del gruppo di ricerca tedesco

I test sono stati eseguiti su tre piattaforme hardware differenti: ARM, PowerPc e Intel x86. Per la piattaforma basata su Intel x86 sono state utilizzate due differenti sistemi. Il primo è in sostanza un desktop standard con un AMD K7 a 600 MHz con 120 Mb di ram e un hard disk IDE. È stata scelta questa tipologia perché la maggior parte degli utenti dispone di una configurazione simile. La seconda piattaforma è, praticamente, un sistema embedded con un processore Intel x86 della Kontron a 300 MHz con 120 Mb di ram. Su ARM si è preferito la board “LILLY-9xx” della Incostartec. Questa board utilizza un processore ARM920T a 32-bit con un clock a 200 MHz. Come tutti processori ARM, sono disponibili una serie di periferiche integrate come un network, un video e un IDE controller. Sulla board trova posto, poi, 32 Mb di ram e un gestore della paginazione della memoria, MMU. Come monitor e loader si utilizza redboot, che è preinstallato sul target. In realtà viste le difficoltà di utilizzare questa board, il gruppo tedesco ha anche valutato la possibilità di disporre di un’altra configurazione: “ARM & EVA” della Conitec Datensysteme. Questa board contiene un processore ARM AT91RM9200: in questo modo è possibile utilizzare le più recenti versioni del kernel di Linux. L’ultima configurazione hardware utilizzata è basata su PowerPC, MEG32, della Frenco con un PowerPc G2 con un clock a 300 MHz, 128 Mb di ram e una flash di 32 Mb. Il gruppo tedesco ha condotto una serie di attività preliminari per installare il kernel e le toolchain sull’ambiente host. Per esempio, in ambiente Intel x86, una volta scelto di utilizzare  il package Xenomai, release 2.3.1 con ker nel Linux 2.6.20, e scompattati i due file nella cartella /usr/src, rinomata la cartella in “linux-2.6.20-xenomai” e applicate le patch RTAI relative utilizzando, magari, questo script:

scripts/prepare-kernel.sh —arch=i386
—adeos=ksrc/arch/i386/patches/\
adeos-ipipe-2.6.20-i386-X.Y-ZZ.patch
—linux=/path/to/kernel/tree

Si è proceduto a compilare, linkare e installare i prodotti con una serie di script file e il comando:

”make DESTDIR=/rootfs/opt/xenomai install”

Benchmark

Per misurare le prestazioni di un sistema operativo real-time sono state definite una serie di prove:

» Interrupt latency. L’obiettivo di questo test è di misurare  il tempo speso dal nostro sistema per reagire ad un evento esterno. Per misurare questo tempo occorre disporre di un pin di I/O, comunque disponibile negli ambienti di test.

» Jitter. Questo è uno degli attributi maggiormente espressivi di un sistema di tipo real-time.  Il target genera un’onda quadra su uno dei suoi pin con l’obiettivo di misurare la durata di ogni mezzo ciclo (un ciclo intero è stato stabilito in 4 ms) e, poi, si calcola la massima differenza tra queste durate.

» Maximal frequency. L’idea alla base di questo test è di misurare la frequenza d’esecuzione di un task. La misura è rilevata intervenendo, come in tutte le procedure, sui pin di I/O presenti nella configurazione hardware.

» Inter-process Comunication (IPC). Lo scopo di questo test, condotto dal gruppo tedesco, è misurare la quantità di informazioni che sono trasferite attraverso I/O speciali quali file e pipe. Inoltre, il gruppo italiano ha anche messo a punto un gruppo di prove per valutarne le prestazioni IPC, per esempio, utilizzando mailbox in kernel space.

» Overload. Il test è condotto utilizzando due processi con la stessa priorità. Con questo test si vuole controllare il comportamento, in tempo reale, del sistema in presenza di sovraccarichi temporanei.

» Priority. Il test vuole dimostrare l’uso corretto delle priorità. Il test è condotto ponendo in esecuzione un’applicazione con differenti priorità, periodicità e tempi di lavorazione differenti. Il  controllo è svolto da un thread che acquisisce  il sistema, con prelazione, da un altro con priorità più bassa.

Risultati

L’esecuzione dei test ha permesso di ricavare i seguenti  risultati:

» Interrupt latency. Il gruppo tedesco ha ritenuto che il tempo rilevato non era così apprezzabile per giustificare la scrittura di una sequenza di inizializzazione in ambiente PowerPc, per questa ragione si è preferito lavorare su Intel x86. Le figure 2, 3 e 4 mostrano le latenze associate per le estensioni di real-time di Linux.

Figura 2: interrupt latency su Intel x86 con Linux 2.6 e Xenomai.

Figura 2: interrupt latency su Intel x86 con Linux 2.6 e Xenomai.

Figura 3: interrupt latency su Intel x86 con Linux 2.6 e RTAI.

Figura 3: interrupt latency su Intel x86
con Linux 2.6 e RTAI.

Figura 4: interrupt latency su Intel x86 con Linux 2.4 e RTAI.

Figura 4: interrupt latency su Intel x86
con Linux 2.4 e RTAI.

La linea blu mostra, su tutte le tre figure, il  test-run senza alcun carico di lavoro, mentre la linea rossa pone in evidenza le latenze sotto carico. Come chiaramente  il grafico pone in evidenza, i diversi  tre approcci real-time presentati reagiscono dopo circa, nel caso peggiore, 19µs. In caso di sistemi senza carichi di lavoro le interruzioni sono gestiti entro 13µs. La latenza media di tutte le tre piattaforme è pari ad un valore che oscilla tra 8 e 9  s, anche in presenza di carichi di lavoro. Viceversa, il gruppo di lavoro italiano ha, invece, ricavato delle misure per l’ambiente PowerPc, evidenziate in figura 5.

Figura 5: confronto latenza minima Massima e varianza IRQ.

Figura 5: confronto latenza minima Massima e varianza IRQ.

Dalla figura è possibile rilevare che la versione di Linux RTAI è quello che fornisce il miglior tempo, pari a 330 nanosecondi di variazione massima, mentre R TLinux peggiora questo tempo di circa 30 nanosecondi: il tempo peggiore, secondo i  ricercatori italiani, è da attribuire a VRTXsa che riporta un tempo di 510.

» Jitter. La figura 6 mostra i dati ricavati dal gruppo tedesco.

Figura 6: jitter: PowerPc vs Intel x86.

Figura 6: jitter: PowerPc vs Intel x86.

La figura relaziona i  dati tra le due differenti architetture hardware: PowerPc e Intel x86. Come vediamo, R TAI è quello che presenta maggiore stabilità; infatti, ha un jitter di circa 19µs quando il  sistema è sottoposto a carico di lavoro. Xenomai, invece, non è molto stabile:  il suo jitter oscilla da 22µs a 33µs. Il più alto jitter si trova nella combinazione tra PowerPc, Linux 2.6 e Xenomai senza un carico di sistema. Su Intel è di nuovo RTAI protagonista; infatti, il  jitter di RTAI ammonta a circa 2µs in assenza di carico e di circa 12µs con pieno carico, mentre i valori associati a Xenomai sono, rispettivamente, pari a 4µs e 15µs. Linux kernel 2.6 con rt-preempt patch mostra un valore, invece, pari a 24µs e 30µs.

» Maximal frequency. I risultati  di questo test sono mostrati nella figura 7.

Figura 7: risultato del frequency benchmark.

Figura 7: risultato del frequency benchmark.

Il grafico mostra che con l’architettura Intel, in combinazione con RTAI, si ottiene il valore più apprezzabile con una frequenza di 10kHz con Linux kernel 2.6 e di 5kHz con il kernel 2.4. I valori ricavati su PowerPc  sono  inaspettatamente  bassi, 1.2kHz, ma si ritiene, ragionevolmente, che questi sono da imputare alle basse prestazioni delle porte hardware.

» Inter-process communication. La figura 8 mostra il grafico della stima ottenuta dall’Università La Sapienza su IPC con mailbox in kernel space.

Figura 8: test IPC.

Figura 8: test IPC.

La figura pone in evidenza  il dato apprezzabile di VRTXsa. RTLinux è sicuramente  il sistema più prestante, RTAI mostra la sua perturbabilità in caso di presenza di carichi o stress di sistema, mentre VRTXsa è sicuramente quello meno veloce, ma, viceversa, presenta un comportamento più costante. I risultati  delle prove condotte, invece, dal gruppo tedesco, sono messe in evidenza in figura 9.

Figura 9: risultato del test IPC

Figura 9: risultato del test IPC

» Overload. La tabella 4 mostra i  risultati dei test condotti dal gruppo tedesco.

Tabella 4: priority test PowerPc.

Tabella 4: priority test PowerPc.

» Priority. La tabella 2 mette in evidenza i risultati  per Intel x86 con Linux kernel 2.6 e Xenomai.

Tabella 2: priority test Intel x86.

Tabella 2: priority test Intel x86.

I thread elencati in colonna acquistano per prelazione  i thread elencati nelle righe. Per esempio il thread T2 acquista per prelazione  il thread T3 40 volte quando il sistema non è in carico e 48 volte quando il sistema  è sotto carico. Il thread T0 ha priorità più alta e T3 ha priorità più bassa. La stessa prova è stata svolta anche con il test bench PowerPC con Linux 2.6 con Xenomai.  Il test svolto su PowerPC non ha le stesse prestazioni come per Intel x86, tabella 3.

Tabella 3: priority test PowerPc.

Tabella 3: priority test PowerPc.

Conclusioni

Complessivamente  i due studi mettono in risalto le prestazioni apprezzabili di RTAI, la versione italiana, politecnico di Miano, del kernel real-time di Linux in ambiente PowerPC. È opportuno, però, fare alcune considerazione. Per esempio, i  due studi non descrivono le opzioni di compilazione e non dicono nulla sulle eventuali ottimizzazioni utilizzate. Inoltre, lo studio dell’università La Sapienza non mette in evidenza le versioni di Linux utilizzate.

 

 

Scarica subito una copia gratis

Scrivi un commento

Seguici anche sul tuo Social Network preferito!

Send this to a friend