Prestazioni real-time ottimizzate a confronto

ALA038-Figure2

Alcuni sistemi real-time possono avere requisiti "hard real-time", per i quali cioè il jitter (ovvero l’errore di temporizzazione di un task relativo a iterazioni successive di un programma o loop) sui vincoli temporali deve restare all’interno di soglie prefissate. Ciò serve ad evitare che eventuali malfunzionamenti del sistema possano produrre danni di notevole entità. Altri sistemi devono soddisfare requisiti meno severi (soft real-time): si pensi ad esempio all'ottimizzazione dell'efficienza energetica, che non è causa di guasti gravi o catastrofici ma il cui rispetto è importante su tempi di funzionamento molto lunghi. In ogni caso è essenziale comprendere l'esatta risposta in real-time di una determinate architettura di sistema in termini di latenza del loop in real-time, jitter e altri requisiti. In prima istanza è possibile ipotizzare che un sistema privo di sistema operativo (o bare metal) sarà intrinsecamente più veloce, ma questa ipotesi non è necessariamente vera: eseguire un'applicazione su un application processor (processore applicativo) operante a elevata velocità su cui gira un Rtos ricco di funzionalità può fornire tempi di risposta migliori rispetto a quelli di un'implementazione di tipo "bare metal".


Requisiti e problematiche
Per comprendere i requisiti delle applicazioni real-time, le applicazioni di controllo industriale rappresentano un caso esemplare in quanto prevedono processi di tipo sia real-time sia non real-time. I task in real-time gestiscono gli interrupt esterni - sfruttando l'interrogazione (polling) dei registri o una routine per la gestione dell'interruzione Isr (Interrupt service routine) - che si verificano con cadenze dell’ordine delle decine di microsecondi durante i quali il sistema risponde all'interrupt, trasferisce i dati richiesti, effettua l’elaborazione e ritrasferisce i risultati prima dell’arrivo dell’interrupt successivo. Per assicurare una risposta in real-time il jitter non deve essere superiore ad alcuni microsecondi. Gli utenti spesso raggruppano tutte le elaborazioni in real-time in un core particolare per avere un controllo più diretto e ottenere, teoricamente, prestazioni migliori. I task non real-time sono generalmente compiti ausiliari, connessioni in rete e gestione dell'interfaccia utente. La condivisione delle periferiche tra i core del processore è minima o assente, anche se è necessario condividere alcuni buffer di memoria comuni per la sincronizzazione, la comunicazione o la visualizzazione dei dati. Tra gli altri requisiti che hanno una notevole importanza si possono annoverare la semplicità di programmazione e la minimizzazione del rischio, ragion per cui è richiesto il supporto da parte di un valido ecosistema - l’ecosistema Arm in questo caso. Per garantire che un progetto possa essere trasferito in tempi brevi su processori caratterizzati da migliori prestazioni e beneficiare dei vantaggi legati alle innovazioni apportate a livello software, la portabilità delle componenti hardware e software è un altro elemento critico, che spesso implica la necessità di eseguire la programmazione su un'astrazione del sistema operativo. I requisiti inerenti la risposta in real-time e la tolleranza al jitter sono in larga misura responsabili di molte decisioni relative ai progetti real time. Il tempo di risposta è solitamente espresso sotto forma di loop in real-time durante il quale il sistema gestisce un interrupt ed esegue tutte le elaborazioni richieste prima dell'arrivo dell'interrupt successivo. Il tempo di loop in real-time può variare da circa 1 µs per un sistema di tipo hard real-time alle decine di microsecondi nel caso di sistemi real-time.

