Old:Low-latency 2.6 kernel per applicazioni audio realtime: differenze tra le versioni
(completato) |
m (aggiunti link) |
||
| Riga 1: | Riga 1: | ||
== Introduzione == | == Introduzione == | ||
Questa | Questa è una breve guida su come patchare un kernel 2.6 con la patch realtime-preemption di Ingo Molnar per ottenere un kernel a bassa latenza. | ||
Il kernel 2.6 ha raggiunto ormai delle prestazioni molto buone per quanto riguarda la latenza. Normalmente non | Il kernel 2.6 ha raggiunto ormai delle prestazioni molto buone per quanto riguarda la latenza. Normalmente non è necessario usare nessuna patch aggiuntiva. Se però si vogliono raggiungere prestazioni estreme (come lavorare in full-duplex su diverse tracce a latenze inferiori a ~ 5 ms) è necessario usare la patch realtime-preemption. | ||
Per chi non conoscesse il mondo dell'audio professionale su GNU/Linux consiglio questo magnifico sito introduttivo: | Per chi non conoscesse il mondo dell'audio professionale su GNU/Linux consiglio questo magnifico sito introduttivo: | ||
| Riga 11: | Riga 10: | ||
In questo ambiente le patch e i kernel evolvono rapidamente. Non posso che descrivere il processo che ho usato con il kernel e la patch attuale (che a me hanno dato ottimi risultati), sapendo che le versioni di kernel e patch citate diventeranno presto obsolete. | In questo ambiente le patch e i kernel evolvono rapidamente. Non posso che descrivere il processo che ho usato con il kernel e la patch attuale (che a me hanno dato ottimi risultati), sapendo che le versioni di kernel e patch citate diventeranno presto obsolete. | ||
{{Warningbox|Se non siete a vostro completo agio a compilare e patchare il kernel questa non | {{Warningbox|Se non siete a vostro completo agio a compilare e patchare il kernel questa non è la via che fa per voi. Consiglio in tal caso si usare il [http://demudi.agnula.org/packages/demudi/pool/main/demudi/ kernel multimediale di DeMuDi]. Se voltete poi un setup per l'audio professionale pronto per l'uso installate l'ottima [http://demudi.agnula.org/ distribuzione DeMuDi] (è una [http://wiki.debian.net/index.cgi?CustomDebian CDD]).}} | ||
== Dal kernel stabile all'RC == | == Dal kernel stabile all'RC == | ||
Consiglio di compilare l'ultima versione stabile del kernel, configurandola e testandola fino ad ottenere una configurazione ben funzionante. Come spunto potete usare [[Esempio configurazione kernel|questa configurazione]]. Nel mio caso ho usato il [ftp://ftp.it.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.14-rc3.tar.bz2 kernel 2.6.13.2] e la [[Debian Kernel Howto|debian-way]] di compilare il kernel. | Consiglio di compilare l'ultima versione stabile del kernel, configurandola e testandola fino ad ottenere una configurazione ben funzionante. Come spunto potete usare [[Esempio configurazione kernel|questa configurazione]]. Nel mio caso ho usato il [ftp://ftp.it.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.14-rc3.tar.bz2 kernel 2.6.13.2] e la [[Debian Kernel Howto|debian-way]] di compilare il kernel. | ||
Attualmente le patch realtime-preemption si applicano (ufficialmente) ai soli kernel rc (Release Candidate). Quindi si | Attualmente le patch realtime-preemption si applicano (ufficialmente) ai soli kernel rc (Release Candidate). Quindi si dovrà scaricare e compilare un kernel rc. Nel momento un cui scrivo l'ultimo rc è il 2.6.14-rc3. Se si è precedentemente compilato un kernel stabile basta fare un make oldconfig per configurare le nuove voci. Questo metodo "a due passi" permette di separare i problemi dovuti ad un eventuale errore di configurazione del kernel stabile dai problemi potenzialmente introdotti dall'uso di un kernel non stabile rc. Per questo ho consigliato di testare prima il kernel stabile per verificare l'assenza di problemi. | ||
== La patch realtime-preemption == | == La patch realtime-preemption == | ||
L'archivio delle patch realtime-premption si trova [http://people.redhat.com/mingo/realtime-preempt/ qui]. La patch realtime-preemption da me usata e la rt2. La patch | L'archivio delle patch realtime-premption si trova [http://people.redhat.com/mingo/realtime-preempt/ qui]. La patch realtime-preemption da me usata e la rt2. La patch è un semplice file di testo. Il suo nome è del tipo <tt>patch-''<kernel version>''-''<patch version>''</tt>. Bisogna applicare la patch all'esatta versione del kernel indicata dal nome. Nel mio caso ho usato la [http://people.redhat.com/mingo/realtime-preempt/older/patch-2.6.14-rc2-rt2 versione rt2 applicata al kernel 2.6.14-rc3]. Dopo questa versione sono uscite molto rapidamente una serie di aggiornamenti (attualmente fino a rt8) ma mi è stato consigliato sulla lista [http://www.djcj.org/LAU/guide/index.php LAU] di continuare ad usare l'rt2 (almeno per alcuni giorni fino a quando la situazione non si stabilizza nuovamente). YMMV. | ||
Per applicare la patch basta copiarla in <tt>/usr/src</tt>, entrare della dir del kernel e lanciare il comando (nel mio esempio): | Per applicare la patch basta copiarla in <tt>/usr/src</tt>, entrare della dir del kernel e lanciare il comando (nel mio esempio): | ||
| Riga 25: | Riga 24: | ||
$ cat ../patch-2.6.14-rc3-rt2 |patch -p1 -t | $ cat ../patch-2.6.14-rc3-rt2 |patch -p1 -t | ||
A questo punto nuovamente un make oldconfg ci | A questo punto nuovamente un make oldconfg ci permetterà di configurare le voci inserite dalla patch. Assicurarsi di scegliere '''Complete Preemption (Real-Time)''' in: | ||
<pre> | <pre> | ||
| Riga 42: | Riga 41: | ||
== Il modulo realtime-lsm == | == Il modulo realtime-lsm == | ||
Per usare il server audio jack in realtime da utente normale | Per usare il server audio jack in realtime da utente normale è inoltre necessario compilare il modulo realtime-lsm. Su debian è semplicissimo, basta installare il pacchetto realtime-lsm-source e usare <tt>[[Pagina di manuale di module-assistant|module-assistant]]</tt> per compilare e pacchettizzare il modulo. Facciamo puntare il link simbolico <tt>/usr/src/linux</tt> alla directory dei sorgenti del kernel patchato ed eseguiamo: | ||
$ m-a build realtime-lsm | $ m-a build realtime-lsm | ||
| Riga 48: | Riga 47: | ||
A questo punto non ci resta che installare il pacchetto realtime-lsm creato. | A questo punto non ci resta che installare il pacchetto realtime-lsm creato. | ||
L'uso di questo modulo non richiede alcuna patch al kernel ed | L'uso di questo modulo non richiede alcuna patch al kernel ed è usabilissimo anche con un normale kernel vanilla. | ||
Questo modulo non | Questo modulo non è mai stato accettato nel tree ufficilae del kernel per i potenziali problemi di sicurezza legati al fatto di dare i privileggi realtime ai processi dei singoli utenti. E' già presente nel kernel un nuovo meccanismo più sicuro per concedere i privileggi di realtime chiamato rlimits che sostituirà il modulo realtime-lsm. Tuttavia si dovrà aspettare che gli rlimits vengano inclusi nelle distribuzioni dato che è richiesto l'impiego di libc che li supporti. Attualmente, un metodo per usare gli rlimits senza cambaire libc, è quello di patchare PAM. Personalmente non ho ancora provato questa alternativa. | ||
== Conlusioni == | == Conlusioni == | ||
Con un kernel | Con un kernel così ottimizzato si raggiungono prestazioni realtime davvero spinte. Io ad esempio, con una modestissima SB Audigy 1 posso fare partire jack a 32 frame x 2 periodi @ 48000Hz (latenza 1.3 ms!) in modalità solo playback. Qualche xrun avviene ancora a latenze così basse se si eseguono altre operazioni sulla macchina. Per avere la massima affidabilità in full-duplex utilizzo usualmente jack a 128x2 @ 48000Hz. | ||
In bocca al lupo e... | In bocca al lupo e... | ||
Happy Debian! | Happy Debian! | ||
== Links == | |||
* http://www.emillo.net/home | |||
* http://www.djcj.org/LAU/guide/index.php | |||
* http://tapas.affenbande.org/?page_id=3 | |||
---- | ---- | ||
Autore: [[Utente:TheNoise|~ The Noise]] | Autore: [[Utente:TheNoise|~ The Noise]] | ||
Versione delle 13:36, 5 ott 2005
Introduzione
Questa è una breve guida su come patchare un kernel 2.6 con la patch realtime-preemption di Ingo Molnar per ottenere un kernel a bassa latenza.
Il kernel 2.6 ha raggiunto ormai delle prestazioni molto buone per quanto riguarda la latenza. Normalmente non è necessario usare nessuna patch aggiuntiva. Se però si vogliono raggiungere prestazioni estreme (come lavorare in full-duplex su diverse tracce a latenze inferiori a ~ 5 ms) è necessario usare la patch realtime-preemption.
Per chi non conoscesse il mondo dell'audio professionale su GNU/Linux consiglio questo magnifico sito introduttivo:
In questo ambiente le patch e i kernel evolvono rapidamente. Non posso che descrivere il processo che ho usato con il kernel e la patch attuale (che a me hanno dato ottimi risultati), sapendo che le versioni di kernel e patch citate diventeranno presto obsolete.
|
ATTENZIONE Se non siete a vostro completo agio a compilare e patchare il kernel questa non è la via che fa per voi. Consiglio in tal caso si usare il kernel multimediale di DeMuDi. Se voltete poi un setup per l'audio professionale pronto per l'uso installate l'ottima distribuzione DeMuDi (è una CDD). |
Dal kernel stabile all'RC
Consiglio di compilare l'ultima versione stabile del kernel, configurandola e testandola fino ad ottenere una configurazione ben funzionante. Come spunto potete usare questa configurazione. Nel mio caso ho usato il kernel 2.6.13.2 e la debian-way di compilare il kernel.
Attualmente le patch realtime-preemption si applicano (ufficialmente) ai soli kernel rc (Release Candidate). Quindi si dovrà scaricare e compilare un kernel rc. Nel momento un cui scrivo l'ultimo rc è il 2.6.14-rc3. Se si è precedentemente compilato un kernel stabile basta fare un make oldconfig per configurare le nuove voci. Questo metodo "a due passi" permette di separare i problemi dovuti ad un eventuale errore di configurazione del kernel stabile dai problemi potenzialmente introdotti dall'uso di un kernel non stabile rc. Per questo ho consigliato di testare prima il kernel stabile per verificare l'assenza di problemi.
La patch realtime-preemption
L'archivio delle patch realtime-premption si trova qui. La patch realtime-preemption da me usata e la rt2. La patch è un semplice file di testo. Il suo nome è del tipo patch-<kernel version>-<patch version>. Bisogna applicare la patch all'esatta versione del kernel indicata dal nome. Nel mio caso ho usato la versione rt2 applicata al kernel 2.6.14-rc3. Dopo questa versione sono uscite molto rapidamente una serie di aggiornamenti (attualmente fino a rt8) ma mi è stato consigliato sulla lista LAU di continuare ad usare l'rt2 (almeno per alcuni giorni fino a quando la situazione non si stabilizza nuovamente). YMMV.
Per applicare la patch basta copiarla in /usr/src, entrare della dir del kernel e lanciare il comando (nel mio esempio):
$ cat ../patch-2.6.14-rc3-rt2 |patch -p1 -t
A questo punto nuovamente un make oldconfg ci permetterà di configurare le voci inserite dalla patch. Assicurarsi di scegliere Complete Preemption (Real-Time) in:
Processor type and features ---> Preemption Mode (Complete Preemption (Real-Time))
per il resto ho lasciato quasi tutte le altre voci al valore di default.
Non ci resta che compilare il kernel:
$ fakeroot make-kpkg --append-to-version -realtime --revision 0.1 kernel_image
ed installare il pacchetto.
Il modulo realtime-lsm
Per usare il server audio jack in realtime da utente normale è inoltre necessario compilare il modulo realtime-lsm. Su debian è semplicissimo, basta installare il pacchetto realtime-lsm-source e usare module-assistant per compilare e pacchettizzare il modulo. Facciamo puntare il link simbolico /usr/src/linux alla directory dei sorgenti del kernel patchato ed eseguiamo:
$ m-a build realtime-lsm
A questo punto non ci resta che installare il pacchetto realtime-lsm creato.
L'uso di questo modulo non richiede alcuna patch al kernel ed è usabilissimo anche con un normale kernel vanilla.
Questo modulo non è mai stato accettato nel tree ufficilae del kernel per i potenziali problemi di sicurezza legati al fatto di dare i privileggi realtime ai processi dei singoli utenti. E' già presente nel kernel un nuovo meccanismo più sicuro per concedere i privileggi di realtime chiamato rlimits che sostituirà il modulo realtime-lsm. Tuttavia si dovrà aspettare che gli rlimits vengano inclusi nelle distribuzioni dato che è richiesto l'impiego di libc che li supporti. Attualmente, un metodo per usare gli rlimits senza cambaire libc, è quello di patchare PAM. Personalmente non ho ancora provato questa alternativa.
Conlusioni
Con un kernel così ottimizzato si raggiungono prestazioni realtime davvero spinte. Io ad esempio, con una modestissima SB Audigy 1 posso fare partire jack a 32 frame x 2 periodi @ 48000Hz (latenza 1.3 ms!) in modalità solo playback. Qualche xrun avviene ancora a latenze così basse se si eseguono altre operazioni sulla macchina. Per avere la massima affidabilità in full-duplex utilizzo usualmente jack a 128x2 @ 48000Hz.
In bocca al lupo e...
Happy Debian!
Links
- http://www.emillo.net/home
- http://www.djcj.org/LAU/guide/index.php
- http://tapas.affenbande.org/?page_id=3
Autore: ~ The Noise