Ubuntu 10.10 con 512 MB RAM

ASRock K7VM3

ASRock K7VM3

Ubuntu 10.10 anda perfecto en esta máquina de 2004. Con menos de 512 MB de RAM, solo usa 298 MB con el Firefox 4.0 abierto (5 tabs).  El procesador es de 32 bits y trabaja a 44ºC.

La instalación de Ubuntu ocupa 2,9 GB y tiene una montón de programas incluidos.

Con tan pocos recursos, de repente una PC que tenía en el armario se transformó en algo útil.

-Computer-
Processor        : AMD Sempron(tm) 2500+
Memory        : 492MB (298MB used)
Operating System        : Ubuntu 10.10
Date/Time        : mar 16 nov 2010 23:38:27 ART
-Display-
Resolution        : 1280×1024 pixels
OpenGL Renderer        : Mesa DRI UniChrome (KM400) 20060710 x86/MMX+/3DNow!+/SSE
X11 Vendor        : The X.Org Foundation
-Multimedia-
Audio Adapter        : VIA8233 – VIA 8235
-Input Devices-
Power Button
Sleep Button
Power Button
AT Translated Set 2 keyboard
Genius Optical Mouse
-Printers-
No printers found
-SCSI Disks-
ATA WDC WD400BB-00FR
LITE-ON CD-ROM LTN-529S
HL-DT-ST DVD-RAM GSA-H20N

¿Windows tiene problemas de afinidad y le echamos la culpa a AMD?

(Y lo peor es que aparentemente es más fácil cambiar todas las BIOS antes que arreglar Windows.)

Voy a tratar de explicar por qué Windows no hace un uso óptimo del procesador a raíz de que su planificador de CPU (CPU scheduler) tiene muy pobre afinidad natural.

Cuando se tiene más de un procesador (o más de núcleo en un procesador) los procesos se pueden ejecutar en cualquiera e incluso a lo largo de su ejecución pueden pasar de uno a otro. Sin embargo, mudar un proceso a otro procesador es una operación costosa y que debe evitarse sobre todo en el caso de procesos que hacen uso de CPU en forma intensiva.

¿Por qué es costosa?

  • Primero porque cada procesador (o núcleo) tiene sus propias memorias caché L1 y L2 y al mudar un proceso a otro procesador hay que volver a leer de la RAM o de la caché L3 los datos e instrucciones que se necesitan. Si el proceso hubiera seguido en el mismo procesador habría sido altamente probable que sus datos todavía estuvieran en las cachés. Cuantas más veces se mude un proceso de procesador más tiempo se perderá en recargar las cachés.
  • Segundo porque el procesador al que el proceso fue reasignado puede estar en un estado de ahorro de energía y le tomará un tiempo (por ejemplo 1 milisegundo) activarse y volver a la velocidad máxima.

Eso último es exactamente lo que pasa con Windows Vista, Seven y Server 2008 en los procesadores AMD Phenom X3 y X4. Cuando se tiene una tarea que requiere usar el 100% de CPU como puede ser el caso de ver una película en HD o comprimir audio o video, típicamente sólo uno de los 3 ó 4 núcleos está trabajando a la velocidad máxima (2,2 GHz por ejemplo) y los demás en la mitad (1,1 GHz). Eso es bueno, porque se ahorra energía, se emite menos calor y se puede reducir la velocidad de los ventiladores disminuyendo el ruido y todo eso sin perder rendimiento.

Como Windows hace rebotar los procesos entre los diferentes procesadores casi constantemente (todos lo notan), transcurre luego de cada cambio un tiempo en el que el proceso se ejecuta a 1,1 GHz. Además hay que sumar el tiempo para que las cachés L1 y L2 se invaliden y repoblarlas con datos traídos desde las memorias más lentas (L3 y RAM).

El resultado es que a la larga el rendimiento es menor cuantos más cambios de núcleo hay.

El concepto de Afinidad justamente busca evitar esos problemas tratando dentro de lo posible que un proceso que se está ejecutando en un procesador siga haciéndolo ahí. El sistema operativo Linux tenía también problemas de afinidad en su versión 2.4, pero desde la versión 2.6 responde muy bien en ese aspecto.

Ahora, ¿por qué se llega al extremo de decir que el manejo de Cool’n’Quiet del AMD Phenom X4 tiene un bug? Está claro que el rendimiento de los benchmarks ejecutados en Windows es inferior con Cool’n’Quiet habilitado que deshabilitado, pero no es culpa del hardware sino del software.