Un esempio applicativo
Un esempio applicativo, che gira su una scheda di sviluppo equipaggiata con un SoC della linea Cyclone V di Altera può fornire dati utili per una valutazione oggettiva delle differenti configurazioni di sistemi operativi real-time. Il SoC in questione integra un application processor nella struttura dell'Fpga. Il processore dual-core Arm Cortex-A9 presente nel sistema Hps (Hard processor system) del SoC è di tipo "tightly coupled" grazie all’uso della tecnologia MPCore di Arm in configurazione Smp (Symmetric multiprocessing) classica. Soluzioni software mature e collaudate sono disponibili da molti fornitori software facenti parte dell'ecosistema Arm per consentire la multielaborazione di tipo asimmetrico o Amp (Asymmetric multiprocessing). Il sistema cui si fa riferimento utilizza sia il cluster formato dai due core del processore Cortex A9 sia l'Fpga, mentre un circuito Dma (Direct memory access) sviluppato ad hoc e denominato DataMover che gira sull'Fpga e opera in cooperazione con il cluster Cortex A9 è preposto al trasferimento dei dati da/verso l'Fpga. Il sistema riceve gli interrupt dall'Fpga e i dati sono inviati da quest'ultima al sistema Hps per la gestione - operazione che prevede una ridotta mole di elaborazione – dopo di che alcuni risultati sono scritti nuovamente nell'Fpga. I task che simulano la gestione dell'interrupt, il trasferimento dei dati e il successivo trasferimento dei dati all'Fpga sono complessivamente denominati "processi real-time". Le misure del tempo di loop in real-time del percorso di andata e ritorno (round-trip) e del jitter rappresentano un'indicazione della velocità di risposta in real-time del sistema e gli interrupt sono gestiti mediante interrogazioni o routine Isr. In questo sistema gli interrupt esterni sono simulati dai dati memorizzati nella Ram a bordo del chip implementata nell'Fpga. Le dimensioni dei dati possono essere facilmente modificate per analizzare le relazioni che intercorrono tra le dimensioni dei dati e l'efficienza delle operazioni Dma. Il software applicativo è stato implementato in tre differenti configurazioni: Linux (LTSI v3.10) e VxWorks (v6.9) che girano singolarmente in modalità Smp con core affinity (affinità dei core - che indica in pratica la tendenza di un'applicazione a girare su un particolare core e "resistere" alla migrazione) su entrambi i core del cluster Cortex-A9 e "bare metal" che utilizza le librerie hardware presenti in SoC Embedded Design Suite 14.0 che gira su un core singolo. Tutte e tre le implementazioni utilizzano il core 1 per il DataMover - trasferimento dei dati e gestione degli interrupt - mentre le due implementazioni con sistema operativo sfruttano anche il Core 0 per far girare una serie di Fibonacci continua al fine di simulare task di tipo non real time. Il Core 0 non è impiegato nella configurazione "bare metal" per rappresentare un ambiente nel caso migliore, senza rallentamenti o gestione dei buffer.

Analisi dei risultati
Consideriamo i risultati per il sistema Linux, dove il Core 1 gestisce i task in real-time utilizzando l'interrogazione ciclica o le routine Isr. Dall'analisi delle due figure non si evidenzia alcuna differenza in un sistema Linux nello stato busy o in quello di idle. L'interrogazione produce una risposta complessiva leggermente migliore, mentre il jitter è relativamente alto (<10s) in entrambe le modalità (interrogazione e Isr). Nei sistemi dove un jitter dell'interrupt uguale o superiore a 10 1è accettabile, un sistema Linux SMP standard risulta adeguato allo scopo. Analizziamo i risultati relativi a un sistema VxWorks, dove il Core 1 sta gestendo task in real-time utilizzando l'interrogazione ciclica o le routine Isr. Anche in questo caso non si rilevano significative variazioni in un sistema VxWorks nello stato busy o nello stato di idle in termini di tempo di loop. Val la pena sottolineare che si manifestano variazioni di entità inferiore a livello di jitter complessivo in un sistema nello stato busy con dimensione dei dati pari a 1k. Passiamo ai risultati relativi a un sistema che gira in modalità "bare metal" ed è preposto solamente alla gestione degli interrupt. Come previsto, il jitter è inferiore a 1s utilizzando sia l'interrogazione sia le routine Isr. Il tempo di loop è confrontabile con quello delle altre due implementazioni appena descritte (nel caso si utilizzi l'interrogazione), mentre la risposta ottenuta con la gestione mediante Isr è notevolmente superiore, poiché non sono previste la schedulazione o la prelazione (pre-emption) di eventi. Di conseguenza, la programmazione in modalità "bare metal" non comporta alcun vantaggio in termini di prestazioni. Oltre a ciò, il prodotto risultante è specifico per un certo hardware e non può essere trasferito in modo semplice su futuri processori che dispongono di core differenti (o in numero maggiore), mentre le applicazioni che girano sulla parte superiore (on the top) del sistema operativo sono astratte rispetto alle differenze dell'hardware e possono essere trasferite rapidamente sui dispositivi futuri.

Processori e real-time
Vista la complessità delle interazioni con il sistema dei più recenti application processor, i moderni sistemi operativi real-time ad alto livello possono non solo garantire le stesse prestazioni in real-time offerte da soluzioni ottimizzate manualmente, ma anche assicurare tutti i vantaggi, in termini di stabilità del sistema e di riutilizzo del progetto, propri delle attuali metodologie di sviluppo software rispetto alle applicazioni "bare metal" ottimizzate. Grazie alla disponibilità di numerosi sistemi operativi gratuiti o a basso costo, molti dei quali già predisposti per sfruttare al meglio i vantaggi delle architetture dei processori, l'adozione di un collaudato sistema operativo come software run time permette agli sviluppatori di un'applicazione di focalizzare la loro attenzione sulle ottimizzazioni a livello di sistema. Oltre a ciò, l'utilizzo di metodi di programmazione ben definiti, come ad esempio Core-Affinity, nei sistemi multicore di tipo simmetrico produrrà generalmente risultati migliori rispetto alla programmazione indipendente di ciascun core. L'impiego di soluzioni standard e collaudate consente agli utilizzatori di ottenere la miglior combinazione possibile in termini di prestazioni, produttività, affidabilità del sistema e scalabilità.

Pubblica i tuoi commenti