Adiós al kernel "rt"

Hace poco lo leímos en la lista de correo de linux audio:

linux-2.6.39 with force threaded irq-handlers: our new rt-kernel

Adiós al parche PREEMP_RT, adiós a los "linux-rt". Lo he probado con el 2.6.39 rc3 en ubuntu natty beta. Sólo he tenido que editar una línea en /etc/default/grub:

GRUB_CMDLINE_LINUX="threadirqs"

Y funciona! rtirq-init funciona con el kernel genérico!

Saludos, Pablo

como usuario en gnu/linux no ducho en programacion c, espero larga vida a tango studio, amen.
yo todavia alucino, me miran raro en mis reflexiones, pero san google existe.... pablo es increible la comunidad linux, el sistema compartido creado. salud por las ganas de compartir...

Pablo_F escribió:

Adiós al parche PREEMP_RT, adiós a los "linux-rt".

Pablo F, pregunta... Entonces no en un futuro no se va atener que parchar el Kernel con el Patch RT, y todos los demás Kernels vendrán por default RT? o tendrán alguna especie de "switch" por demanda de uso.

O sea, que si Ardour ocupa extensiones RT, entonces el Kernel sabiamente asignara las extensiones adecuadas?

Si es así, ya no va a haber tanto desorden en el Grub, al tener que instalarse dos Kernels distintos, si usan distros como Debian o Ubuntu

Alguien escribió:

Entonces no en un futuro no se va atener que parchar el Kernel con el Patch RT, y todos los demás Kernels vendrán por default RT?

Eso es, ya no será necesario parchear el kernel o instalar un kernel parcheado precompilado. De hecho, el último parche PREEMP_RT es aplicable a 2.6.33. No existe para versiones posteriores. Y a partir de 2.6.39 deja de tener sentido porque toda su funcionalidad queda integrada en la línea principal del kernel.

Alguien escribió:

o tendrán alguna especie de "switch" por demanda de uso.

Seguirá siendo necesario configurar el script rtirq-init.



Recordar que con las versiones actuales del kernel, no siempre es necesario el parche PREEMP_RT. Depende de cada caso particular.

Por ejemplo, con una tarjeta firewire enchufada a una tarjeta ExpressCard donde el controlador de la tarjeta, el controlador firewire y quizás otros dispositivos comparten el mismo número de IRQ. En este caso, el kernel rt nos permite modificar la prioridad realtime de cada controlador por separado a través del comando "chrt -f -p prioridad pid", con lo cual evitamos xruns a baja latencia.

Para facilitarnos la vida, el script rtirq-init (disponible en los repos de debian / ubuntu y supongo que en otras distros) usa este comando de forma inteligente a partir de un archivo de configuración donde indicamos las prioridades del hardware que nos interesa (la tarjeta de audio, el controlador de la ExpressCard, el bus USB donde conectamos un disco duro que vamos a usar para nuestras grabaciones...).


Lo de los IRQ's y las prioridades realtime está explicado aquí:

http://subversion.ffado.org/wiki/IrqPriorities

Más información en castellano, aunque no se habla de rtirq-init:

http://www.soundebian.com.ar/2009/10/configurando-verdaderamente-el-real-time-para-audio/

Debate con el gran Rui sobre rtirq-init (el autor de rtirq-init, qsynth, qjackctl, qtractor, qmidinet...):

http://www.rncbc.org/drupal/node/107

Aquí otro resumen en castellano e ideas para configurar rtirq-init:

http://semicorchux.blogspot.com/2010/05/el-script-rtirq-en-ubuntustudio.html


La novedad es que todo esto funciona en el kernel 2.6.39 con sólo indicar el parámetro "irqthreads". Así que afirmaciones como:

