Utilizando un kernel RT (de baja latencia)

Miguel Mayol, gran seguidor y comentador de este blog, nos recomendó un artículo publicado en Hispasonic sobre la utilización de kernels RT, que hemos decidido publicar y ampliar en algunas de sus partes.

Los kernels RT permiten un óptimo rendimiento en algunas situaciones partículares, por ejemplo, la edición de audio o la utilización de instrumentos musicales virtuales.

Kernel multitarea

El kernel de Linux, como el de la mayoría de los sistemas operativos modernos, es multitarea. Eso quiere decir que se están ejecutando varios programas al mismo tiempo.

En realidad esto no ocurre exactamente así. Lo que se hace es poner los programas en una cola y, uno por uno, el microprocesador los ejecuta durante una cierta cantidad de tiempo. Una vez agotado éste el microprocesador interrumpe la tarea dejándola a medias y da paso a la siguiente. A esta cantidad de tiempo se le denomina quantum o time slice, y no tiene por qué ser constante.

Una buena analogía podría ser el cocinero de un bar preparando varios platos a la vez: un bocata de lomo, una de callos, una ensalada mixta… Ahora parto el pan, enciendo la sartén, mientras se calienta lavo la lechuga, etc.

Si el quantum es suficientemente pequeño la impresión subjetiva para un observador lento, como el ser humano, es de que en vez de un procesador rápido ejecutando tareas alternativamente tenemos un procesador lento para cada una ellas (varios cocineros en la misma cocina haciendo lentamente cada uno un solo plato).

La conmutación de tareas tiene un costo

La multitarea no es gratis: implica una sobrecarga del procesador. En efecto, desalojar una tarea y cargar la siguiente es un trabajo extra. Esta operación se denomina ‘cambio de contexto’ o ‘conmutación de tareas’. Sería más rentable en términos de CPU ejecutar los programas por completo, uno por uno, que partirlos en ‘rodajas’ e ir saltando de uno a otro. Sin embargo, el sistema perdería en interactividad, no podríamos tener varias ventanas abiertas o, en el caso de un servidor, atender a varias peticiones simultáneamente.

Latencia y rendimiento

Supongamos que nuestro cocinero tiene que pelar 20 kilos de gambas y deshuesar 20 kilos de aceitunas. ¿Cómo se planifica el trabajo?

En un caso extremo primero pelaría todas las gambas, se lavaría las manos para no mezclar sabores y después deshuesaría todas las aceitunas. Lo representaremos así:

GGGGGGGGGGGGGGGGGGGGGG… C AAAAAAAAAAAAAAAAAAAAAA…

En el extremo opuesto, pelaría una gamba, se lavaría las manos, deshuesaría una aceituna, se lavaría las manos… gamba, aceituna, gamba, aceituna… Lo representaremos así:

GCACGCACGCACGCACGCACGCACGCACGCACGCACGCACGCACGCACGCACGCACGCAC…

La ‘C’ representa el cambio de contexto: lavarse las manos, cambiar de utensilio…

Al mismo tiempo, un camarero recoge las peticiones de los clientes: «¡una de gambas!»… «¡una de aceitunas!»… y las translada a la cocina.

En el primer caso, supongamos que entra un cliente y pide una ración de gambas. No hay problema, enseguida se le sirve. Pero, ¿y si pide aceitunas? El camarero no podría servirla hasta que todas las gambas estuvieran peladas. En este caso la latencia, que es el tiempo que pasa desde que se hace una petición hasta que ésta es atendida, sería muy alta.

En el segundo caso, pida lo que pida el cliente, estará disponible en poco tiempo, además prácticamente igual en ambos casos. La latencia será baja, pero a un coste: debido a los cambios de contexto se producirá una disminución del rendimiento, entendido como la parte del tiempo durante el cuál la CPU está haciendo tareas directamente productivas, en lugar de labores de soporte.

Evidentemente en este caso la solución ideal sería un término medio, que dependería del tamaño de las raciones y de la distribución estadística de las peticiones. La teoría de colas es la rama de la matemática que se encarga de estudiar estas situaciones y de darles soluciones óptimas.

