Ubuntustudio. con dos kernels, preempt y rt : GNU/Linux

Solo una curiosidad.Llevo dias trabajandome este hilo instrumentos-muestreados-para-gnu-linux-t146166.html con las valiosas aportaciones de los moderadores no oficiales.Al iniciar el grub, con la instalacion de ubuntustudio , me instalo un kernel-prempt y otro kernel-rt.
Tengo instalado ubuntu 10.10 y ubuntu studio.Al arrancar con ubuntu studio, me carga el kernel-preempt, si inicio el sistema con el kernel-rt, intenta arrancar ubuntu 10.10 , pero se queda todo bloqueado una vez a cargado el desktop gnome.No es un problema, solo una reflexion.Al instalar el ubuntustudio me instalo un kernel-preempt y otro kernel-rt.
salud

Hola

No entiendo bien el problema. Tienes dos sistemas en dos particiones diferentes, supongo, un ubuntu 10.10 y un ubuntustudio, qué versión? Si en US tienes dos kernels instalados, cómo puede ser que que al arrancar con uno de sus kernels te arranque el otro sistema, que está en la otra parción (si es que estoy suponiendo bien...). Otra cosa es que haya algún problema de integración del driver de la gráfica y el kernel rt.

Saludos, Pablo

Hola pablo!.Primero instale ubuntu 10.04 en tras particiones primarias.mas tarde hice un upgrade a 10.10.En la particion que me queda, instale ubuntustudio, en tres particiones logicas.Al instalar ubuntustudio, veo que ma instalado dos kernels, uno "preempt" y el otro un "rt"
Perdon por el tocho:

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Ubuntu, amb Linux 2.6.32-25-preempt' --class ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod ext2
set root='(hd0,5)'
search --no-floppy --fs-uuid --set 7eae51a4-d239-475e-b87e-fd35f19d2bf5
linux /boot/vmlinuz-2.6.32-25-preempt root=UUID=7eae51a4-d239-475e-b87e-fd35f19d2bf5 ro quiet splash
initrd /boot/initrd.img-2.6.32-25-preempt
}
menuentry 'Ubuntu, amb Linux 2.6.32-25-preempt (mode de restabliment)' --class ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod ext2
set root='(hd0,5)'
search --no-floppy --fs-uuid --set 7eae51a4-d239-475e-b87e-fd35f19d2bf5
echo 'Carregant Linux 2.6.32-25-preempt ...'
linux /boot/vmlinuz-2.6.32-25-preempt root=UUID=7eae51a4-d239-475e-b87e-fd35f19d2bf5 ro single
echo 'S'\''està carregant la ramdisk inicial ...'
initrd /boot/initrd.img-2.6.32-25-preempt
}
menuentry 'Ubuntu, amb Linux 2.6.32-21-preempt' --class ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod ext2
set root='(hd0,5)'
search --no-floppy --fs-uuid --set 7eae51a4-d239-475e-b87e-fd35f19d2bf5
linux /boot/vmlinuz-2.6.32-21-preempt root=UUID=7eae51a4-d239-475e-b87e-fd35f19d2bf5 ro quiet splash
initrd /boot/initrd.img-2.6.32-21-preempt
}
menuentry 'Ubuntu, amb Linux 2.6.32-21-preempt (mode de restabliment)' --class ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod ext2
set root='(hd0,5)'
search --no-floppy --fs-uuid --set 7eae51a4-d239-475e-b87e-fd35f19d2bf5
echo 'Carregant Linux 2.6.32-21-preempt ...'
linux /boot/vmlinuz-2.6.32-21-preempt root=UUID=7eae51a4-d239-475e-b87e-fd35f19d2bf5 ro single
echo 'S'\''està carregant la ramdisk inicial ...'
initrd /boot/initrd.img-2.6.32-21-preempt
}
### END /etc/grub.d/10_linux ###

### BEGIN /etc/grub.d/20_memtest86+ ###
menuentry "Memory test (memtest86+)" {
insmod ext2
set root='(hd0,5)'
search --no-floppy --fs-uuid --set 7eae51a4-d239-475e-b87e-fd35f19d2bf5
linux16 /boot/memtest86+.bin
}
menuentry "Memory test (memtest86+, serial console 115200)" {
insmod ext2
set root='(hd0,5)'
search --no-floppy --fs-uuid --set 7eae51a4-d239-475e-b87e-fd35f19d2bf5
linux16 /boot/memtest86+.bin console=ttyS0,115200n8
}
### END /etc/grub.d/20_memtest86+ ###

