220 likes | 394 Views
FACOLT Á DI INGEGNERIA CORSO DI LAUREA INGEGNERIA INFORMATICA. Progetto e Sviluppo di un Algoritmo di Scheduling per il Sistema RTAI. Candidato: Luca Marzario. Sommario. Motivazioni Obiettivi Architettura del sistema RTAI Implementazione Test Conclusioni. Motivazioni.
E N D
FACOLTÁ DI INGEGNERIACORSO DI LAUREAINGEGNERIA INFORMATICA Progetto e Sviluppo di un Algoritmo di Scheduling per il Sistema RTAI Candidato: Luca Marzario
Sommario • Motivazioni • Obiettivi • Architettura del sistema RTAI • Implementazione • Test • Conclusioni
Motivazioni • Applicazioni interattive e multimediali • Quality of service • Sistemi operativi general-purpouse (Windows, Linux, ...) non offrono garanzie temporali • Sistemi operativi real-time • troppo costosi • non offrono supporto adeguato alle applicazioni multimediali e interattive
Caratteristiche di Linux • Linux non è un sistema operativo real-time • Possiede molte caratteristiche che ne fanno un ottimo sistema operativo: • robusto e affidabile • ampio supporto di processori e periferiche • networking avanzato • strumenti di sviluppo e dubugging • interfaccia grafica • ampia disponibilità di software
Linux e Real-Time • Linux non possiede le caratteristiche tipiche dei sistemi real-time: • determinismo (prevedibilità) • possibilità di preemtion • specifica vincoli temporali • programmazione “fine” del timer
RTAI • Real-Time Application Interface (RTAI) • Affianca a Linux un kernel real-time • Schedula Linux come idle task • Vantaggi • Buone prestazioni real-time per i task RTAI • Sistema di sviluppo basato su Linux • Problemi • Starvation di Linux in caso di alti carichi real-time • Crash del sistema in caso di errori di programmazione o malfunzionamenti
Soluzioni • Implementare un algoritmo di reservation su RTAI • Riservare banda di utilizzo del processore a ogni task • Tempo minimo di esecuzione garantito • Protezione del sistema da errori di programmazione o malfunzionamenti • Schedulare Linux con il CBS • Shell di comandi sempre attiva • Minor tempo di risposta delle applicazioni Linux
Real Time Application Interface (RTAI) • Sistema real-time che permette l’esecuzione di applicazioni tipo hard real-time • Fa parte dei progetti Linux Real-Time • Questo tipo di sistemi si definisce “real time executive” • Solo il kernel real-time ha il pieno controllo dell’hardware • Principali sistemi: RTAI e RTLinux Linux Task 1 Task n real time executive hardware
RTAI vs RTLinux • Prestazioni offerte paragonabili. • Interfacce di programmazione (API) molto simili • RTAI è meno intrusivo rispetto a RTLinux: • Maggiore mantenutibilità • Più facile aggiornamento delle modifiche kernel Linux • RTLinux open-source non è più mantenuto • RTAI costantemente aggiornato • Ultima versione di RTAI rilasciata il 23 settembre 2002
RTAI • Costituito di moduli da inserire nel kernel Linux precedentemente modificato • Moduli principali • Gestore interruzioni (interrupt dispatcher) • Scheduler Gest. Interr Scheduler • Moduli aggiuntivi • FIFO • shared memory • POSIX etc. kernel Linux modificato FIFO Shared Mem POSIX Linux Task • Task Real-Time RT task
Linux Applicazione RTAI • Real-time (acquisizione, elaborazione, controllo etc.) • eseguita da task RTAI (real-time) Costituita di due componenti • Non real-time (visualizzazione, tracing etc.) • eseguita da processi Linux • non disturba le attività real-time • Meccanismi di comunicazione • fifo • scambio di messaggi • segnali • memoria condivisa • ... P1 Pk Task RT1 Task RT2 Task RTn P2 RTAI
Linux Task 1 Task n RTHAL hardware RTHAL • Modifiche kernel Linux • Linux perde il controllo diretto dell’hardware • Attivazione RTAI • modifica dei puntatori dell’rthal • Disattivazione • ripristino dei puntatori alle funzioni originali di Linux Hard disable Linux disable interrupt RTHAL disable interrupt Soft disable
RTAI interrupt dispatcher Salva registri rtai handler? rtai handler Linux in esec? Linux handler? Linux handler RTAI dispatcher interruzione pendente Ripristina registri
Scheduler • Architetture supportate • monoprocessore • multiprocessore • Politiche di scheduling • Prioritario Semplice • Rate Monotonic • Earliest Deadline First • Gestione del Timer • modalità periodica • modalità one-shot
Resource reservation • Ogni task ha riservato un tempo Q ogni periodo T • Processi hard real-time e soft real-time possono convivere • E’ possibile riservare una frazione del tempo macchina a Linux
Il Constant Bandwidth Server • Resource reservation tramite CBS (Constant Bandwidth Server) • Basato sul TBS e DSS • Rispetto al TBS non richiede WCET • Rispetto al DSS migliori prestazioni
Algoritmo CBS • Ad ogni task viene associato un server schedulato con EDF • capacità massima • periodo • Ad ogni istanza servita dal server viene associata una deadline dinamica • Durante l’esecuzione la capacità viene decrementata. Una volta esaurita, viene ricaricata al suo valore massimo e la deadline viene posposta (diminuzione priorità)
Applicazione di prova RT1 FIFO RT2 Linux P1 RT3
Conclusioni • Risultati ottenuti • Diminuzione dei tempi di risposta delle applicazioni Linux • Garanzia di schedulazione di Linux anche in caso di grossi carichi real-time • Maggior controllo • Maggiore robustezza