FACOLT

1
FACOLTÁ DI INGEGNERIACORSO DI LAUREAINGEGNERIA
INFORMATICA

• Progetto e Sviluppo di un Algoritmo di Scheduling
  per il Sistema RTAI

Candidato Luca Marzario
2
Sommario

• Motivazioni
• Obiettivi
• Architettura del sistema RTAI
• Implementazione
• Test
• Conclusioni

3
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

4
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

5
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

6
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

7
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

8
Real Time Application Interface (RTAI)

• Sistema real-time che permette lesecuzione 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
  dellhardware
• Principali sistemi RTAI e RTLinux

Linux
Task 1
Task n
real time executive
hardware
9
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

10
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
11
Applicazione RTAI

• Costituita di due componenti

• Real-time (acquisizione, elaborazione, controllo
  etc.)
• eseguita da task RTAI (real-time)

• 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 RTn
Task RT2
P2
RTAI
12
RTHAL

• Modifiche kernel Linux
• Linux perde il controllo diretto dellhardware

• Attivazione RTAI
• modifica dei puntatori dellrthal

• Disattivazione
• ripristino dei puntatori alle funzioni originali
  di Linux

Hard disable
Linux disable interrupt
RTHAL disable interrupt
Soft disable
13
RTAI interrupt dispatcher
Salva registri
rtai handler?
rtai handler
Linux in esec?
Linux handler?
Linux handler
RTAI dispatcher
interruzione pendente
Ripristina registri
14
Scheduler

• Architetture supportate
• monoprocessore
• multiprocessore
• Politiche di scheduling
• Prioritario Semplice
• Rate Monotonic
• Earliest Deadline First
• Gestione del Timer
• modalità periodica
• modalità one-shot

15
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

16
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

17
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 lesecuzione la capacità viene
  decrementata. Una volta esaurita, viene
  ricaricata al suo valore massimo e la deadline
  viene posposta (diminuzione priorità)

18
Applicazione di prova
RT1
FIFO
RT2
Linux P1
RT3
19
(No Transcript)
20
(No Transcript)
21
(No Transcript)
22
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