### BEGIN /etc/grub.d/30_os-prober ###
menuentry "Ubuntu, with Linux 2.6.35-22-generic-pae (on /dev/sda1)" {
insmod ext2
set root='(hd0,1)'
search --no-floppy --fs-uuid --set cde0645a-0e77-42ff-aa68-02fd1c9ed9ed
linux /boot/vmlinuz-2.6.35-22-generic-pae root=UUID=cde0645a-0e77-42ff-aa68-02fd1c9ed9ed ro quiet splash
initrd /boot/initrd.img-2.6.35-22-generic-pae
}
menuentry "Ubuntu, with Linux 2.6.35-22-generic-pae (recovery mode) (on /dev/sda1)" {
insmod ext2
set root='(hd0,1)'
search --no-floppy --fs-uuid --set cde0645a-0e77-42ff-aa68-02fd1c9ed9ed
linux /boot/vmlinuz-2.6.35-22-generic-pae root=UUID=cde0645a-0e77-42ff-aa68-02fd1c9ed9ed ro single
initrd /boot/initrd.img-2.6.35-22-generic-pae
}
menuentry "Ubuntu, with Linux 2.6.32-25-generic-pae (on /dev/sda1)" {
insmod ext2
set root='(hd0,1)'
search --no-floppy --fs-uuid --set cde0645a-0e77-42ff-aa68-02fd1c9ed9ed
linux /boot/vmlinuz-2.6.32-25-generic-pae root=UUID=cde0645a-0e77-42ff-aa68-02fd1c9ed9ed ro quiet splash
initrd /boot/initrd.img-2.6.32-25-generic-pae
}
menuentry "Ubuntu, with Linux 2.6.32-25-generic-pae (recovery mode) (on /dev/sda1)" {
insmod ext2
set root='(hd0,1)'
search --no-floppy --fs-uuid --set cde0645a-0e77-42ff-aa68-02fd1c9ed9ed
linux /boot/vmlinuz-2.6.32-25-generic-pae root=UUID=cde0645a-0e77-42ff-aa68-02fd1c9ed9ed ro single
initrd /boot/initrd.img-2.6.32-25-generic-pae
}
menuentry "Ubuntu, with Linux 2.6.32-25-generic (on /dev/sda1)" {
insmod ext2
set root='(hd0,1)'
search --no-floppy --fs-uuid --set cde0645a-0e77-42ff-aa68-02fd1c9ed9ed
linux /boot/vmlinuz-2.6.32-25-generic root=UUID=cde0645a-0e77-42ff-aa68-02fd1c9ed9ed ro quiet splash
initrd /boot/initrd.img-2.6.32-25-generic
}
menuentry "Ubuntu, with Linux 2.6.32-25-generic (recovery mode) (on /dev/sda1)" {
insmod ext2
set root='(hd0,1)'
search --no-floppy --fs-uuid --set cde0645a-0e77-42ff-aa68-02fd1c9ed9ed
linux /boot/vmlinuz-2.6.32-25-generic root=UUID=cde0645a-0e77-42ff-aa68-02fd1c9ed9ed ro single
initrd /boot/initrd.img-2.6.32-25-generic
}
menuentry "Ubuntu, with Linux 2.6.31-11-rt (on /dev/sda1)" {
insmod ext2
set root='(hd0,1)'
search --no-floppy --fs-uuid --set cde0645a-0e77-42ff-aa68-02fd1c9ed9ed
linux /boot/vmlinuz-2.6.31-11-rt root=UUID=cde0645a-0e77-42ff-aa68-02fd1c9ed9ed ro quiet splash
initrd /boot/initrd.img-2.6.31-11-rt
}
menuentry "Ubuntu, with Linux 2.6.31-11-rt (recovery mode) (on /dev/sda1)" {
insmod ext2
set root='(hd0,1)'
search --no-floppy --fs-uuid --set cde0645a-0e77-42ff-aa68-02fd1c9ed9ed
linux /boot/vmlinuz-2.6.31-11-rt root=UUID=cde0645a-0e77-42ff-aa68-02fd1c9ed9ed ro single
initrd /boot/initrd.img-2.6.31-11-rt
}
### END /etc/grub.d/30_os-prober ###
Si arranco el kernel preempt, me carga ubuntustudio, y todo anda bien, si cargo el kernel-rt intenta montarme ubuntu 10.10, pero una vez a cargado el escritorio de gnome se queda todo bloqueado.
No hay ningun problema, solo la curisidad que al instalar ubuntustudio 10.04, me instalo dos kernels, el "preempt" que para mi es nuevo, y el kernel-rt.
Queria hacer limpieza de kernels, y al examinar el grub me encuentro con esta sorpresa.Lo dejo tal como esta, ahora anda bien.Pablo no es que sea un problema,pero como veo que aparte del kernel "rt" , hay orto kernel "preempt"....en fin que dios no bendiga, pelillos a la mar y hacer buena musica con gnu/linux.
salud

