Rami Taibah

La versión 2.6.28 del kernel Linux fue liberada mientras estábamos celebrando la Nochevieja, y declaró el tan esperado sistema de ficheros Ext4 como estable. Se habló tanto sobre cómo de rápido y de fiable es Ext4 que la comunidad Ubuntu se permitió celebrar la noticia de que la próxima versión 9.04 de la distribución incluirá Ext4. Ext4 incorpora multitud de mejoras, pero para alguien sin perfil técnico como yo la explicación puede aparecer confusa, con multitud de términos técnicos que no parecen tener mucho sentido. Así que pensé en informarme y en hacer todo lo posible por entender Ext4 y cómo mejorará nuestra experiencia informática diaria.

Para que un sistema escriba un fichero en un disco duro se necesita una metodología, e instrucciones específicas para alojar el espacio necesario. El viejo Ext3 utiliza un esquema de mapeado de bloques. Un fichero de 100 MB será mapeado en 25.600 bloques de 4 KB cada uno. Cuanto más grande sea el fichero, más bloques serán mapeados, algo que hará el manejo cada vez más lento.

Con la explosión de los accesos a Internet de alta velocidad y los contenidos multimedia este método aparece como claramente ineficiente. Ext4 introduce el concepto de Extent. Un extent es básicamente un conjunto de bloques. En nuestro ejemplo para un fichero de 100 MB, se dirá básicamente «escribe los datos en los próximos n bloques». En lugar de mapear cada bloque individual por separado, Ext4 soportará extents de hasta 128 MB, de forma que para un fichero de 1.000 MB ó 1 GB, se mapearán 10 extents en lugar de 256.000 bloques. Esto mejora el rendimiento y reduce la fragmentación.

¿Confuso? Permíteme explicarlo: En nuestro ejemplo de 100 MB, Ext3 utiliza un alojador de bloques que decide qué bloques libres van a ser utilizados para escribir los datos. Pero el alojador puede trabajar sólo de bloque en bloque, lo que significa que nuestro fichero de 100 MB necesitará 25.600 llamadas al alojador. Ineficiente, ¿no? Resulta aún peor darse cuenta de que el alojador no puede optimizar sus políticas porque en realidad no sabe cuántas veces va a ser llamado. No sabe el tamaño del fichero para el que se le está pidiendo que aloje bloques.

Ext4 va a soportar alojar multi-bloques, en una sola llamada, en lugar de una llamada por bloque, evitando sobrecargas de proceso.

Si quieres las ventajas de Ext4, tu sistema Ext3 existente puede ser fácilmente actualizado a Ext4 sin necesidad de formatear. Esto significa que tus datos permanecerán intactos después de actualizar —lo que no quiere decir que no debas hacer un backup antes—.

Lo explicado ya reduce en gran medida la cantidad de fragmentación en tu disco duro, aunque ésta acabará sucediendo de una forma u otra. Ext4 incorporará una herramienta que permitirá desfragmentar ficheros individuales o sistemas de ficheros completos —no disponible aún en 2.6.28 pero sí en futuras versiones—.

Otras características:

• Comprobación más rápida del sistema de ficheros; los bloques sin alojar son simplemente ignorados
• Marcas temporales mejoradas, lo que retrasa el problema con el año 2038
• Subdirectorios ilimitados; donde Ext3 tenía un límite de 32.000
• Ficheros más grandes; Ext4 soporta volúmenes de hasta 1 EB y tamaños de fichero de hasta 16 TB.

El popular blog sobre hardware y Linux Phoronix ha ejecutado unas pruebas extensivas sobre el rendimiento de Ext4 contra otros sistemas de ficheros populares como Ext3, XFS, JFS o ReiserFS. El resultado más impresionante se produjo durante la escritura de un fichero de 4 GB, donde Ext4 literalmente borró al resto de sistemas del mapa.

Softpedia ha ejecutado otra prueba distinta en un sistema Ubuntu y descubierto que el uso de Ext4 ahorra hasta 8,7 segundos durante el arranque del sistema.