rtirq-init only makes sense on a PREEMPT_RT patched kernel (a.k.a. realtime-preempt, Ingo Molnar's RT-patchset)... Otherwise it just does nothing.quote]

dejarán de tener validez en poco tiempo. Incluso si fue Rui quien lo dijo hace menos de tres años.


O sea, que si Ardour ocupa extensiones RT, entonces el Kernel sabiamente asignara las extensiones adecuadas?[/quote]

No, la prioridad realtime de ardour (al menos del thread de ardour que habla con jack), como buen cliente de jack, viene dada por jack. Eso ya se consigue ahora con un kernel genérico siempre que el usuario que lanza jack tenga prioridad de realtime (el famoso rtprio en limits.conf).

Saludos, Pablo

Gracias Pablo por la información aportada.

Saludos.

De nada Igny

Aclarar que, en lugar de "adiós al kernel rt", el título del post habría sido mejor "adiós al parche rt", o incluso "bienvenido kernel rt".

ostras es verdad!! con mi ubuntu 11.04 y con 2.6.38-8-generic.Tengo cargado el jack + Qsynth + crisis general midi3 + rosegarden y anda de putixxxa madre ...a ver , solo falta verlo currando con el musescore.
salud

No sé si a ustedes les pasa, pero a mi jack no me funciona bien con el kernel genérico y dependo del RT, incluso he tenido problemas de compatibilidad de algunos drivers (específicamente el fglrx) por usar un kernel tan antiguo.

Sé bien que esto es a partir del 2.6.39 (Todavía en desarrollo), pero ya desde el kernel 2.6.36 decían que el parche RT era prescindible para un buen rendimiento de las aplicaciones de audio. En mi caso no es así, jack inicia, pero después de un tiempo deja de sonar, y aparecen miles de xruns. Y programas pesados como Linuxsampler, ni siquiera abren.

Espero que esta noticia realmente implique que el parche RT deje de ser necesario.

A partir de 2.6.39 el parche RT dejará de ser necesario para el IRQ threading, gracias al cual podemos asignar una prioridad de realtime mayor para el hardware de audio incluso si comparte número de IRQ con otros dispositivos. La necesidad o no del IRQ threading depende de cada caso.

Otra cosa es que el kernel binario genérico que las distros principales ofrecen, incluso a partir de 2.6.39, sea el más adecuado para trabajo con audio, pues el kernel se puede configurar de mil maneras diferentes a la hora de compilarlo. El genérico se supone que es lo bastante bueno para el uso de Escritorio en el mayor número posible de configuraciones de hardware y no está especialmente optimizado para baja latencia (aunque puede ser usable). Sin embargo, hay kernels optimizados (los "low-latency") que parten del mismo código fuente.

Este kernel se instala de manera automatica en dsitros tradicionales (ubuntu, etc, etc)?

Todavía no. Acaba de salir del horno hace muy pocos días.

Eso sí, ya está disponible para Debian sid y supongo que también para Arch.

Ubuntu natty ha salido con un 2.6.38 y ya no lo va a incorporar en sus repos. Eso sí, ubuntu 11.10 (oneiric ocelot) ya vendrá con un >=2.6.39 (probablemente 40 ó 41). Fedora 15 sale mañana y vendrá con 2.6.38 también.

Yo probé un 2.6.39-rc para Natty que instalé desde este PPA:

https://launchpad.net/~kernel-ppa/+archive/ppa?field.series_filter=natty

Saludos, Pablo

Hola pablo! cuando nombras a "2.6.39-rc" la "c" que significa?.Acabo de añadir este repositorio que indicas , pero no se que paquete es exactamente.Claro yo busco en synaptic "kernel-rt" , pero me da tantas opciones que no se cual escoger.
gracias.

"rc" significa "release candidate" e indica que está (en este caso estaba) en la fase final del ciclo de desarrollo. No es el considerado estable pero está muy cerca y probablemente funcione igual para el uso que le damos nosotros (para empezar, el kernel soporta un montón de arquitecturas). Y por lo que veo, en ese PPA no han actualizado a la versión actual.

En Synaptic puedes clasificar los paquetes por origen, botón de abajo a la izquierda. Seleccionas el repositorio añadido y ahí lo verás.

También se puede intentar añadir el repositorio de Debian Sid. Supongo que estás intentando todo esto en un sistema de pruebas.

Saludos, Pablo

si pablo, mantego dos sistemas despues de una sugerencia tuya.Trabajo con tango studio, y luego voy mirando ubuntu 11.04, su nueva interficie, unity, y la verdad me aguanta bien la santisima trinidad "jack+Qsynth+rosegarden".., la unica pena es que musescore se cuelga muy a menudo.He estado mirando Lylipond, pero es demasiado para mi , el manejo de este editor, pero con paciencia a ver si me aclaro.
Gracias por la aclaracion.

Quería decir que es verdad.

Ya hice la prueba de fuego. Tenía corriendo unos 10 sintetizadores a la vez, y solo tuve un par de xruns por bristol arp2600.

Fuera de eso, el kernel 2.6.39 es en tiempo real sin parchar nada.