¡No me acordaba! (Lo de que ibas a instalar ubuntustudio en una partición de pruebas). Lo has hecho bien, lo que pasa que ahora tienes un pequeño lío, pero no es nada grave. Poco a poco lo arreglarás.

Así se entiende mejor:

menuentry 'Ubuntu, amb Linux 2.6.32-25-preempt'

set root='(hd0,5)'



menuentry 'Ubuntu, amb Linux 2.6.32-25-preempt (mode de restabliment)'

set root='(hd0,5)'



menuentry 'Ubuntu, amb Linux 2.6.32-21-preempt'

set root='(hd0,5)'



menuentry 'Ubuntu, amb Linux 2.6.32-21-preempt (mode de restabliment)'

set root='(hd0,5)'



menuentry "Memory test (memtest86+)"

set root='(hd0,5)'



menuentry "Memory test (memtest86+, serial console 115200)"

set root='(hd0,5)'



menuentry "Ubuntu, with Linux 2.6.35-22-generic-pae (on /dev/sda1)" {

set root='(hd0,1)'



menuentry "Ubuntu, with Linux 2.6.35-22-generic-pae (recovery mode) (on /dev/sda1)"

set root='(hd0,1)'



menuentry "Ubuntu, with Linux 2.6.32-25-generic-pae (on /dev/sda1)" {

set root='(hd0,1)'



menuentry "Ubuntu, with Linux 2.6.32-25-generic-pae (recovery mode) (on /dev/sda1)"

set root='(hd0,1)'



menuentry "Ubuntu, with Linux 2.6.32-25-generic (on /dev/sda1)"

set root='(hd0,1)'



menuentry "Ubuntu, with Linux 2.6.32-25-generic (recovery mode) (on /dev/sda1)"

set root='(hd0,1)'



menuentry "Ubuntu, with Linux 2.6.31-11-rt (on /dev/sda1)"

set root='(hd0,1)'



menuentry "Ubuntu, with Linux 2.6.31-11-rt (recovery mode) (on /dev/sda1)"

set root='(hd0,1)'

Desde luego, no eres el típico linuxero ordenado sino igualito que yo

Pero como comentas, es mejor que disfrutes con la música y no te obsesiones con intentar saberlo todo, porque no acabas nunca.

Edito otra vez:
No sé cómo ha podido ocurrir esto. Es un menu list muy raro. No lo entiendo pero creo que hace que te ocurra lo que comentas, que es lo más raro que he leído últimamente. Si te gusta el SO apúntate a unas clases y si te gusta la música, no te preocupes mucho por el SO. En cualquier Linux moderno puedes hacer algo de música. Nunca puedes pretender lo mejor desde el principio.

Saludos, Pablo

Hola otra vez,

Fíjate en tu menú de grub:

ubuntustudio 10.04 que instalaste en /dev/sda5 (que grub conoce como hd0, 5) no instaló dos kernel, instaló sólo el preempt (2.6.32-21-preempt) al cual posteriormente le has hecho una actualización (2.6.32-25-preempt).

En /dev/sda1 (hd0, 1) tenías instalado el 2.6.31-11-rt, el 2.6.32-25-generic y el 2.6.32-25-generic-pae. Posteriormente has hecho una actualización a Maverick, en la que has instalado el 2.6.35-22-generic-pae.

Y ahora, a disfrutar.

Saludos, Pablo

gracias pablo.Me chuta el rosegarden de cojones, y con el banco de crisismidi. Voy a dejar por un tiempo el toquetear las tripas del ordenata. y dedicarme un poco a la musica, que con gnu/linux se puede y es de todos.
salud y alegria.

Bueno, esto no tiene mucho que ver con el post, pero, cual es la diferencia entre el preempt y el rt??

Hola DosSantos,

En la terminología de ubuntu:

https://help.ubuntu.com/community/Ubunt ... TimeKernel

-preempt kernel - Está basado en las mismas fuentes del kernel generic pero está compilado con una configuración diferente para reducir la latencia. Es un kernel "soft-realtime".

-rt kernel - Está basado en las mismas fuentes que el kernel generic pero antes de compilar le aplican el parche PREEMPT_RT de Ingo Molnar. Es un kernel "hard real-time".

https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO

Que yo sepa, los kernel hard realtime (no sólo los basados en Linux) se utilizan para control de máquina herramienta, en la industria militar :secreto:

... y también en algunos casos son útiles para el trabajo con audio.

http://en.wikipedia.org/wiki/Real-time_operating_system

Saludos, Pablo

-preempt kernel - Está basado en las mismas fuentes del kernel generic pero está compilado con una configuración diferente para reducir la latencia. Es un kernel "soft-realtime".

-rt kernel - Está basado en las mismas fuentes que el kernel generic pero antes de compilar le aplican el parche PREEMPT_RT de Ingo Molnar. Es un kernel "hard real-time".

Que yo sepa, los kernel hard realtime (no sólo los basados en Linux) se utilizan para control de máquina herramienta, en la industria militar :secreto:

... y también en algunos casos son útiles para el trabajo con audio.

hola Pablo!
* no solo al compañero DosSantos le sirvió esta señora aclaración. Me aclaro lo que citabas en otra entrada (kernel-rt trabajan mas cerca del hardware). Gracias.
* sobre que: "..en algunos casos son útiles para el tabajo con audio" -> naaaaaaa, esa data me voló la peluca. Oportuno y discreto
Saludos.

Hola,

No sé si es correcto decir que el kernel rt trabaja más cerca del hardware, ¿Yo dije eso? Es posible, a veces meto la pata.

Aquí el compañero Luis hizo un artículo titulado "Introducción al kernel rt" que explica muy bien la idea:

introduccion-kernel-t276319.html

Lo malo del kernel rt es que tiende a ser más inestable (aunque en mi caso va de perlas) sobretodo cuando hemos compilado drivers privativos. Pero todo depende del uso que le vayamos a dar al ordenador y también por supuesto, del hardware. En general, instalar un kernel rt (y menos compilarlo) no es la optimización más importante, ni por donde un principiante debería empezar, en mi opinión.

Sin embargo en algunos casos, es necesario dar prioridad a algunos kernel threads que comparten número de IRQ con otras piezas de hardware. Por lo que leo en los foros, hay gente con tarjetas firewire que sin el kernel rt y sin subir las prioridades con el script rtirq de Rui Nuno Capela, le va bastante mal. Pero cada caso es diferente.

Saludos, Pablo

Todo esto se encuadra en un entorno multitarea, donde un proveedor, o conjunto de proveedores en caso de sistemas multiprocesador o multinúcleo, trata de atender a un cierto número de clientes.

A ver, otro ejemplo: un cajero de supermercado cobrando a varios clientes.

Solo que este cajero está estudiado informática y en vez de el clásico sistema de cola FIFO (first in, first out) el cajero decide implementar un sistema de tiempo compartido (round-robin).

Cuando llega un cliente el cajero le pasa 5 artículos. Si el cliente tiene más artículos y hay otros clientes esperando, el cajero lo manda al final de la cola con los artículos restantes.

Evidentemente este sistema no tiene más rendimiento entendido como el tiempo que se tarda en atender todas las necesidades de todos los clientes, porque hay que perder tiempo en los cambios de cliente.

Pero es más interactivo, es decir, tiene menos latencia promedio, definiendo latencia como el tiempo que el sistema tarda en atender al menos parte de tus necesidades.

¿Es mejor o peor este sistema? Como siempre en ingeniería, la respuesta es: depende de qué es lo que estemos intentando optimizar. Evidentemente este sistema es peor para clientes de carro y mejor para clientes de cesta.

Pero la cosa se complica: la tienda tiene clientes VIP. Los clientes VIP siempre que llegan a la cola se ponen delante de los clientes normales, y sólo hacen round-robin si hay otros clientes VIP. Si no, monopolizan la caja hasta que terminan.

Además, si un cliente VIP llega y hay un cliente normal a medias, pongamos que solo ha pasado dos artículos, se le echa de la caja aunque no haya terminado la parte de atención que le correspondía. A esto se le llama desalojo (preemption).

¿Esto es bueno o es malo? Depende de lo importante que sea tener a los clientes VIP contentos a costa de fastidiar a los demás.

La diferencia entre un kernel normal, un kernel preempt y un kernel rt está en lo agresiva que es su política de desalojo o preemption. Cuando estamos sirviendo a un cliente normal y llega un cliente VIP, ¿qué hace el cajero? ¿Termina de pasar los 5 artículos que le corresponden al cliente normal? ¿Termina por lo menos de pasar el artículo que tiene en la mano?

Un kernel rt es tremendamente agresivo, que trata al cliente VIP como si fuera el Papa y desprecia a todos los demás. Además tiene mecanismos de verificación de que una tarea se ha cumplido en plazo.

En sistemas de control industrial cuando un sistema RT no cumple plazos se levanta una alerta porque se considera catastrófico y que el sistema está mal dimensionado (tiene poca potencia para la tarea que se le encomienda). Como un xrun, pero a lo bestia, por las consecuencias tan graves de seguridad o económicas que puede tener.

El problema de un kernel rt es que baja el rendimiento de la máquina para tareas no interactivas (por ejemplo, tareas de cálculo pesado como aplicarle un filtro a una imagen, a no ser que le subas la prioridad y entonces no puedas ni mover el ratón hasta que termine) y que abre más posibilidades para que una tarea de alta prioridad cuelgue la máquina si es maliciosa o tiene algún bug.

Todos los kernels por definición están cerca del hardware, es su función. Aunque el tema de la planificación de tareas o scheduling es más una cuestión de software.

Lo que pasa es que parte del software son los drivers del hardware. La baja latencia, o respuesta rápida a tareas cortas, en realidad sólo (sí, sólo con tilde diacrítica, diga lo que diga la RAE) tiene sentido cuando hay periféricos implicados, bien sea de interfaz hombre-maquina o sistemas de control industrial.

Pero otro tipo de kernel para otras aplicaciones puede prestar más atención a otros elementos del hardware, como el mejor aprovechamiento de la CPU, el disco duro o la conexión de red para tareas que no son interactivas. Recordemos que bajar la latencia tiene un coste en rendimiento.

Para lo que nos interesa a nosotros, que es el audio: ¿kernel rt o no?

En mi experiencia personal sólo lo he encontrado interesante en dos casos que necesitan latencia ultra-baja, pero posiblemente haya más con los que no me he topado:

1) Para modificar el sonido en tiempo real con mucha precisión, por ejemplo cuando tocas con un teclado MIDI un instrumento virtual. A lo mejor para mover un fader de volumen no hace falta una respuesta tan rápida.

2) Para monitorizar una grabación en tiempo real, por ejemplo si estás grabando una pista mientras escuchas por los cascos otras partes pregrabadas. Incluso en este caso, si el software de grabación tiene compensación de latencia no necesitas una latencia muy baja: durante la grabación el nuevo segmento irá siempre por detrás, pero al pulsar el botón de 'stop' el programa le da un empujoncito para que se alinee con el resto.

También es cierto que disminuye la posibilidad de que haya clicks (xruns) durante una grabación o reproducción, especialmente si estamos haciendo alguna otra tarea al mismo tiempo, como navegar por internet o si salta alguna tarea cron tipo updatedb o prelink, aunque éstas suelen ejecutarse a la prioridad más baja.