El resultado sería igualmente bueno al medido sin Cool’n’Quiet

  • si el planificador de CPU de Windows fuera mejor;
  • o si deshabilitáramos 3 de los 4 núcleos del Phenom;
  • o si le asignáramos una CPU Affinity Mask al proceso que hace el benchmark;
  • o si le especificáramos al proceso la afinidad a uno de los núcleos desde el administrador de tareas;
  • o si no usáramos Windows.

El problema de la afinidad de Windows ya es muy conocido y hasta la base de datos FirebirdSQL tiene incorporada una configuración para que se pueda obligar a Windows a ejecutarla en un determinado procesador para evitar el pésimo desempeño ocasionado por ir de un procesador al otro a cada rato. Está claro ahí mismo que eso sólo es necesario en Windows y en ningún momento se menciona que sea un problema del AMD Phenom X4. De hecho el problema y su solución puntual están ahí escritas desde antes de que existiera ese modelo.

En procesadores como los de Intel que tienen muchos núcleos y la característica de hyperthreading, manejar bien la afinidad es vital ya que el costo del cambio de un procesador a otro no es el mismo al cambio de un núcleo a otro ni el mismo del cambio de un thread a otro dentro del mismo núcleo. Veamos:

  • Puede haber 2 procesadores físicos cada uno en su socket en cuyo caso no comparten nada y pasar un proceso de uno a otro tendría el máximo costo.
  • Puede haber dos núcleos dentro de un procesador, en cuyo caso comparten la caché L3 y el costo sería algo inferior.
  • Puede haber 2 threads dentro de un núcleo en cuyo caso comparten todo: L1, L2 y L3, pero ambos threads compiten por el uso de determinados recursos del propio procesador lo que podría ocasionar menor rendimiento.

El mal llamado bug de Cool’n’Quiet no hace más que poner en evidencia o agravar un problema que ya estaba y que sigue estando en la forma en que Windows planifica el uso de la CPU.

La solución que adoptó AMD en su Phenom II de no permitir que los núcleos operen a diferentes velocidades mitiga una de las consecuencias, pero tiene el costo de desperdiciar energía, generar más calor y no permitir la reducción de ruido provenientes de los ventiladores. El problema de la caché L2 sigue sin solución y afecta a cualquier marca de procesador. De hecho cada tanto alguien encuentra el problema y recurre a establecer manualmente la afinidad de un proceso en Windows.

El otro día estuve codificando un video de 9,1 GB a Theora. Tardó 6 horas y como tengo un widget en el escritorio que me muestra a cuántos gigahertz se está ejecutado cada núcleo, se veía claramente que siempre era el mismo el que estaba ocupado y los otros tres estaban libres casi todo el tiempo (tengo habilitado el Cool’n’Quiet). Eso es porque uso Linux.

Ventajas de los Drivers Libres

Ahora que finalmente el soporte 3D está llegando a las placas de video ATI se hacen más evidentes las ventajas de que el código fuente de los drivers esté disponible.

Soporte a Largo Plazo

El driver libre para ATI Radeon soporta todos los modelos lanzados al mercado desde 2000. En cambio el driver Catalyst de ATI ya no soporta modelos tan viejos y menos en Windows 7. Algo similar ocurre con las placas NVidia. El driver que provee el fabricante no soporta tantos modelos como el driver libre.

Integración

Cada vez que sale una versión nueva de Linux o del servidor gráfico, si es necesario, se adaptan todos los drivers libres para que sigan funcionando correctamente. En cambio los otros drivers suelen tardar más en ser adaptados y dejan a mucha gente si soporte un tiempo. Además los drivers libres son integrados por las propias distribuciones de Linux y vienen «andando de fábrica» mientras que los drivers de los fabricantes los debe bajar el usuario de la página oficial e instalarlos siguiendo las instrucciones.

Soporte de Errores

Si bien los drivers libres a veces se deben hacer sin las especificaciones oficiales que los fabricantes no publican, los programadores que los hicieron se ocupan de arreglar los errores y de hacer las mejoras que sean posibles. En el caso de AMD/ATI, entre 2007 y 2008 publicó la documentación necesaria para sus placas de video Radeon y los drivers libres se están haciendo en base a ella. Es así que ahora cualquiera puede reportar errores o incluso participar de las mejoras. En cambio ATI y NVidia son más propensos a escuchar a los fabricantes de juegos que a los usuarios y desde ya que no se puede participar de las mejoras de sus drivers.

Hoy los drivers de los fabricantes son más completos y en algunos casos puede ser que sean más rápidos, pero a la larga los drivers libres van completarse y van a alcanzar el rendimiento del otro reteniendo las otras ventajas antes explicadas.