• Ubuntu 8.10 con sistema de ficheros Ext3 arranca en 31,8 segundos (en un sistema AMD Sempron)
• Ubuntu 9.04 Alpha (Build 20090112.1) con sistema de ficheros Ext3 arranca en 28,3 segundos (en un sistema AMD Sempron)
• Ubuntu 9.04 Alpha (Build 20090112.1) con sistema de ficheros Ext4 arranca en 23,1 segundos (en un sistema AMD Sempron)
• Ubuntu 8.10 con sistema de ficheros Ext3 arranca en 26,8 segundos (en un sistema Intel Core 2 Duo;
• Ubuntu 9.04 Alpha (Build 20090112.1) con sistema de ficheros Ext3 arranca en 24,5 segundos (en un sistema Intel Core 2 Duo)
• Ubuntu 9.04 Alpha (Build 20090112.1) con sistema de ficheros Ext4 arranca en 21,4 segundos (en un sistema Intel Core 2 Duo)

Visto en Ext4 Filesystem Explained in Plain English.

Algunos nos dicen que deberíamos haber utilizado una versión descargada desde Mozilla y compilada por nosotros. No estamos de acuerdo, dado que la mayor parte de los usuarios de Linux utilizan software de su gestor de paquetes, y no se bajan otro tipo de cosas de la red. Otros nos han dicho que hubieramos debido probar también Opera. Por último hay quien nos cita que los drivers nVidia, AMD o Intel son los que ralentizan Linux.

De cualquier forma, pensamos en realizar un par de pruebas benchmark rápidas adicionales para ver si podíamos eliminar alguna de esas variantes. No tenemos tiempo para una suite completa desde cero, así que hemos realizado sólo unas pocas pruebas rápidas para ver qué encontramos.

Lo que necesitas saber es:

• Estas pruebas fueron ejecutadas en el mismo ordenador utilizado para las anteriores, con su misma instalación de Fedora 10
• Hemos probado con Mozilla Firefox para Linux tal cual es posible descargarlo desde Mozilla
• Hemos probado también Mozilla Firefox para Windows tal cual es posible descargarlo desde Mozilla, pero corriendo sobre WINE en Fedora.
• Hemos instalado y probado Opera 9.63 para Fedora 10, tal cual es posible descargarlo desde Opera.com. Nota: Sólo hemos encontrado binarios para i386 en el sitio de Opera, y esto no es óptimo, así que si alguien nos dice dónde descargar binarios para i686 de Opera para Fedora 10, actualizaremos con gusto el artículo.
• Hemos ejecutado el benchmark Google V8, como otras veces.

Para ser muy claros: Hemos tomado el Firefox de Windows y lo hemos corrido en Fedora Linux utilizando el WINE 1.1.12 de su gestor de paquetes. Con esta información, así es como quedan los resultados.

Como conclusión: Firefox de Mozilla o de Fedora tienen diferencias de velocidad insignificantes, pero Firefox para Windows corriendo en WINE es más rápido que el Firefox nativo. Opera queda por detrás, pero nos inclinamos a pensar que sus números serían mejores con un binario más optimizado.

¿Cuál es la moraleja? Esperamos comentaristas afirmando que el motivo es claramente un fallo de los drivers de nVidia, ATI o cualquier otro. Vamos, chicas, probadlo por vosotras mismas. Si usas Linux, instala WINE, prueba el Firefox de Windows y saca tus propias conclusiones.

Visto en Browser benchmarks 2: even Wine beats Linux Firefox publicado en TuxRadar vía Slashdot.

Florian Paul Schmidt

Pensé en documentar la información que tengo sobre cómo utilizar un sistema Linux con un kernel apropiativo —N. del T.; Preemptive en el original— a tiempo real como sistema de trabajo con audio y MIDI. Así puedo referirme a esta documentación en lugar de repetirla una y otra vez en discusiones.

Todo lo que sigue se aplica a los kernels -rt con el modelo apropiativo completo —N. del T.; complete preemption en el original—. En mi opinión es la mejor forma de operar con un kernel -rt si se quiere en control más estricto sobre prioridades y latencias. Procede un aviso y es que los drivers binarios y los módulos para nVidia podrían ser incompatibles con este tipo de kernel. Utilícese el driver nv de las X11 en su lugar. Aún si el módulo binario fuese compatible, no habría garantías de que encaje en el modelo particular de este kernel y podría destruir las bajas latencias que el resto del código del kernel nos garantiza.

El sistema de audio y MIDI

En un sistema de audio y MIDI típico basado en Linux encontramos varios componentes clave:

• JACK, el kit de conexiones de audio. Facilita servicios de audio y por supuesto utiliza la tarjeta de sonido. La IRQ de la tarjeta de sonido requiere un tratamiemto especial —es decir, una alta prioridad— para no ser interrumpida por otras cargas del sistema —el disco duro o la red—. JACK es la opción favorita para este trabajo dado que permite conectar las aplicaciones de audio las unas con las otras. Además está diseñado para el trabajo a tiempo real desde el primer día. Con un sistema correctamente configurado pueden lograrse latencias ridículamente bajas, p.ej. tamaños de buffer de 8 ó 16 muestras a 48 KHz.
• ALSA, facilitando servicios de audio a JACK y el acceso al MIDI vía alsa-seq.
• Algún secuenciador MIDI como rosegarden, muse o seq24 que utilice JACK y alsa-seq.
• Algunos sintetizadores software —al final, clientes JACK— manejados por el secuenciador MIDI
• Más hardware que precisa de una IRQ para funcionar —red, disco duro, etc.—
• El resto del software, como el gestor de ventanas, el escritorio y otras utilidades.

Cualquier kernel -rt en combinación con realtime lsm o rt_limits facilita al usuario herramientas que le permiten un trabajo cómodo que asegura:

• Operación de audio sin problemas, y con «sin problemas» me refiero a sin problemas. Por ejemplo, puedo fácilmente compilar un kernel mientras trabajo con audio a 32 muestras por buffer.
• Sincronización MIDI exacta.

Claro está que habrá que ajustar el sistema para obtener el mejor resultado. Podría ser necesario llegar a modificar algunas aplicaciones.

Configuración de audio

Podemos simplificar y decir que cuanto más alta sea la prioridad de una tarea más posible es que se ejecute sin molestias. Con un kernel -rt se tiene la posibilidad de que ciertos manejadores de IRQ tengan menos prioridad que aplicaciones que corren en el espacio de usuario. Es posible, por ejemplo, correr jackd con una prioridad mayor que la de cualquier manejador de IRQ que podría interrumpir el trabajo con audio, como el disco duro o la red. Es necesario el parámetro -P de jackd para esto.

En un kernel -rt, por defecto todos los manejadores de IRQ tienen prioridades entre 40 y 60, así que hacer que jackd se ejecute con una prioridad de 70 parece una buena elección.

  jackd -R -P 70 -d alsa ...
  

Sólo que si queremos que el manejador de la IRQ de la tarjeta de sonido tenga una prioridad más alta que jackd, dado que la IRQ de la tarjeta de sonido es al final la que gobierna el funcionamiento de JACK. Utilizamos así la utilidad chrt para cambiar esto. En mi sistema la tarjeta de sonido tiene la IRQ 4, comprueba /proc/interrupts en tu máquina para averiguar la tuya.

  chrt -f -p 82 `pidof "IRQ-4"`
  

—N. del T.; Comprueba las distintas prioridades asignadas así:—

  top -b -H -n 1 | grep -i irq | sort -n -k3
  

Una prioridad de 82 está bien por encima de la concedida a jackd. Dado que jackd ejecuta hilos además de su bucle principal, es necesario vigilar esto. Por ejemplo, implementa un watchdog que se ejecuta a una prioridad 10 superior a la del bucle principal. Es decir, a 80 en nuestro caso. Los hilos de proceso de cliente, en cambio, corren con una prioridad 1 inferior a la del bucle principal, 69 en nuestro caso.

La parte audio de nuestro sistema queda cubierta. Con esta configuración consigo operar con tamaños de buffer ridículamente bajos con JACK y mi M-Audio Delta 66 —hasta 8 muestras por periodo, reconociendo algún problema con el cambio de contextos forzando tanto mi sistema— Y ahora, ¿qué pasa con MIDI? ¿Cómo lo hacemos funcionar aquí?

Configuración MIDI

Tenemos que saber una cosa o dos sobre cómo la planificación a tiempo real funciona para afinar esta parte. La clase de planificación utilizada por la mayor parte de aplicaciones de audio es SCHED_FIFO. Se trata de una clase especial con niveles de prioridad estáticos de 1 a 99 y que garantiza que las tareas que la utilizan pueden conservar la CPU tanto tiempo como requieran, siempre que otra tarea SCHED_FIFO de mayor prioridad no la reclame. Por supuesto esto significa que un programa lo suficientemente puñetero puede bloquear el sistema simplemente acaparando toda la CPU siempre que no haya otra tarea con una prioridad mayor que pase por encima. Así que las tareas que tienen más prioridad ahora en nuestro sistema son los hilos de jackd y el manejador de la IRQ de la tarjeta de sonido.

El procesado de audio se realiza por lotes y para ilustrarlo permítaseme asumir que utilizamos un tamaño de buffer muy grande, digamos de 1 segundo —no sé si alguna tarjeta de sonido permite un buffer de este tamaño, pero para ilustrar el argumento supongamos que sí—. Se trata de 48.000 muestras a 48 KHz. Asúmase también que los clientes JACK están cargando realmente el sistema. Por ejemplo que el indicador DSP de jackd muestra un 50%. Esto significa que cada segundo el sistema completo se detiene para que jackd y sus clientes se tomen ese medio segundo para realizar sus procesos. Es fácil adivinar que el efecto en la sincronización MIDI va a ser terrible.

En realidad MIDI necesita más «tiempo real» que el audio. El audio se procesa en lotes de tamaño respetable —entre 1 y 50 ms dependiendo del tamaño de buffer utilizado—. Pero cuando un secuenciador MIDI necesita enviar un evento a un puerto, debe hacerlo con garantías de que llegará a tiempo a su destino —hay una excepción derivada de la implementación del secuenciador MIDI en ALSA, el cual permite aplazar eventos hasta un tiempo posterior, y de la que se derivan los problemas de ALSA con el MIDI—. El procesado MIDI, en cambio, es ligero comparado con el de audio. El bucle principal de un secuenciador MIDI necesita ejecutarse muchas veces por segundo para ser capaz de procesar eventos MIDI con una resolución lo suficientemente detallada. Así que la parte MIDI de un secuenciador debería correr con una prioridad mayor que jackd. La interfaz alsa-seq permite que los eventos MIDI sean aplazados para ser entregados en un momento preciso, lo que aligera el requisito de «debo enviarlo ahora mismo». Pero se trata de una funcionalidad compleja de gestionar y no demasiados programadores la utilizan. Así que tiene mucho más sencillo configurar el sistema para que los datos MIDI tengan una entrega inmediata.

Hay distintas fuentes de sincronización utilizadas por los secuenciadores MIDI en un sistema Linux. Las más comunes son:

RTC

El reloj en tiempo real que todo PC tiene. Corre a una frecuencia programable, p.ej. de 1.024 Hz y permite a una aplicación ser ejecutada muy a menudo y muy regularmente. Para que la sincronización basada en RTC funcione bien, el manejador de la IRQ del RTC —la IRQ 8 en un sistema XT-PIC, consúltese /proc/interrupts— necesita una prioridad superior a la de jackd y a la del resto de aplicaciones del sistema. 98 es un buen valor.

  chrt -f -p 98 `pidof "IRQ-8"`
  

Aún si no se utiliza el RTC, esta configuración no hará ningún daño. Si se quiere que los usuarios ordinarios puedan hacer uso del RTC a una frecuencia razonablemente alta, hay que asegurarse de que:

  /proc/sys/dev/rtc/max-user-freq
  

Está configurado a 8192. Puede hacerse ejecutando como root:

  echo 8192 > /proc/sys/dev/rtc/max-user-freq
  

—N. del T.; Es posible llevar esta configuración a /etc/sysctl.conf, consúltese la ayuda.—

Es posible por supuesto visualizar el valor actual:

  cat /proc/sys/dev/rtc/max-user-freq
  

Temporizador basado en sleep()

En este caso la aplicación corre repetidamente poniéndose a sí misma a dormir por cortos intervalos. Luego mide cuánto tiempo durmió para ser capaz de sincronizar correctamente. No sé exactamente como sleep() o sus derivadas como nanosleep() o usleep() están exactamente implementadas en Linux, así que me permito una adivinanza.

Cuando una tarea echa a dormir en realidad le dice al planificador que libera la CPU y que no quiere volver a ser ejecutada hasta que el tiempo de sueño haya vencido. El temporizador del sistema es una interrupción especial de temporización en todo sistema PC que corre a una frecuencia de 250 Hz en la configuración por defecto de un kernel Linux. Este temporizador del sistema ejecuta el bucle principal de ejecución de un kernel Linux, a saber, el planificador. Así que cuando sólo hay un temporizador disponible en el sistema, el tiempo más breve que una aplicación puede dormir son 4 ms —1/250 seg—. La granularidad es grande, así que cabe aconsejar cambiar la frecuencia por defecto del temporizador del sistema de 250 Hz a 1.000 Hz, lo que facilita una resolución de milisegundo a sleep(). Presúmase que se trata de una configuración correcta, que sólo costará un mínimo de carga adicional en el sistema.

Dado que este temporizador del sistema siempre corre a la máxima prioridad SCHED_FIFO en los kernel -rt actuales, no es necesaria ninguna configuración extra.

¡BZZZZT ERROR! Podrías tener que dar a algunos hilos de temporización también una alta prioridad para que sleep() funcione correctamente. El más importante aquí es softirq-timer/0, así que dale también un 99.

¡BZZZZZZZT ERROR OTRA VEZ! Esto se aplicaría sólo para un kernel habiendo sido compilado sin el soporte al temporizador de alta resolución. Espero aclarar este punto en algún momento en más detalle preguntando directamente a Ingo Molnar. Si en tu configuración el temporizador de alta resolución ha sido activado, no debería ser necesario darle a softirq-timer/0 una prioridad tan alta.

En realidad, actualmente parece que establecer esa alta prioridad a softirq-timer/0 daña el rendimiento del sistema. Así que de momento recomiendo configurar el temporizador de alta resolución en el kernel y dejar en paz a softirq-timer/0.

Otras fuentes de sincronización

¿Los temporizadores POSIX de alta resolución?

Hilos MIDI en aplicaciones MIDI

Nuestras fuentes de sincronización ya han sido establecidas. ¿Qué pasa ahora con las aplicaciones que las utilizan? Establecer una alta prioridad para la interrupción del reloj no es todo lo que se necesita. Las aplicaciones corriendo en el espacio de usuario deben utilizar dichas interrupciones directa o indirectamente, y también necesitan correr con altas prioridades. Idealmente por encima de la de jackd y el resto de material de audio.

Sintetizadores software

Habitualmente tienen un hilo de ejecución que recibe eventos MIDI, les añade una marca temporal —p.ej. mediante jack_frametime()— y los mete en una cola —idealmente un ringbuffer sin lock— donde las llamadas a audio_process() los van consumiendo. La llamada a process() puede determinar exactamente dónde dentro del periodo deben generarse los datos de audio correspondientes utilizando el método jack_last_frametime() de JACK —un método sencillo; añádase un periodo a la marca temporal de los eventos MIDI y después réstese el jack_last_frametime de la cuenta. La diferencia resultante es el desplazamiento dentro de el periodo que se está procesando. El hilo de recepción y marca temporal MIDI necesita correr a una prioridad más alta que jackd y que todos los procesos de audio. 90 es por ejemplo una elección razonable.

He escrito un pequeño sintetizador software que evalúa numéricamente la ecuación de onda que utiliza este esquema, y que funciona realmente bien.

ughsynth-0.0.5.tgz

Téngase cuidado sin embargo con la cantidad de CPU que utiliza —hasta un 50% en mi Athlon a 1,2 GHz—.

Secuenciadores MIDI

Generalmente tienen al menos un hilo de ejecución para manejar su sincronización MIDI. Algunos usan el RTC, otros se basan en sleep(). El único que conozco que permite establecer su prioridad en tiempo real es seq24 pero, hasta donde sé, esta prioridad está a pelo en el código fuente. Así que para ajustarla tendrás que remangarte.

No sé demasiado sobre el resto de secuenciadores MIDI ni de cómo manejan esta cuestión. Rosegarden por ejemplo facilita dos opciones diferentes para su fuente de sincronización —RTC y reloj del sistema basado en sleep()— pero no he encontrado la forma de obtener más detalles. Debería ser posible acceder a esta configuración utilizando la interfaz de usuario, lo que sería lo ideal.

Probándolo todo

He escrito un pequeño conjunto de aplicaciones:

midi_timer-1.tgz

Incluye dos que intentan producir un flujo de mensajes MIDI note-on. Una está basada en el RTC ejecutándose a una frecuencia de 2.048 Hz, lo que debería ser suficiente. La otra está basada en sleep(). Las dos se ejecutan a una prioridad de 95, por encima de la de jackd, y deberían servir como casos de prueba.

Resumen de configuración de prioridades

  99 System timer IRQ
  98 RTC IRQ

  95
  .
  . Midi threads of softsynths/midi sequencers
  .
  85 -

  82 Soundcard IRQ

  80 Jackd watchdog thread
  70 Jackd main loop
  69 Jackd client (softsynths/midi sequencers) audio process callbacks

  60
  .
  . Other IRQ handlers (disk, network, USB, GFX)
  .
  40
  

Permitiendo a usuarios normales ejecutar procesos en tiempo real

Consúltense las páginas de ayuda de realtime-lsm y/o rtlimits.

Visto en Linux Audio/MIDI System Setup publicado en Ugh! – Software, Music and more…