Como se puede ver, latencia y rendimiento son opuestos. Por esta razón no es correcto afirmar que los kernels rt dan más rendimiento. Todo lo contrario, al bajar la latencia empeoran el rendimiento de la máquina y, por lo tanto, son una elección pésima para sistemas que no necesiten respuestas superrápidas como, por ejemplo, servidores web o de bases de datos.

Por el contrario, los kernels de baja latencia son ideales en situaciones donde se necesite la máxima velocidad de respuesta a los estímulos externos, como sistemas de control industrial o aplicaciones multimedia interactivas, sabiendo que estamos sacrificando parte de la potencia de la máquina en garantizar esa rápida reacción.

Prioridades

Una opción interesante en sistemas multitarea es dar distintas prioridades a las tareas, de tal forma que las más importantes reciban más tiempo del procesador y las menos importantes menos. En un kernel normal esto se hace con el comando ‘nice’. Si nuestro cocinero espera servir más raciones de gambas que de aceitunas haría bien en dedicarle más tiempo a las primeras, lógicamente.

Kernel RT (o de baja latencia)

El problema de los kernel normales es que las tareas no se pueden interrumpir en cualquier sitio, hay que esperar a que lleguen a ciertos puntos de ejecución donde ya se pueden detener para conmutar a otra. Esto introduce lo que llamamos latencia.

Por ponerlo de una forma simplificada, los kernels RT permiten interrumpir las tareas en más cantidad de sitios que los kernel normales. Pueden hacer, por así decirlo, rodajas más finas de tiempo, así que la tarea actual será desalojada más rápidamente y nuestra tarea prioritaria podrá acceder antes a la CPU. Por lo tanto la latencia será más baja.

Digamos que un kernel RT nos permite dejar una gamba a medio pelar si lo que se necesita en ese momento, urgentemente, es ponerse a deshuesar una aceituna lo antes posible, mientras que en un kernel normal habría que terminar de pelar la gamba.

Además de hacer rodajas más finas, los kernels RT tienen un sistema de prioridades mucho más estricto, donde las tareas prioritarias pegan hachazos inmisericordes a las demás (preempting) para hacerse con el control de la CPU, ralentizando los demás programas lo que sea necesario para cumplir con sus requisitos.

¿Cuándo es importante usar un Kernel RT?

En dos casos:

1) Cuando necesitamos latencias muy bajas, es decir, reacciones muy rápidas de la máquina. El ejemplo más claro es la ejecución de instrumentos virtuales, donde necesitas que al pulsar una tecla de un teclado MIDI el instrumento suene inmediatamente.

2) Cuando necesitamos prioridades muy estrictas, es decir, que nuestra tarea de alta prioridad no se interrumpa por nada del mundo (a no ser en el caso catastrófico de que la CPU esté tan sobrecargada que se supere el 100% de utilización). Por ejemplo, estamos grabando una sesión de audio con Ardour y observando cómo suben y bajan los indicadores de los faders. No importa si perdemos algún cuadro de refresco de los faders con tal de que el transporte de sonido del micrófono al disco duro no se vea interrumpido. Un kernel RT ralentizará el refresco de los faders todo lo que sea necesario con tal de que no se pierda ni una muestra de audio.

Dicho esto, en general los kernels no RT más recientes han mejorado mucho su sistema de planificación de tareas y su gestión de prioridades. Si no tienes la CPU al límite de sus posibilidades (digamos por debajo del 50% de utilización) o si no te importa que de vez en cuando se produzca un pequeño microcorte (clic) en el sonido (los tan temidos xruns), un kernel normal da unas prestaciones perfectamente aceptables.

¿Qué latencia es aconsejable?

A mí personalmente cualquier cosa por debajo de 10 ms ya me va bien y a partir de 20 ms ya empiezo a notar el retardo claramente. Hay gente más exigente.

Instalación

En Ubuntu y derivados:

sudo apt-get install linux-headers-lowlatency
sudo apt-get install linux-lowlatency
sudo update-grub

Al arrancar se podrá disponer de las dos opciones (el kernel normal y el de baja latencia).

En Arch y derivados:

yaourt -S linux-rt
sudo update-grub

Fuente: Hispasonic


13 comentarios, deja el tuyo

Deja tu comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

