Joseph K ha scritto:Ed il quale (Audiolinux) souna meglio --- col modalita RT bloccato..
Almeno per me, col sistema mio. Opinione personale.
Ah-ah! Interessante.
Joseph K ha scritto:Di sicuro libera risorse e permette di eseguire operazioni piu pesanti,
senza alcun dubbio. È uno dei motivi per cui i Kernel "general purpose" non sono RT, e quelli per uso server spesso non includono neanche il supporto RT standard.
Vale la pena di chiarire un paio di cose. Prima di tutto, il significato di "real-time".
Contrariamente a quanto si potrebbe essere portati a pensare, un sistema "
real-time"
non è un sistema "più veloce", né un sistema che fa le cose più in fretta, o risponde più in fretta.
La caratteristica che definisce un sistema che possa (propriamente) dirsi RT è
la natura deterministica della latenza massima.
In parole povere, mentre un sistema non-RT cerca di rispondere il più in fretta possibile, ma non garantisce nulla in merito ai tempi di risposta (che sono casuali e virtualmente illimitati), un sistema RT spesso risponde più lentamente, ma garantisce che la risposta arrivi entro un determinato tempo massimo (che può essere conosciuto a priori).
Questo può essere fondamentale ed imprescindibile in determinati contesti ed applicazioni, ma ha un prezzo. Parte del quale è proprio la minore efficienza del sistema, che porta ad avere una
risposta mediamente più lenta, ed un "throughput" inferiore rispetto ad un sistema non-RT.
Oltre ai sistemi RT propriamente detti esistono però anche degli standard più "rilassati", che potremmo dire "quasi-RT". In pratica questi sistemi includono delle funzionalità che permettono di avvicinarsi alle caratteristiche di un sistema RT, cioè in sostanza che permettono di ottenere latenze basse, pur non potendo garantire al 100% che queste siano sempre limitate (entro un dato tempo max).
in questo senso, i Kernel Linux "moderni" sono praticamente tutti "real-time", in quanto includono il supporto per le estensioni real-time standard POSIX. I Kernel "RT" vanno oltre, ed hanno modifiche e funzionalità aggiuntive che consentono di implementare sistemi real-time propriamente detti.
La differenza sta in un "piccolo" ma importante particolare: mentre i Kernel "normali" prevedono al loro interno dei "processi"
critici che non possono essere interrotti (dallo scheduler del kernel stesso) finché non hanno completato l'operazione in corso, le versioni "RT" sono "fully pre-emptible", cioè qualsiasi operazione può essere interrotta in qualsiasi momento (o quasi) dallo scheduler. Questo fondamentalmente è ciò che rende possibile garantire la prevedibilità della latenza max.
Sfortunatamente, in pratica questo significa che anche una operazione importante può essere interrotta, causando tempi di esecuzione e ritardi mediamente maggiori di quelli che si avrebbero se si lasciasse che il Kernel faccia quel che ha da fare senza disturbarlo con interruzioni inopportune. Implica inoltre che i diversi "processi" (inclusi quelli interni al Kernel) possono "disturbarsi" a vicenda, potendo dar luogo anche a situazioni di "deadlock", ecc. Le diverse priorità devono essere gestite con la massima cura ed accortezza, altrimenti si rischia di creare soltanto conflitti e problemi a non finire.
In definitiva, a meno che non sia assolutamente necessario (ed IMHO non è proprio il nostro caso), è meglio starne lontani. Specie se non si è più che competenti ed esperti degli innumerevoli dettagli di cui si deve tenere conto per far funzionare bene le cose...