Soporte 3D en Linux

Logo de ATI Radeon

Cuando en abril salga Ubuntu 10.04 Lucid Lynx se supone que finalmente tendremos soporte 3D para placas de video ATI con los drivers radeon y radeonhd hechos en base a las especificaciones que AMD publicó cuando compró ATI. En particular la documentación necesaria para usar el hardware de video para operaciones 3D fue publicado el 29 de diciembre de 2008 y llegaron al kernel 2.6.32 que salió 3 de diciembre de 2009.

Según la página de esos drivers libres, se necesita esa versión del kernel y la versión 7.7 de la biblioteca gráfica mesa. Lucid Lynx parece estar preparado ya que trae:

  • xserver-xorg-video-radeonhd 1.3.0-2
  • linux-generic 2.6.32.15.16
  • mesa 7.7-4

En el caso de tener una placa ATI determinamos qué hardware es con esta explicación tomada de la wiki del driver libre:

  * RV505:	Radeon X1550, X1550 64bit
  * RV515:	Radeon X1300, X1550, X1600; FireGL V3300, V3350
  * RV516:	Radeon X1300, X1550, X1550 64-bit, X1600; FireMV 2250
  * R520:	Radeon X1800; FireGL V5300, V7200, V7300, V7350
  * RV530:	Radeon X1300 XT, X1600, X1600 Pro, X1650; FireGL V3400, V5200
  * RV535:	Radeon X1300, X1650
  * RV550:	Radeon X2300 HD
  * RV560:	Radeon X1650
  * RV570:	Radeon X1950, X1950 GT; FireGL V7400
  * R580:	Radeon X1900, X1950; AMD Stream Processor
  * R600:	Radeon HD 2900 GT/Pro/XT; FireGL V7600/V8600/V8650
  * RV610:	Radeon HD 2350, HD 2400 Pro/XT, HD 2400 Pro AGP; FireGL V4000
  * RV620:	Radeon HD 3450, HD 3470
  * RV630:	Radeon HD 2600 LE/Pro/XT, HD 2600 Pro/XT AGP; Gemini RV630; FireGL V3600/V5600
  * RV635:	Radeon HD 3650, HD 3670
  * RV670:	Radeon HD 3690, 3850, HD 3870, FireGL V7700, FireStream 9170
  * R680:	Radeon HD 3870 X2
  * M52:	Mobility Radeon X1300
  * M54:	Mobility Radeon X1400; M54-GL
  * M56:	Mobility Radeon X1600; Mobility FireGL V5200
  * M58:	Mobility Radeon X1800, X1800 XT; Mobility FireGL V7100, V7200
  * M62:	Mobility Radeon X1350
  * M64:	Mobility Radeon X1450, X2300
  * M66:	Mobility Radeon X1700, X1700 XT; FireGL V5250
  * M68:	Mobility Radeon X1900
  * M71:	Mobility Radeon HD 2300
  * M72:	Mobility Radeon HD 2400; Radeon E2400
  * M74:	Mobility Radeon HD 2400 XT
  * M76:	Mobility Radeon HD 2600;(Gemini ATI) Mobility Radeon HD 2600 XT
  * M82:	Mobility Radeon HD 3400
  * M86:	Mobility Radeon HD 3650, HD 3670, Mobility FireGL V5700
  * M88:	Mobility Radeon HD 3850, HD 3850 X2, HD 3870, HD3870 X2
  * RS600:	Radeon Xpress 1200, Xpress 1250
  * RS690:	Radeon X1200, X1250, X1270
  * RS740:	RS740, RS740M
  * RS780:	Radeon HD 3100/3200/3300 Series
  * R700:	Radeon R700
  * RV710:	Radeon HD4570, HD4350
  * RV730:	Radeon HD4670, HD4650
  * RV740:	Radeon HD4770. EXPERIMENTAL AND UNTESTED
  * RV770:	Radeon HD 4800 Series; Everest, K2, Denali ATI FirePro
  * RV790:	Radeon HD 4890
  * M92:	Mobility Radeon HD4330, HD4530, HD4570. EXPERIMENTAL
  * M93:	Mobility Radeon M93. EXPERIMENTAL AND UNTESTED
  * M96:	Mobility Radeon HD4600
  * M97:	Mobility Radeon HD4860. EXPERIMENTAL AND UNTESTED
  * M98:	Mobility Radeon HD4850, HD4870