*

  1. Responsable de los datos: Miguel Ángel Gatón
  2. Finalidad de los datos: Controlar el SPAM, gestión de comentarios.
  3. Legitimación: Tu consentimiento
  4. Comunicación de los datos: No se comunicarán los datos a terceros salvo por obligación legal.
  5. Almacenamiento de los datos: Base de datos alojada en Occentus Networks (UE)
  6. Derechos: En cualquier momento puedes limitar, recuperar y borrar tu información.

  1.   Jordi Fdez dijo

    muy completo y bien
    explicado. eso si, estoy utilizando Linux para produccion musical con
    una distro corriente y moliente y no tengo problemas de latencia, la
    respuesta es instantanea al reproducir audio. no tengo muchos
    conocimientos, pero creo que los drivers para audio en Linux estan
    bastante bien, ni siquiera necesito jack para obtener un buen
    rendimiento

  2.   Carlos dijo

    Excelente artículo y la explicación no pudo estar mejor. Saludos

  3.   Carlesa25 dijo

    Hola: Muy interesante, lo probaré en tareas de cálculo intensivo CPU+GPU.

    Como se puede dejar el SO Ubuntu 12.0 como antes, es decir desinstalar el «linux-headers-lowlatency». Saludos.

  4.   Th3Gh057 dijo

    Muchas gracias por el artículo. Realmente es muy interesante conocer el funcionamiento de los núcleos de baja latencia. Me ha despertado el interés por conocer más de ello y su utilidad. Saludos

  5.   Oliver dijo

    Buenisimo el artículo! alguna vez escuché que era necesario un kernel de baja latencia para hacer funcionar un teclado con mejor respuesta pero no tenía idea de por que y como hacerlo. Muy clara la analogía.

  6.   Courage dijo

    Sí señor, completamente cierto.

    Es algo completamente vital en la producción musical, también, como se dice en el uso de VST’s, por ejemplo en un directo usando un controlador MIDI tenemos que ir a la vez que los demás instrumentos y una latencia alta nos puede jugar una mala pasada.

    O no necesariamente en el uso de instrumentos virtuales, sino en grabación, a través de la interfaz se produce latencia que nos puede confundir a la hora de interpretar instrumentos

  7.   Rayonant dijo

    Genial artículo, no tenia ni idea de lo que significaba una baja latencia en un kernel (aunque lo relacionaba con las latencias en los módulos de ram)

  8.   Gerardo Azoños dijo

    Muy bueno…me gustó mucho.
    cambiando de tema, alguien sabe como resolver el problema del wifi (inalámbrico de mi lap) que no me deja trabajar en espacios públicos, la señal es muy baja.
    tengo ubuntu 11.10 y mi lap es: Dell inspiron n4110.
    les agradezco de ante mano.

  9.   Miquel Mayol i Tur dijo

    Gracias, añadir que Sabayon lleva este kernel, compilado a 1000 Hz por defecto, que también es ideal para los servidores de juegos FPS y para los propios juegos FPS y cualquiera exigente, excepto quizás los que recurren a bases de datos, aunque a mi en Sabayon freeciv me volaba..

    En un escritorio normalmente prioriza la tarea principal , por lo que puede convenir usarlo aunque para las otras tareas sea menos eficiente para lo que estemos haciendo en el momento nos irá más rápido, y en las actuales computadoras modernas nos puede interesar bastante.

    Es cuestión de instalarlos, probarlos una semana, volver al kernel – normal – y ver que tal nos ha ido, y cual preferimos, además de usarlo para las tareas específicas que es mejor cada uno de ellos.

  10.   Gustavo Trepat dijo

    Excelente artículo, muy bien explicado.
    Gracias.

  11.   Esteban dijo

    Excelente explicación, muchas gracias, me ha servido de mucho 🙂

  12.   Carlos Martinez dijo

    Muy interesante artículo, me ha quedado un poco más claro aunque aun tengo dudas sobre si me conviene un kernel lowlatency. ¿Cómo puedo saber la latencia de un kernel? Saludos

  13.   JULIO dijo

    Recientemente instalé una distro de ubuntu studio y me di cuenta lo de low latency, investigando llegué a tu página. Tengo muy claro los conceptos básicos de Sistemas Operativos y tu explicación fue perfecta. Te lo curraste. Felicitaciones