Un paio di considerazioni a proposito di
scheduling e "
real-time".
La prima e più importante è che, di solito, per default soltanto "root" ha i privilegi necessari per poter assegnare uno scheduling di tipo "real-time" ad uno o più processi/threads. Il motivo di ciò risulta evidente se si ha presente che cosa ciò significhi in realtà. Dato che forse non tutti lo sanno, spendo due parole per provare a spiegarlo in modo semplice.
Oggi siamo talmente abituati ad avere a che fare con sistemi "multitasking" che diamo praticamente per scontato che un computer sia in grado di svolgere un gran numero di compiti diversi "contemporaneamente". Perciò tendiamo a dimenticare che, in realtà, un computer è un sistema strettamente
sequenziale, che cioè fa una sola cosa alla volta, una dopo l'altra, in sequenza (nei sistemi moderni ci può essere un certo grado di parallelismo effettivo grazie alla presenza di sottosistemi hardware ridondanti, ma la sostanza non cambia). Che i diversi compiti siano svolti "contemporaneamente" è fondamentalmente una illusione, dovuta al fatto che il sistema (per la precisione lo
scheduler, che è uno degli elementi essenziali del
kernel) interrompe continuamente l'esecuzione del "task" in corso per eseguirne un altro e così via, in rapida successione (ed ovviamente fa altrettanto anche per poter eseguire sé stesso!). Se la cosa avviene in modo sufficientemente veloce (rispetto alle esigenze specifiche dei compiti che sta svolgendo), agli effetti pratici è come se i vari compiti fossero effettivamente svolti "in parallelo".
È proprio nello scheduler, ovvero nel modo in cui questo decide quando sospendere l'esecuzione di un task per passare ad un altro (ed a quale altro passare), che risiede la differenza tra un sistema "real-time" ed uno che non lo è.
In breve, la differenza sostanziale consiste unicamente nel tempo di attesa tra l'interruzione di un "task" e la sua successiva riattivazione. In generale, tale tempo di attesa è
casuale (dipende dalla velocità e dal "carico" del sistema, ecc) ma, in un sistema real-time, il massimo tempo di attesa deve essere
deterministico. Cioè, in ogni caso, un dato task che ha "priorità" real-time deve tornare ad essere eseguito al più
entro un tempo massimo prefissato.
Ovviamente, dato che le risorse del sistema sono finite, ciò non può che avvenire a spese degli altri task.
Ovvio quindi che, normalmente, in un sistema multiutente non si può permettere che un utente qualsiasi possa "monopolizzare" le risorse del sistema assegnando priorità real-time ad uno (o più) dei propri processi.
Perché un utente normale possa utilizzare la modalità real-time, è quindi necessario che questo (od uno dei gruppi di cui fa parte) sia debitamente autorizzato a farlo.
In caso contrario (a meno di non far girare mpd come utente root, cosa altamente sconsigliata!) utilizzare una versione di MPD con la patch "real-time" (con o senza un kernel "-rt") è perfettamente inutile, in quanto mpd verrà comunque eseguito con scheduling e priorità normali!
Per permettere l'esecuzione di MPD (o di qualsiasi altra cosa...) in modalità real-time, editate i files:
/etc/security/limits.conf
/etc/security/limits.d/audio.conf
ed assicuratevi che, in uno dei due (quale dei due è indifferente), sia presente quanto segue:
Codice: Seleziona tutto
@audio - rtprio 50
#@audio - memlock unlimited
@audio - memlock 1542192
#@audio - nice -19
@audio - nice -10
(in effetti, l'unica linea essenziale è quella relativa al parametro "rtprio". Al solito, quelle che iniziano con il carattere '#' sono inattive in quanto "commenti").
Il significato di tali impostazioni è il seguente:
#Each line describes a limit for a user in the form:
#
#<domain> <type> <item> <value>
#
#Where:
#<domain> can be:
# - an user name
# - a group name, with @group syntax
# [...]
#<item> can be one of the following:
# [...]
# - memlock - max locked-in-memory address space (KB)
# - nice - max nice priority allowed to raise to values: [-20, 19]
# - rtprio - max realtime priority
Una nota a proposito dei kernel "-rt": in realtà, ormai da molto tempo
tutti i kernel Linux "sono real-time", cioè hanno schedulers che supportano le modalità realtime (
RR e FIFO).
La differenza tra le attuali versioni "-rt" rispetto alle altre consiste essenzialmente nel fatto che i kernel "-rt" sono "
fully preemptible", cioè non solo i processi utente, ma anche quelli del kernel stesso possono essere interrotti in favore di un task che gira in modalità real-time (ciò in realtà può accadere anche per i kernel non rt, ma solo per un set più limitato di "task" del kernel stesso). Questo consente di raggiungere l'obbiettivo di ottenere un sistema "hard real-time", cioè con ritardi (latenza) massimi effettivamente (sempre) deterministici. Per contro, con un kernel "-rt" è molto più facile produrre malfunzionamenti o blocchi totali del sistema se si sbaglia ad assegnare scheduling e priorità ai vari task (servizi del kernel inclusi) oppure se c'è un bug in una delle applicazioni che gira in modalità real-time (o peggio nel kernel stesso).
https://rt.wiki.kernel.org/index.php/Fr ... _Questions
http://taipei.freedomhec.org/dlfile/RealTimeLinux.pdf
http://stackoverflow.com/questions/9374 ... g-in-linux
In altre parole, NON è necessario utilizzare un kernel "-RT" per far girare MPD in modalità real-time (sia pure "soft real-time", che di norma però dovrebbe essere più che sufficiente per i nostri scopi).
Parimenti, NON è strettamente necessario utilizzare una versione di MPD con la patch real-time per farlo girare in modalità real-time: per impostare modalità di scheduling e priorità di qualsiasi processo si può infatti utilizzare il comando "
chrt" oppure "
schedtool":
Il vantaggio principale della versione di MPD con la patch RT è che questa permette di controllare facilmente (attraverso il file di configurazione) la modalità di scheduling e la priorità dei vari sottoprocessi.
P.S.: consiglio di installare "
htop" (apt-get install htop) quale utile strumento per monitorare i processi (è un tool simile a "top", ma molto più completo).
P.P.S.: IMHO eviterei di dare ai processi utente (incluso quelli di mpd) priorità RT maggiore di quella dei task RT del kernel stesso (RT=50): la cosa rischia di creare problemi ed essere controproducente...
Inoltre, userei la modalità "RR" piuttosto che quella "FIFO".
Have fun!
Ciao, Paolo.
«Se tu hai una mela, e io ho una mela, e ce le scambiamo, tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»
) che ci facilita di molto il lavoro. Complimenti per il tuo sforzo di ricerca, davvero!