En la tabla sobre estas líneas están los modelos anunciados comercialmente por los fabricantes como ATI Radeon HD 3200 que es una placa integrada y el chipset correspondiente. Luego muchos chipsets están agrupados por sus características en tres grupos:

  • R500 style hardware: R5xx, RV5xx, RS6xx, RS740, M52 and up
  • R600 style hardware: R6xx, RV6xx, RS780, M64 and up
  • R700 style hardware: RV7xx

Una vez que determinamos si nuestro hardware de video corresponde a la serie R500, la R600 o la R700, podemos ir a ver qué funcionalidades ya están implementadas en el driver libre.

En http://www.x.org/wiki/RadeonFeature se lista el soporte al presente de cada serie para diversos aspectos como la aceleración 2D, 3D  o la salida a TV o HDMI.

Para saber qué aplicaciones 3D (como Compiz, juegos y Google Earth) han sido probadas y cómo funcionan se puede consultar esta página http://www.x.org/wiki/RadeonProgram.

En cuanto pueda voy a probar la versión alfa 3 de Lucid Lynx en mi equipo y voy a ver si puedo hacer andar el soporte 3D o si tendré que esperar a instalarlo en su versión final.

Actualización: efectivamente los efectos del escritorio 3D de Compiz funcionan en la versión alfa 3 de Ubuntu 10.04 Lucid Lynx sin tener que hacer ninguna configuración especial. Lo probé en una ATI Radeon HD 3200 ejecutando desde el disco USB de Ubuntu.

SoundConverter y la Computación Multi-core

SoundConverter es un programa de GNOME que permite traspasar música de cualquier formato (Ogg Vorbis, AAC, MP3, FLAC, WAV, AVI, MPEG, MOV, M4A, AC3, DTS, ALAC, MPC, Shorten, APE, SID, etc.) a otros formatos (WAV, FLAC, MP3, AAC, and Ogg Vorbis).

Lo bueno es que está pensado para ser sencillo y a la vez potente. Por ejemplo en mi equipo que tiene 4 núcleos, comprime de a 4 archivos a la vez. Es una de las primeras aplicaciones que observo que logran aprovechar al máximo el AMD Phenom X4 sin requerir intervención del usuario o una estrategia de uso compleja para aumentar el trabajo que se realiza en paralelo.

Es difícil hacer aplicaciones que usen correcta y eficientemente varios núcleos. En algunas aplicaciones es tan difícil que nadie se toma el trabajo. En este caso particular es muy sencillo y por suerte se tomaron el trabajo de hacerlo. En mi experiencia, se puede ahorrar hasta un 70% del tiempo de codificación usando cuatro núcleos en lugar de uno.

Por supuesto que está en los repositorios de Ubuntu.

AMD Phenom X4

Quiero hablar del procesador de AMD que disfruto en mi computadora. Es el AMD Phenom X4 9550.

En rigor son 4 procesadores (o núcleos) integrados junto al controlador de memoria en el mismo chip. Cada uno corre a 2.200 MHz y tiene 128 KB de memoria caché de nivel 1 y 512 KB de nivel 2. Además los 4 comparten 2 MB de memoria caché de nivel 3.

Cada núcleo en si mismo es rápido, supera ampliamente a un AMD Athlon X2 ejecutando a los mismos MHz, pero como 2.200 MHz no es lo más rápido que se ha visto (incluso hay modelos de este mismo procesador de hasta 2.600 MHz) al ejecutar una única tarea como por ejemplo comprimir un video o una canción a mp3 no es el procesador más rápido del mundo (ni siquiera en su familia de Phenoms).

Para sacarle todo el jugo a este Phenom hay que hacer varias cosas a la vez, o paralelizar. Obviamente que no se puede estar todo el tiempo haciendo 4 cosas, la mayor parte del tiempo tenemos suerte si hacemos 2 a la vez (escuchar música y navegar, por ejemplo). Pero hay que armarse de una estrategia para hacer más a la vez y así ganar tiempo aprovechando más y mejor el recurso.

Características que favorecen el procesamiento en paralelo

  • Ya se dijo que es un procesador de 4 núcleos, hay posibilidad de tener 4 tareas ejecutándose en paralelo.
  • 2 MB caché compartida. Este tipo de caché es necesaria porque la caché de cada núcleo suele perder eficacia cuando una tarea que se estaba ejecutando en un núcleo es programada para ejecutarse en otro por el sistema operativo. La caché compartida no tiene ese problema. Fíjense que la versión II del Phenom X4 tiene entre 4 y 6 MB de caché compartida.
  • Acceso a memoria en unganged mode: en teoría permite que diferente núcleos accedan a la memoria en forma independiente en determinadas circunstancias. En algunas aplicaciones hay beneficio. Aunque ese test ejecuta una única tarea a la vez. Sería deseable ver qué pasa cuando se ejecutan diferentes tareas en forma paralela. Ahí hay más probabilidad de que el método de acceso unganged mejore la performance.

