Pubblichiamo un guest post di Emanuele Rampichini
Troppo spesso nel mondo dell’informatica c’è confusione riguardo al concetto di “tempo reale”. Siamo abituati ad utilizzare sistemi operativi che rispondono in maniera immediata ai nostri comandi, siano essi impartiti da una tastiera da un mouse o da altre periferiche. Questa abitudine porta a pensare che un sistema possa essere considerato in “tempo reale” semplicemente in relazione a quanto più rapidamente le risposte ai nostri stimoli vengano interpretate, processate e le risposte restituite.
Nei sistemi operativi interattivi tradizionali il tempo medio di risposta di un processo è il parametro su cui si gioca la partita. Nei sistemi realtime i concetti centrali sono invece quelli della garanzia e della prevedibilità. Non ci importa che un certo numero di processi vengano eseguiti complessivamente velocemente ma vogliamo delle garanzie temporali sui singoli processi (tecnicamente parliamo di deadline).
Per rendere chiaro questo concetto possiamo fare un esempio molto semplice:
Supponiamo che alle 8:00 di mattina vi vengano assegnati i seguenti compiti:
– Pagare la bolletta
– Comprare il Pane
Supponiamo che per qualche motivo vi troviate di fronte a queste due possibilità:
– Passare immediatamente alle poste riuscendo a concludere il pagamento per le 10:00, poi al supermercato completando i compiti assegnati alle 11:50
– Passare prima al supermercato riuscendo a comprare il pane per le 9:30 e solo in seguito alle poste completando i compiti assegnati alle 11:00
Ovviamente nessuna persona (sana di mente) conoscendo le due alternative sceglierebbe la prima possibilità rispetto alla seconda. Ma se cambiassimo le carte in tavola e inserissimo ulteriori vincoli nel problema?
– La bolletta va pagata entro le 10:30 pena il pagamento di una sovratassa
– Il pane va acquistato entro le 12:00 pena il salto del secondo pasto più importante della giornata :D
Ecco che quella che fino a un secondo fa ci sembrava una scelta illogica adesso diventa non solo comprensibile ma addirittura la scelta preferibile. Arrivare alle 11:50 e non alle 11:00 a casa non compromette in alcun modo il pranzo e non implicherà l’esborso di una sovratassa.
Ecco come il concetto di tempo reale esula da quello di velocità assoluta di risposta ed entra nel contesto dell’ambiente in cui si opera (nell’esempio l’ambiente sono i vincoli inseriti in un secondo momento).
Il passo successivo è quello di individuare le conseguenze del mancato rispetto dei vincoli temporali. Solitamente i processi che si presentano in un sistema in tempo reale vengono suddivisi in due categorie:
PROCESSI HARD REALTIME:
Processi in cui il mancato rispetto dei vincoli temporali (sforamento delle deadline) comporta un effetto catastrofico sul sistema.
In generale tra gli esempi di processi hard realtime possiamo annoverare tutti quelli che hanno a che fare strettamente con l’ambiente reale circostante(sensoristica, sistemi di attuazione, controllo di dispositivi automatici)
PROCESSI SOFT REALTIME:
Processi in cui lo sforamento dei vincoli temporali comporta un degrado delle prestazioni, ma non viene compromesso il comportamento complessivo del sistema. Pensiamo per esempio al motore di rendering di un videgame, che in alcune situazioni potrebbe rallentare per via di carichi più alti del previsto con l’effetto di vedere il flusso di immagini scattare.
Nei sistemi complessi molto spesso le due categorie di processi convivono e vanno gestite contemporaneamente.
Per dare una idea generale di quello che deve essere un sistema operativo in tempo reale possiamo elencarne le caratteristiche attese:
– Gestione esplicita dei vincoli temporali:
La correttezza dei risultati è valutata non solo riguardo ai valori ma anche rispetto al parametro tempo. Un risultato che arriva in ritardo in alcuni ambiti può significare la vita o la morte di una persona.
– Prevedibilità
Il sistema deve essere sempre in grado di prevedere le conseguenze delle decisioni che si troverà a prendere.
– Tolleranza ai sovraccarichi
Bisogna prevedere l’eventualità di sovraccarichi e prendere decisioni a riguardo senza compromettere il corretto funzionamento del sistema.
– Monitorabilità
Deve conoscere se qualcosa sta andando storto al suo interno e essere in grado di segnalarlo.
– Flessibilità
Deve essere modulare per adattarsi il più possibile alle esigenze delle applicazioni che ci gireranno sopra.
Svincolandosi dall’esempio particolarmente ridicolo descritto sopra e dalla panoramica generale, problemi che vanno affrontati nell’ottica del “tempo reale” sono ovviamente ampiamente presenti nella società moderna. Basti pensare ai sistemi ABS delle automobili, o ai sistemi di controllo e stabilizzazione degli aeroplani.
Nell’ articolo che seguirà analizzeremo come la scena open source proponga una offerta estremamente variegata di sistemi operativi adatti alla progettazione di applicativi in tempo reale.
Riferimenti:
Appunti delle lezioni sistemi operativi in tempo reale – Prof Aldo Franco Dragoni
Sistemi in Tempo Reale – Giorgio C. Buttazzo
Wikipedia en
Al mio primo colloquio di lavoro, ormai circa venti anni fa … mi chiesero proprio di descrivere e definire un sistema in tempo reale. Il tempo passa, ma i fondamenti dell’informatica son sempre quelli.
Ottimo articolo e bellissima foto :D
A questo punto mi aspetto in futuro un cenno sulle problematiche della parallelizzazione dei processi, “hard” & “soft”.
@ilruz
Grazie prima di tutto dei complimenti. Per le prossime puntate sto preparando una carrellata di alcuni sistemi operativi real time open source come scritto nell’articolo. Per le problematiche della parallelizzazione dei processi, “hard” & “soft” credo che sia difficile proporre un pezzo del genere senza andare un po più a fondo con la spiegazione degli algoritmi in ballo.
“Ovviamente nessuna persona (sana di mente) conoscendo le due alternative sceglierebbe la prima possibilità rispetto alla seconda”
gli anziani!! stanno sempre a rompere le scatole xD
sia in posta che dal dottore O.O
scherzi a parte grazie per l’articolo: chiaro, semplice e alla portata di tutti (compresi i nOOb come me :D)
In effetti non avevo pensato a loro! :D
Sono contento visto che il mio intento era proprio quello! ;-)
articolo di anteguerra…
@homero
Consigli e idee naturalmente sono bene accetti. Ci tengo a precisare però che il fatto che dei concetti siano vecchi non significa che non abbiano dignità di essere presentati e discussi.
Aspetto spunti da parte tua e ovviamente da tutti quelli che vorranno proporne.
Bell’articolo… aspettiamo i prossimi!
PS ma sei new entry della squadra AD?… in tal caso benvenuto tra noi!!!
@Homero
Concordo con l’autore: i sistemi real time sono ancora oggi molto in voga. Prorio lo scorso semestre mi e’ capitato di seguire un seminario riguardante un “nuovo” (relativamente recente) metodo di gestione delle priorita’ che e’ stato usato nella missione Rover della Nasa (Rover era quello su Marte, vero? Spero di non confondermi).
x homero
commento di ….. (sostituite i punti con lettere e avrete la soluzione !!
I RTOS sono tutt’ altro che antidiluviani.
Chi fa girare le centrali elettriche, gli apparecchi medici, i gadget dei soldati, gli apparati spaziali, i radiocomandi delle automobiline da corsa, i sistemi di allarme, i pc di chi vuol fare musica, e chi più ne ha più ne metta, sono tutti gestiti da sistemi real-time.
Per chi non ne sa niente è un ottimo spunto di riflessione. E se ne sai più di tutti noi scrivilo.
Mi sfugge un pò cosa siano gli OS realtime…
NON stiamo parlando di OS che abbiamo sui PC di casa, ma di OS (di cui ci parlerai) dedicati ad ambiti molto specifici o che comunque fanno una distinzione nel gestire i processi tra hard (real time) e soft. Quindi ambiti medici, professionali ecc. giusto? :)
ecco forse n0v0 mi ha risposto…
ma perchè l’esempio dei videogames – è fuorviante no?
Faccio i miei migliori auguri di buon proseguimento al mio amico e compagno di studi per il suo post inaugurale ;)
Vedrete che la sua competenza nel settore sarà fonte di ottimi articoli e di ottimi spunti di discussione :)
Complimenti lele!
Ciao a tutti
Gianluigi
@simone
Diciamo che sono in fase di apprendistato. Vediamo come va poi si vedrà! Grazie comunque del benvenuto.
@NeXuS
Non ti sbagli affatto. Il Mars Rover Spirit (progettato per durare intorno alle 3 settimane e che ha festeggiato recentemente i 5 anni di passeggiate su marte) è spinto dal sistema operativo realtime VxWorks della Wind River.
@tmx
È assolutamente corretto quello che ha scritto n0v0. L’esempio del motore di rendering di un videogame in effetti può essere fuorviante ma l’ho usato per descrivere i processi soft-realtime. In fondo un motore grafico deve produrre e renderizzare una scena per un numero fisso di volte al secondo (FPS). Il riferimento era per far capire che in un motore 3D lo sforamento in alcuni ambiti dei vincoli temporali è ovviamente ben tollerato e non implica un fallimento.
@Gianluigi Biancucci
;-)
grazie Emanuele, aspettiamo prossimi interventi!
Per l’ intera redazione, vorrei dire – giusto perché l’ argomento è anche quello delle new entry – ma le quote rosa..?
Per ora c’ è l’ ottima Eleonora che però, poverina, è sola soletta… ;-)
Ottimo intervento!
Benvenuto!
Uso Ubuntu Studio con real time kernel per studio/hobby e mi trovo veramnete bene!
non mi va di scrivere lunghe disquisizioni
andatevi a vedere i server serie Z di IBM…
…
ormai non si parla piu’ di software in real time ma solo di hardware in real time…
qualunque software che supporti hardware in real time è esso stesso real time…
anzi nel caso di ibm…l’hardware è capace di riavviare porzioni di OS, e spostare treand su altri nodi quando la CPU è in sovraccarico o si verificano guasti hardware…
…
quindi non venitemi a parlare di microkernel e soluzioni embedded…
il real time è una funzione hardware e non software…
dall’altronde con tutti gli HAL che abbiamo….le virtual machine…i virtual OS…e quant’altro no potrebbe essere altrimenti…
se poi vogliamo tornare indietro di 20 anni accomodatevi pure…
@homero:
si la tua posizione è interessante, però come la mettiamo per tutti quegli ambiti in cui non è possibile (per motivi di costo e/o di tempi di sviluppo) utilizzare un sistema hardware realtime andando cosi a far ricadere le scelte su OS realtime?
Tuttavia rimane ovvio che non si possono paragonare le prestazioni di operazioni svolte con ausilio hardware (ASIC, DSP, …) e le stesse operazioni in ambito software, in particolare considerando le architetture general purpose, ma credo che questo esula lo scopo dell’articolo! ;)
Comunque gran bell’argomento! ;)
Mi unisco anch’io ai complimenti. Ne ho sempre sentito parlare, di sistemi operativi real time, ma non ho mai approfondito cosa fossero. Ora ho colmato, almeno a livello concettuale, la lacuna. Grazie!
Secondo me sarebbe stato bene un esempio riguardante una pressa in una fabbrica.
Se si preme il pulsante d’emergenza, lo stop, la pressa deve fermarsi immediatamente, pena la riduzione in frittella di un operaio che voleva emulare charlie chaplin.
@homero
Non riesco a trovare riferimenti al real time nel materiale che ho velocemente cercato riguardo ai server serie Z di IBM. Se potessi fornire almeno un link a supporto del tuo commento mi piacerebbe approfondire.
Se affermi qualcosa del genere allora mi viene da pensare che tu non abbia capito in fondo di cosa si parla nell’articolo.
@carletto
Agli ASIC e DSP aggiungerei anche gli FPGA molto più economici e con il vantaggio di essere riprogrammabili a piacere.
@D
Avevo pensato di inserire un esempio del genere ma ho volutamente evitato. Il motivo è che in quel modo qualcuno potrebbe focalizzarsi sulla velocità del sistema (che ovviamente per molti dei problemi trattati è un parametro fondamentale) e non su quello dei vincoli temporali generici. Volevo cercare di far capire che dal punto di vista teorico pensare processi che devono terminare entro un anno non è niente di diverso da pensare a processi che devono terminare entro un millisecondo.
Comunque hai fatto bene ad aggiungerlo.
Ho riletto purtroppo solo adesso il precedente commento. La stanchezza mi ha giocato un brutto scherzo.
Ecco la versione in italiano corrente:
Beh velocità e tempo sono un po’ due facce della stessa medaglia. La necessità di concludere un determinato task in un determinato lasso di tempo impone una gestione seria della velocità di esecuzione preferendo, mettendo in priorità, determinate cose su altre.
Credo che per poter fare degli esempi migliori sarebbe il caso di divagare sui vari concetti di multitasking e timesharing, su come vengono gestiti (e, passami l’esempio cagnesco, “mischiati tipo carte da poker”) i vari processi ecc.ecc. perchè l’esempio della pressa spiegherebbe meglio un os come il dos ed il suo interfacciamento diretto con l’hardware che non un rtos.
Sinceramente, per quanto ne so io parlare di os realtime su sistemi consumer è un pò azzardato. A che serve un so realtime su hardware non realtime? L’elettronica di un normale computer non ha sistemi di controllo in tal senso…
Giulio.
@Giulio Severini
Nessuno ha parlato di sistemi realtime su hardware consumer (anche se in generale un comportamento soft-realtime è riproducibile anche sui nostri PC di casa con alcune strategie). Ovviamente non essendo l’hardware pensato per quel compito va gestito in qualche modo il non determinismo portato per esempio dalla possibilità di cache miss, o dall’uso del DMA per l’accesso alle periferiche passando per la gestione degli interrupt. Altro problema sono i linguaggi di programmazione classici che non prevedendo il fattore tempo esplicitamente e forniscono degli “aiuti” al programmatore che si pagano in termini di prevedibilità del sistema (basti pensare alla allocazione dinamica della memoria) ma comunque esistono progetti atti a colmare tali lacune.
@Emanuele
Si si hai ragione, FPGA e anche le più “classiche” CLPD. Tuttavia per la pura elaborazione i DSP o le FPGA delle serie mixed-signals sono preferibili anche perchè le logiche programmabili pagano sempre la loro fantastica flessibilità. A meno di non spendere molto salire con le frequenze operative rimane molto difficile.
Invece sarebbe interessante vedere come si comportano le nuove architetture GPGPU in termini di vincoli realtime. Ovviamente mi riferisco alla loro architetture interne (estremamente parallelizzate) non alla GPGPU in sè per sè!
Comunque dipende sempre dal campo di applicazione, nel caso della pressa industriale può non aver senso implementare sistemi di sicurezza in software, che diventerebbe l’anello debole dell’intero apparato, ma piuttosto una serie di componeti hardware (elettrici e elettronici) che nel minor tempo possibile possano salvare qualche vita, anche perchè bisognerà passare comunque attraverso degli appositi attuatori: Relè veloci (es. RF) oppure di transitor/tiristori di varie nature. Al punto tale che sommare troppi lag a volte non è buono! ;)
@homero
E’ vero non sarà un argomento all’ultimo grido (poi non è vero ci sono interi gruppi di ricerca che sviluppano certi OS e hardware ottimizzato ^^) ma dire che è una cosa anteguerra non mi sembra corretto.
In fondo anche l’architettura di Von Neumann è anteguerrra (se nn erro intorno agli anni ’40) ma i calcolatori moderni sono sviluppati a partire da questo tipo di architettura.
Una classificazione alternativa dei sistemi real-time prevede:
1) Hard real-time
2) Firm real-time
3) Soft real-time
La definizione di Hard real-time è come quella dell’articolo.
La classificazione poi differenzia firm real-time da soft real-time.
In ambedue i casi, occasionali deadline mancate sono tollerabili; nel caso di sistemi firm real-time però, non vi è nessuna utilità a completare il lavoro (fino ad ottenere un output) se la deadline non è rispettata; nel caso di sistemi soft real-time può avere qualche utilità completare il lavoro anche se in ritardo.
Alla fine comunque, la grande separazione è fra 1) da una parte e 2) e 3) dall’altra.
Questa divisione comporta approcci molto differenti nella progettazione e nelle tecniche di analisi temporale del sistema.
Alla fine c’è sempre qualcuno che fa il professorino, ma mi fa piacere vedere che generalmente invece i toni della discussione sono improntati alla discussione ed al confronto.
E’ chiaro che la sfida sta proprio nel rendere affidabili strumenti per il quale l’errore non è semplicemente possibile (abs, accelatore drive by wire, cruise control, solo per rimanere nell’ambito automotive). Ovvio che tutto ciò a spesso si debba ottenere con hardware embedded anche di poco costo.
Altrimenti caro omero, ci mettiamo tutti un bel 3090 bipolare con raffreddamento ad acqua nel bagagliaio.
Alla fine c’è sempre qualcuno che fa il professorino, ma mi fa piacere vedere che generalmente invece i toni sono improntati alla discussione ed al confronto.
E’ chiaro che la sfida sta proprio nel rendere affidabili strumenti per il quale l’errore non è semplicemente possibile (abs, accelatore drive by wire, cruise control, solo per rimanere nell’ambito automotive). Ovvio che tutto ciò a spesso si debba ottenere con hardware embedded anche di poco costo.
Altrimenti caro omero, ci mettiamo tutti un bel 3090 bipolare con raffreddamento ad acqua nel bagagliaio.
@Marco P.
Grazie per l’interessante aggiunta. Sinceramente conoscevo soltanto la categorizzazione che ho esposto ma comprendo come un ulteriore distinzione tra firm (mi viene da pensare a un decoder video in cui non ha senso continuare a elaborare un fotogramma se nel frattempo il successivo è stato presentato) e soft possa essere utile.
@Giovanni
Sono anche io molto contento del fatto che siano venute fuori cose interessanti dai commenti. Alla fine credo che l’obbiettivo di un blog sia proprio quello.
Il kernel Linux conosce tre approcci:
– scheduler CFS (Ingo Molnar) quello default
– scheduler BFS (Con Kolivas)
– scheduler RT, real time (Thomas Gleixner)
Per i miei usi il migliore e` BFS di Con Kolivas,
esempio su una Intel Core 2 Duo 1866MHz,
tempi piu` corti per un
time make -j 2 bzImage
“tempi piu` corti per un
time make -j 2 bzImage”
Secondo me questo test dice tutto e dice niente perchè ho come l’impressione che la scelta dello scheduler da solo risulti ininfluente se manca il giusto contorno di programmi progettati per “trovarsi meglio” con un metodo piuttosto che un altro.
E’ un po’ lo stesso discorso di quando si ricompila il kernel credendo di guadagnarci chissà cosa in velocità, poi si scopre che a rallentare era tutto il contorno meno che il kernel.
@D
“tempi piu` corti per un
time make -j 2 bzImage”
controllando con sar(1) e top(1) i due CPU
con scheduler BFS sono sempre idle allo 0.0%,
con gli altri scheduler uno dei due e` spesso idle fino al 20%
i time riportati da BFS sono sul 20-30% piu` corti.
Stesso kernel, patchato con la versione BFS, CFS e RT,
.config sempre identico, nei tre casi.
Passino pure tutti i numeri di sto mondo ma nei fatti, nel concreto, nel percepibile si nota effettivamente un miglioramento ?
Ci sono dei test che puoi fare che con gli altri due scheduler mettono alla frusta il sistema mentre con quello eletto no ?
Tanto per dire con un PII 266 e 64MB su windows e linux i divx si vedono a scatti, ci metto beos e vanno fluidi. Questo intendo come miglioramento percepibile. I numeri prendono il tempo che trovano
@D
Se il tuo BEOS funziona cosi` bene,
il suo scheduler supera quelli di Linux!
@Mario Vanoni
Nel prossimo articolo ci sarà un accenno alla situazione storica di linux rispetto al real-time.
Devo dire però che valutare la bontà di uno scheduler real-time sulla compilazione non mi sembra una buona idea soprattutto perchè non è quello il suo campo di applicazione. Inoltre il fatto che uno scheduler complessivamente ottimizzi il tempo medio di risposta (Per quanto questo sia un comportamento auspicabile in generale) non ha molto a che fare con il discorso del real time.
@D
Giusta l’osservazione che le applicazioni per giovare di un sistema operativo real-time devono essere ripensate.
Meno d’accordo sull’ approccio di tipo “benchmark”. Tutta la scienza dei sistemi operativi real time è basata sul determinismo. Le applicazioni si progettano a priori con in mente i vincoli temporali e le contromisure nel caso questi vengano disattesi. Il tutto si fa in maniera il più possibile analitica lasciando il meno possibile al caso.
@Emanuele Rampichini
Uno scheduler RT deve mandare avanti la task per sopravvivere,
ma se ha tante task che girano, quale e` la piu` importante?
Con BFS questa sera:
quattro schermi X aperti ed attivi,
su una un video del Corriere, a singhiozzo.
Spenti tre schermi X, usabile.
Ma chi dice allo scheduler questa task ha priorita` assoluta?
Sia BFS che CFS che RT riducono processi non indispensabili,
ma quale e` veramente vitale, come lo scoprono?
Trovi la mia mail su http://www.slacky.eu Mario Vanoni in chiaro.
“Le applicazioni si progettano a priori con in mente i vincoli temporali e le contromisure nel caso questi vengano disattesi.”
Non mi sembra sbagliata l’idea del video come metodo di confronto.
Se la potenza non è sufficiente ad elaborare tutti i frame, deve scattare un auto frameskip per risincronizzare video e audio dando priorità alla fluidità di quest’ultimo (l’occhio può non percepire dei frame che si perdono, l’orecchio invece non si perde niente). Nel caso del video su beos non c’era neanche bisogno di perdere frame perchè evidentemente il sistema risultava sufficientemente parsimonioso da non rendere necessarie certe contromisure
@Mario Vanoni
Algoritmi come CFS cercano di implementare nel migliore dei modi possibili il comportamento di una macchia multitask ideale su hardware reale (ovvero dare a tutti la giusta parte di CPU). Ovviamente questo è un comportamento apprezzato e apprezzabile in un sistema desktop ma non avendo una gestione esplicita delle deadline è lontano da essere un algoritmo real time. Io stesso ho utilizzato per alcune settimane BFS sul mio portatile testando personalmente l’aumento generale di reattività ma non è questo il punto (cosa che tra l’altro ho scritto nella prima parte dell’articolo).