La velocidad de una computadora con este procesador en tareas cotidianas es tan rápida como se desea. Lo único que retrasa la experiencia es la conexión a Internet. Para aprovechar este procesador al máximo en tareas que insumen mucho tiempo la clave es dividir el trabajo y paralelizarlo.

Tarea 1: comprimir un CD a MP3

Este tipo de tarea consta de 2 fases, extraer a música del CD (ripping) y la compresión a MP3 (u OggVorvis, FLAC, AAC, el preferido). La primera fase es muy importante para evitar ruidos en el sonido y además requiere muy poco procesador y mucho de leer de la unidad de CD.

Paso 1: ripear el CD a WAV sin comprimirlo. Eso lo podemos hacer en segundo plano mientras hacemos otras cosas.

Paso 2: ejecutar 3 procesos de compresión en forma simultánea, cada una con un subconjunto de las canciones extraídas del CD.

Con seguridad podremos seguir usando la PC como si nada pasara mientras se comprimen las canciones y además si comprimir 12 canciones tardaba 12 minutos, de esta forma en aproximadamente 5 minutos habremos terminado.

Tarea 2: comprimir un DVD a DivX (o Xvid, Theora, el preferido de cada uno)

Lo ideal es copiar el contenido del DVD a una carpeta del disco para evitar estar leyendo de la unidad de DVD todo el tiempo.

En este caso no es tan simple dividir la tarea, pero uno siempre tiene la duda de si elegir tal o cual calidad. Ya no más problemas, elegimos ambas calidades y largamos a comprimir simultáneamente con las 2 calidades ejecutando 2 instancias del programa de compresión.

Lo mismo si se duda entre un codec y otro, podemos largar ambos codecs en 2 instancias del programa en paralelo.

Es probable que cada tarea individual tarde un poquito más al estar ejecutándose en paralelo que si lo hace sola, pero lo que es seguro es que ese tiempo de más nunca será cercano al que tardaríamos ejecutado primero una y luego la otra.

Esto último yo lo hice con un DVD que quería pasar a un formato más comprimido usando Thoggen. Puse 3 instancias de Thoggen a comprimir el video que había copiado del DVD al disco. En 4 horas tenía 3 versiones de diferentes calidades para elegir la que más me gustara. Lo mejor es que durante esas 4 horas, podía usar la PC como si nada para las tareas cotidianas.

Para este tipo de tareas ayuda mucho, diría que es indispensable, tener mucha RAM. Por más que tenemos 4 procesadores, el disco sigue siendo uno solo (salvo en equipos con hardware especial) y poder tener 2 o 3 GB de datos en caché de disco es muy beneficioso.

Las aplicaciones en general no están diseñadas para aprovechar la presencia de muchos procesadores. Pero las pocas que lo están realmente tienen un rendimiento extremo en este procesador. En mi caso lo experimento con las aplicaciones Java como NetBeans. Es que Java de por sí tiene muchas cosas ejecutándose a la vez y particularmente el garbage collector que es una pieza clave en la performance de esta plataforma. Netbeans es una de las pocas aplicaciones que en algún momento utiliza los 4 procesadores (aunque brevemente).

Energía

Para la mayoría de la gente, el ahorro de energía no es importante, pero sí el ruido del los ventiladores de la PC. Este procesador consume típicamente 95 W de potencia (en realidad 95W es tu thermal design power o TDP), y los ventiladores andan a 4.500 RPM como máximo. Pero tiene una característica de ahorro de energía que hace que los ventiladores bajen hasta 3100 RPM según la carga. Es que cada núcleo, puede ejecutarse a la velocidad de 2.200 MHz o a la mitad (1.100 MHz) cuando no hay nada que hacer. Esto ahorra energía, baja la temperatura del procesador y reduce la velocidad de los ventiladores haciéndolos más silenciosos. A pesar de no ser un procesador de una portátil, tiene esta funcionalidad y lo notable es que cada núcleo regula independientemente su velocidad según la carga que tiene en cada momento.

Para esto hay soporte en Windows y Linux, por supuesto. Lo único que noto a veces es que en Windows los ventiladores suelen estar más tiempo a menor velocidad, pero en Linux puedo monitorear segundo a segundo a qué velocidad de reloj está ejecutándose cada núcleo.