Acelerando video en alta definición H.264 por hardware en Ubuntu 10.04 con ATI

   Desde que monté el HTPC una de las cosas que siempre quise hacer fue acelerar por hardware los vídeos H.264. Todas las series que descargo (que son bastantes) intento que estén siempre en 720p puesto que además de la calidad adicional respecto al divx estándar, también viene con sonido 5.1, por lo que la sensación final es mucho mejor.
   Así, quería poder acelerar el video sin tener que tirar de cpu. Cuando tenía instalado windows xp en el HTPC lo intenté siguiendo varias guías y tutoriales y también con distintos programas, pero al final no fui capaz de conseguirlo. Desde que instalé Ubuntu en el HTPC la cosa ha cambiado. Mi placa base lleva integrada una ATI HD3200, que, aunque es algo modesta y para juegos seguro que se queda corta, permite acelerar vídeos en alta definición. Para ello vamos a utilizar las librerías VAAPI (Video Aceleration API) que son el equivalente para ATI de las famosas VDPAU de NVidia. Además, como no podría ser de otra forma, el reproductor será mplayer. Veamos cómo lo he conseguido.

Instalando el driver propietario de ATI
   Utilizaremos la última versión de los drivers propietarios de ATI para Linux. En Ubuntu 10.04 sólo funcionan los drivers a partir de la versión 10.4. Por suerte, cuando salió la última versión de Ubuntu, en ATI se pusieron las pilas y al día siguiente ya habían liberado los drivers. Parece que por fin nos van teniendo en cuenta a los usuarios de Linux.
   Actualmente la última versión disponible para mi tarjeta es la 10.7. La descargamos, en mi caso la versión de 64 bits, y la instalamos sin mayor complicación con:

$ sudo ./ati-driver-installer-10-7-x86.x86_64.run

Instalando las librerías VAAPI
   Como hemos comentado, para conseguir la aceleración por GPU vamos a usar VAAPI. En la web http://www.splitted-desktop.com/~gbeauchesne/ nos tenemos que bajar las últimas versiones disponibles de: libva, libva-dev, libva-dbg y xvba-video

$ wget http://www.splitted-desktop.com/~gbeauchesne/libva/pkgs/amd64/libva-dev_0.31.1-1+sds4_amd64.deb
$ wget http://www.splitted-desktop.com/~gbeauchesne/libva/pkgs/amd64/libva1-dbg_0.31.1-1+sds4_amd64.deb
$ wget http://www.splitted-desktop.com/~gbeauchesne/libva/pkgs/amd64/libva1_0.31.1-1+sds4_amd64.deb
$ wget http://www.splitted-desktop.com/~gbeauchesne/xvba-video/xvba-video_0.7.2-1_amd64.deb

Instalamos los paquetes que acabamos de descargar:

$ sudo dpkg -i libva* xvba-video_0.7.2-1_amd64.deb

Compilando mplayer con soporte VAAPI
   Aunque no es estrictamente necesario, sí es recomendable instalar primero la versión existente en los repositorios de Ubuntu. Así, el sistema sabrá que está instalado y nos permitirá instalar complementos como la interfaz gráfica SMPlayer.
   Antes de poder compilar mplayer tendremos que descargar todas las librerías y paquetes xxxx-dev necesarios. Para ello ejecutamos lo siguiente. En mi caso se descargaron 112 paquetes, pero esto puede variar de un sistema a otro en función de lo que tengamos instalado previamente.

$ sudo apt-get build-dep mplayer

   Aunque la compilación de mplayer puede parecer algo complejo, realmente es muy sencilla. Lo que realmente nos vamos a descargar es un script y unos parches para mplayer. Descargamos la última versión disponible en http://www.splitted-desktop.com/~gbeauchesne/mplayer-vaapi/.

$ wget http://www.splitted-desktop.com/~gbeauchesne/mplayer-vaapi/mplayer-vaapi-20100713.tar.bz2

$ bunzip2 mplayer-vaapi-20100713.tar.bz2
$ tar xvf mplayer-vaapi-20100713.tar
mplayer-vaapi-20100713/
mplayer-vaapi-20100713/patches/
mplayer-vaapi-20100713/patches/mplayer-vaapi-gma500-workaround.patch
mplayer-vaapi-20100713/patches/mplayer-vdpau.patch
mplayer-vaapi-20100713/patches/mplayer-vaapi.patch
mplayer-vaapi-20100713/patches/mplayer-vaapi-0.29.patch
mplayer-vaapi-20100713/checkout-patch-build.sh
mplayer-vaapi-20100713/README.txt
mplayer-vaapi-20100713/NEWS

   Ejecutamos el script que se encarga de todo. Descarga de los subversions las versiones adecuadas de mplayer, ffmpeg y dvdnav, las parchea y finalmente las compila. Si hemos ejecutado todos los pasos anteriores deberíamos tener todas las dependencias satifeschas y la compilación no debería fallar. Esperamos a que termine ya que tardará más o menos en función de la potencia de la máquina.

$ ./checkout-patch-build.sh

Ahora tendremos un directorio llamado mplayer-vaapi en el que estará disponible nuestra propia versión de mplayer.


Probando a vídeos con aceleración y sin ella
   Para hacer la prueba voy a utilizar un capítulo de Lost en 720p. Primero vamos a hacer una prueba sin acelerar ejecutando simplemente:

$ ./mplayer Lost.S06E01-02.720p.mkv
...
VIDEO:  [H264]  1280x720  0bpp  24.000 fps    0.0 kbps ( 0.0 kbyte/s)
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==========================================================================
Starting playback...
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [xv] 1280x720 => 1280x720 Planar YV12

   Si ahora hacemos lo mismo pero utilizamos VAAPI vemos en la salida de mplayer que estamos usando las librerías para la aceleración.

$ ./mplayer -vo vaapi -va vaapi Lost.S06E01-02.720p.mkv
...
VIDEO:  [H264]  1280x720  0bpp  24.000 fps    0.0 kbps ( 0.0 kbyte/s)
libva: libva version 0.31.1-sds1
Xlib:  extension "XFree86-DRI" missing on display ":0.0".
libva: va_getDriverName() returns 0
libva: Trying to open /usr/lib/va/drivers/fglrx_drv_video.so
libva: va_openDriver() returns 0
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
[VD_FFMPEG] VA API accelerated codec.
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==========================================================================
VO: [vaapi] 1280x720 => 1280x720 H.264 VA-API Acceleration
[VD_FFMPEG] XVMC-accelerated MPEG-2.

   Para que se vea de una manera más gráfica la diferencia de consumo de CPU, con el comando pidstat tomé muestras del consumo de mplayer en ambos casos.

   Como vemos la diferencia en ambos casos del uso de CPU es brutal, algo esperado porque quien realmente está decodificando el vídeo en el caso de VAAPI es la GPU.

   Finalmente, copiamos mplayer a su ubicación definitiva para poder ejecutarlo desde cualquier sitio. Con esto reemplazaremos los binarios que instalamos desde los repositorios.

$ sudo make install
install -d /usr/local/bin /usr/local/etc/mplayer /usr/local/lib
install -m 755 -s mencoder /usr/local/bin
install -d /usr/local/share/man/man1
install -m 644 DOCS/man/en/mplayer.1 /usr/local/share/man/man1/
cd /usr/local/share/man/man1 && ln -sf mplayer.1 mencoder.1
install -m 755 -s mplayer /usr/local/bin

Automatizando los parámetros de mplayer
   Ahora ya sabemos cómo acelerar los vídeos por hardware pero es una tarea un poco pesada tener que pasar todos los parámetros de mplayer para cada vídeo. Además, en mi caso, no estoy utilizando la salida de audio mini-jack de la placa base, sino que uso la salida óptica S/PDIF. Para conseguir que mplayer saque el audio por ese conector, también debemos indicárselo.
   Mostramos un listado de los dispositivos hardware capaces de reproducir audio para ver cual es que nos interesa.

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: SB [HDA ATI SB], device 0: ALC889A Analog [ALC889A Analog]
 Subdevices: 1/1
 Subdevice #0: subdevice #0
card 0: SB [HDA ATI SB], device 1: ALC889A Digital [ALC889A Digital]
 Subdevices: 1/1
 Subdevice #0: subdevice #0
card 1: HDMI [HDA ATI HDMI], device 3: ATI HDMI [ATI HDMI]
 Subdevices: 1/1
 Subdevice #0: subdevice #0

   Así, debemos ejecutar mplayer indicando la tarjeta y el dispositivo que queremos utilizar para sacar el audio. Adicionalmente también le forzamos el audio AC3:

$ mplayer -ao alsa:device=hw=0.1 -ac hwac3 -vo vaapi -va vaapi pelicula.mvk

   Si hubiera querido que el audio saliera directamente por el conector HDMI que va a la tele, las opciones que tendría que haber puesto en mplayer serían: -ao alsa:device=hw=1.3
   Esto cada vez crece más. Si antes teníamos que poner las opciones para el soporte vaapi, ahora adicionalmente tenemos que poner también la salida por S/PDIF. Para nuestra comodidad podemos añadir todas estas opciones al archivo de configuración de mplayer.

$ cat /home/ivan/.mplayer/config
# Write your default config options here!
# Salida por S/PDIF
ao=alsa:device=hw=0.1,
# Forzar audio a AC3
ac=hwac3
# Aceleración HW
vo=vaapi
va=vaapi

   De esta sólo tenemos que ejecutar

$ mplayer pelicula.mkv

y tendremos la salida de audio por S/PDIF y la aceleración por hardware habilitada.


¿Y por qué no usar VLC?
   Hace un par de semanas se ha liberado la versión 1.1.1 de VLC con soporte VAAPI. Si queréis instalarlo podéis seguir estas instrucciones. Simplemente consiste en añadir un nuevo repositorio e instalar VLC desde él. Aún así esta versión no está compilada con soporte VAAPI. También nos podemos descargar una versión con el soporte vaapi habilitado, pero según podemos leer en el enlace anterior, se "romperán" el resto de reproductores de video y paquetes que utilicen la versión de ffmpeg de los repositorios de Ubuntu. La única solución sería recompilarlos todos contra la nuevas versión de ffmpeg.

Now, regarding vaapi (GPU acceleration): you basically can't compile VLC 1.1.0 with vaapi support without breaking stuff. To get it to work with vaapi, it would need newer ffmpeg packages which would mean every package using the ffmpeg packages in the Ubuntu official repository would be broken unless it is compiled against the same ffmpeg package (so you would need to either compile every package that uses ffmpeg yourself or a PPA should package all these packages - which is practically impossible).

There is a PPA which packages VLC 1.1.0 with vaapi support as well as fixed mplayer to work with the new ffmpeg/gstreamer. But since this PPA only has VLC and mplayer, it means that other video players / video editors will stop working if you use the following PPA and for this reason I won't post instructions for installing it here. You can however find both the PPA and exact instructions for installing VLC 1.1.0 with vaapi support, HERE. Remember: using it, a lot of applications will be broken! Also, the VLC package in the Cutting Edge Multimedia PPA (not the C-Korn PPA we posted in the begining of the post - that's stable and doesn't break anything!) doesn't yet have the latest VLC 1.1.0 but a GIT version dating back to June 16 - that's still very close to the final version.

   Así que nada. Tendremos que esperar a que se actualicen todos los programas de los repos antes de poder probar la aceleración hardware con VLC.


Conclusiones
   Sabía que acelerar los vídeos por GPU iba a suponer que la CPU prácticamente estuviera descansando, aún así el resultado me ha sorprendido gratamente. Además, por fin parece que ATI proporciona unos drivers que funcionan en Linux. Son propietarios y cerrados y sería estupendo que fueran libres, pero al menos, los que decidimos apostar por ATI y Linux no nos sentimos abandonados como hace unos años cuando ATI en Linux era sinónimo de problemas y quebraderos de cabeza. Aún recuerdo cuando monté mi ordenador "de sobremesa" hace ya más de tres años, que elegí una NVidia sin dudarlo por la multitud de problemas que había con ATI en Linux. En fin, los tiempos cambian, por fortuna a mejor, para los usuarios de Linux :-).

HTPC para el salón

   En casa, tanto mi mujer como yo somos muy aficionados a las series. Desde hace ya varios años no vemos la tele. Por las noches, después de acostar a Judith nos ponemos uno o dos capítulos de alguna de las series que seguimos (que son muchas) y disfrutamos de los contenidos que nos gustan cuando nosotros queremos y sin cortes publicitarios.
   Hace ya algún tiempo que conté cómo tengo configurada la red de casa. Hasta ahora, el proceso que seguía un capítulo era el siguiente, lo descargaba del emule con el portatil que tengo dedicado para ello, luego lo copiaba a mi sobremesa, de ahí lo grababa en dvd's reescribibles y me lo llevaba al reproductor de dvd-divx del salón. Como os podéis imaginar es una tarea muy pesada y en muchas ocasiones, grababa unos cuantos capítulos, pero justo algun otro que no había grabado era el que le apetecía ver a mi mujer :-P.

   Así, después de mirar y convencer a mi mujer me decidí a montar un HTPC. Lo primero que tengo que aclarar es que el equipo lo monté a finales de enero (pero lo he ido dejando y hasta ahora no he sacado hueco para el post), por lo que ahora mismo puede que hubiera elegido otras opciones que no estaban disponibles hace 6 meses. Veamos lo que elegí:

Micro AMD Athlon 64 4850e: Aunque soy más de intel, en esta ocasión he elegido AMD. En concreto ese micro porque es especial para htpcs ya que sólo disipa 45W, por lo que podremos tenerlo fresquito sin muchos ventiladores.

Placa base Gigabyte MA78GM-DS2H: Esta placa estaba en casi todas las configuraciones de htpc que leía en los foros. Es una placa muy completa y tiene las salidas que yo estaba buscando: HDMI para conectarla a la tele y salida digital de audio para conectarla al amplificador. Además lleva la tarjeta gráfica integrada (ATI HD3200) que permite aceleración de contenido en alta definición por hardware.

Memoria: 2 GB en dos módulos Kingston. Para el uso que le voy a dar al htpc no necesitaba 4.

Disco duro: Seagate de 640 GB. Creo que los hay más silenciosos, pero en mi caso no lo aprecio y éste estaba a buen precio. Por cierto, ya lo tengo casi lleno :-P

Fuente de alimentación Tacens Radix II de 420W totalmente modular, así sólo conecto los cables de alimentación que necesito.

Caja SilverStone Grandia GD02B: Con la caja tuve un problema y es que mi mueble sólo tiene 40 centímetros de profundidad, por lo que la mayoría de las cajas del mercado no me servían. Al final me quedé con esta aunque me subió un poco de precio, pero no tenía muchas más alternativas. Al menos la caja cuesta lo que vale: es toda de aluminio, con un tacto muy agradable y unos acabados de gran calidad. Además tiene esos "pequeños" detalles que la hacen una gran caja como las gomas en los agujeros del disco duro para absorber las vibraciones y que haya el menor ruido posible.

Grabadora de DVD: Aunque no utilizo mucho el dvd porque todo es contenido descargado, sí que viene bien en ocasiones cuando alguien te deja un dvd o para alguna peli de dibujos de Judith (por supuesto copias de seguridad :-P). Elegí la grabadora LG más barata que encontré, no necesitaba nada mejor :-P.

Teclado y ratón inalámbricos: Como es algo que se va a utilizar muy poco: para buscar los subtitulos, comenzar la reproducción y poco más, elegí uno de una marca poco conocida pero muy económico. Al día siguiente lo tuve que devolver porque el alcance era nulo. Lo cambié por un pack Logitech Cordless Desktop EX110 que tiene un alcance realmente impresionante: me fui a dos habitaciones de distancia del salón y seguía funcionando!. Además el consumo de pilas es muy bueno. En estos 6 meses las pilas del teclado las he cambiado una vez y las del ratón todavía no.

Capturadora de televisión: No he puesto ninguna. El HTPC sustituye en el salón a un video y al reproductor de dvd-divx. Hablando con mi mujer, me preguntó qué hacíamos si queríamos grabar algo de la tele. Mi respuesta fue que llevábamos años (literalmente) sin grabar nada, así que al final nos ahorramos la capturadora.

   Y respecto al hardware eso es todo. Como sistema operativo instalé Windows XP y dejé una partición para instalar Linux, aunque para ser sincero todavía no lo he hecho por falta de tiempo. Hace unos meses probé un live-cd de Ubuntu 8.10 y no conseguí sacar el audio en 5.1 por el amplificador. En cuanto pueda pruebo con la versión 9.04 a ver qué tal.
   Como conclusiones finales diré que estamos encantados con el cambio. Sigo descargando todo en el portatil dedicado al emule y por las noches cuando nos ponemos a ver algo lo grabo directamente al disco duro del htpc. Así siempre tenemos disponible todo lo descargado para elegir. Hemos ganado en calidad de vida...

P.D: Los más observadores se habrán dado cuenta de que en la foto de todos los componentes hay un disipador Scythe Ninja Mini. Lo compré para sustituir al disipador de serie porque pensaba que el htpc estaba muy encajonado y no iba a refrigerar bien. El problema fue que no entraba en la caja y al final lo devolví. Además, he podido comprobar en todo este tiempo que las temperaturas se mantiene en unos márgenes muy razonables.

La informática de antaño

   Estaba haciendo limpieza el otro día en el trastero y al abrir un par de cajas me he encontrado con todo tipo de hardware que me ha hecho recordar cómo era todo en el mundo de la informática hace algunos años. Me he decidido a hacer unas cuantas fotos y a recordar...

Tarjetas perforadas: Datan de los años 1960-1970 y se utilizaban para introducir instrucciones en los ordenadores. Actuan como un código binario en función de si están perforadas o no. Como véis tengo unas cuantas, en total hay 25 perforadas y 4 vírgenes. He querido destacar un fragmento de código de una tarjeta en la que se ve una fecha: 31 de Marzo de 1981, seguramente era para sacar un listado a final de mes. Por aquel entonces sólo utilizaron la fecha con formato 31.03.81 y no se preocuparon de lo que ocurriría en el año 2000... ;-)
   He hablado con mi padre puesto que las tarjetas eran suyas y las utilizó en el trabajo hace mucho y me ha contado que tenían una especie de máquina de escribir en la que tecleaban la instrucción en Cobol y cuando la terminaban la máquina perforaba la tarjeta. Así, iban construyendo el programa línea a línea y al final colocaban todas las tarjetas en un alimentador de hasta 5000 tarjetas que se encarga de leerlas e ir ejecutando el programa. Estos programas corrían contra un host IBM 3090 que estaba en Alemania (mi padre trabajaba desde Madrid). He buscado información de esa máquina y para aquella época era impresionante: dos o cuatro procesadores y 64 ó 128 MB de almacenamiento (según modelo). Y estamos hablando de principios de los 80!.


Disquetes 8": Los empezó a utilizar IBM a finales de los 60 para cargar el microcódigo de arranque en sus mainframes System/370. Antes de disponer de esta unidad de disco utilizaban unidades de cinta para realizar esta carga, pero el proceso era muy lento. Si os fijáis en el de la izquiera, podéis ver que la capacidad era de sólo 1024 bytes, es decir, un "miserable" Kbyte!!.


Disquetes 5.25": El primer prototipo se diseñó en 1975 y surgió por la necesidad de cambiar los discos de 8" que resultaban demasiado grandes. Seguramente los más viejos del lugar recuerden las disqueteras de sus primeros 8086 y la "gran cantidad de información" que podíamos almacenar en estos disquetes. En las fotos véis que la capacidad había aumentado considerablemente, yo tenía de 360 KBytes y de 1.2 MBytes. El disquete de arriba a la derecha es la versión 3.21 de D.O.S.


Disquetes de 3.5": Surgieron a mediados de los 80 como sustitutos de los de 5.25". Por aquel entonces éstos últimos ya no resultaban nada prácticos y además se podían estropear con mucha facilidad. Así, después de diversos formatos e intentos por reducir el tamaño se llegó a los discos de 3.5" que todos conocemos. Las ventajas eran innumerables: formato mucho más pequeño, más capacidad debido al rediseño que se hizo, estaban protegidos por una pequeña chapita,... De estos seguro que sí os acordáis todos. Como podéis ver tengo unas cuantas cajas con juegos clásicos (Monkey Island, Doom, Maniac Mansion,...), multitud de programas (WordPerfect, dBase III,...), discos de arranque... grabados en disquetes de 3.5" y la mayoría comprimidos con el mítico ARJ.


Platos de disco duro: Aunque seguro que la mayoría ha desarmado algún que otro disco duro, los platos de abajo son los normales de discos duros de 3.5" y los de arriba son de discos duros mucho más antiguos. Seguramente no tenían ni siquiera 20 MBytes de capacidad, por lo que os podéis hacer una idea de cuando serán.


Placa de 486: Esta es la placa de un 486DX 50Mhz. Como véis por aquel entonces no había slots PCI y lo máximo eran los nuevos slots VESA Local Bus que creo que nunca llegué a utilizar.


Memorias SIMM de 30 contactos: Las que utilizaba en la placa anterior con mi 486. Empecé con 4 Mbytes cuando me compré el ordenador pero un año después lo amplié con 8 MBytes más. Con esos 12 Mbytes era capaz de ejecutar todos los juegos nuevos sin ningún problema y el ordenador iba muy fluido. Todavía conservo 16 módulos (recordad que iban de 2 en 2) de diversos tamaños que en total suman 152 MBytes de RAM.


Tarjetas gráficas ATI Mach: Todavía conservo un par de tarjetas gráficas de la época. La de abajo es una ATI Mach32 ISA y la de arriba una ATI Mach64 PCI. ¡Qué buenos ratos me hicieron pasar las dos!.


Tarjetas de red: Todas 3Com de diversos modelos. Las de la izquierda son de 10 MBits/seg y conexión ISA, las inferiores de 10 Mbits/seg y conexión PCI y las superiores de 100 Mbits/seg y conexión PCI.


Tarjetas de sonido: Las míticas Sound Blaster AWE 64. ¿Quién no ha tenido una Sound Blaster en su máquina?.


Controladora SCSI: Tiene conexión ISA y creo que nunca la llegué a utilizar, tengo poco que añadir...


Unidad de cinta: En la época de los discos duros de 120MB que parecía que nunca los ibas a llenar y que al final terminaban llenos de juegos (de MS-DOS, claro). La unidad de cinta era perfecta para poder hacer backups de tus juegos y los pocos datos que se acumulaban por aquel entonces. La capacidad era abrumadora porque en una sóla cinta entraban 340MB!. Tenía una unidad externa que se conectaba al puerto de paralelo y posteriormente me hice con esta interna que se conectaba al cable de la disquetera. Las transferencias eran bastante lentas pero podías dejar el backup lanzado y cuando volvías tenías todo tu disco duro en una pequeña cinta.


Cintas de backup: Como ya he comentado tenían 340 Mbytes de capacidad que incluso se podían duplicar si los backups se hacían con la compresión habilitada.


Pentium MMX: Este micro fue una mejora realizada a los primeros Pentium que les añadía las Multimedia Extensions.


Pentium Pro: Fue el procesador diseñado por intel para reemplazar a los Pentium originales. Se utilizó básicamente en servidores y estaciones de trabajo de alto rendimiento y su característica principal es que estaba diseñado para poder montarse en placas bi-procesador.


Placa Pentium 2: Esta era mi placa para el pentium 2 a 300 Mhz que tuve. Esta placa ya llevaba memoria SDRAM, tenía slots PCI e ISA y además introducía el AGP para la conexión de la tarjeta gráfica. Este ordenador me estuvo acompañando muchos años y todavía funciona. En la entrada Servidor Raid 1 en Preproducción de marzo de 2007 comentaba que lo había montado de nuevo para hacer una prueba del raid 1 en linux con hardware real.


Pentium 2: Intel creó este micro después del Pentium Pro. La principal característica que más llamaba la atención era su enorme tamaño y su encapsulado. Era algo totalmente distinto a lo que estábamos acostumbrados a ver.


Memoria SDRAM: Este tipo de memorias ya no era necesario montarlas de 2 en 2 y fueron las precursoras de las actuales DDR, DDR2,.... Se podían mezclar de cualquier tamaño y funcionaban sin problemas. La mayoría de los módulos que tengo funcionan y en total suman 896 MBytes de RAM repartidos en los 10 módulos que se ven.


Tarjetas PCMCIA: El principal uso de este tipo tarjetas es para utilizarlas como expansión en los portátiles. Así, en los tiempos en que éstos no tenían ni modem ni tarjeta de red integrados con una simple tarjeta pcmcia se podían ampliar. Este tipo de tarjetas se podían conectar y desconectar en caliente (el famoso plug&play).


Discos duros: En total tengo 14 discos duros IDE de los que seguramente no debe funcionar casi ninguno. Son discos muy antiguos y su capacidad va desde los 850 MBytes a los 4.2 GBytes. Los fabricantes son Seagate, Sansumg, Quantum y Fujitsu.


   A todo esto que habéis visto hay que añadirle multitud de cables IDE, cable de red, conectores DB25 y DE9 desarmados y listos para soldar en un cable, cables de audio de los que se conectaban a la tarjeta de sonido y al lector de cd's, algún lector de cd's y grabadora antigua, tres modems de 33.6 bps y 56 bps... y diverso hardware más.

   Quiero dar las gracias a mi padre que ha estado muchos años dedicándose a esto y gracias al cual he podido estar cerca de todo lo que acabáis de ver. Muchas veces he pensado que si él hubiese sido albañil, fontanero, mecánico... en lugar de informático, yo no habría llegado donde estoy ni tendría esta pasión y afición que tengo por la informática. ¡Muchas gracias papá!.
   Además, tampoco me olvido de mi mujer por dejarme conservar todas estas reliquias y cacharros viejos como los llama ella en el trastero...

Aprovechando servidor HP Proliant con VMware ESX Server

   En el anterior post comentaba que teníamos en el trabajo unos servidores nuevos pero que estaban siendo totalmente desaprovechados. Comenzamos justo donde lo dejé diciendo que había encontrado la forma de poder aprovecharlos. Se trata de utilizar VMware Server ESX 2.5 (como ya acertó Supercoco en los comentarios) para virtualizar el Windows 2003 Server. VMware ESX está basado en linux como sistema operativo base lo que le proporciona gran estabilidad, más concretamente en RedHat 7.1. Además incluye un conjunto de utilidades que actúan como capa de acceso a todo el hardware que proporcionan la virtualización. Utiliza un sistema de ficheros propio, VMFS en el que se almacenan los discos virtuales de cada máquina virtual y que se puede compartir entre varios servidores ESX. Los requisitos para la instalación de VMware ESX son bastante elevados puesto que están pensados para servidores. Así, debemos tener una máquina multiprocesador, gran cantidad de RAM, al menos dos tarjetas de red y controladora SCSI, RAID ó FC principalmente.

   La instalación de VMware ESX es muy sencilla, sólo hay que configurar la zona horaria, el password de root, la distribución del teclado y las particiones. La controladora raid fue reconocida sin ningún problema y en poco más de 20 minutos tenía el sistema instalado. Una vez reiniciada la máquina para arrancar ya con ESX me conecté a la web de administración para terminar de configurar el sistema. Aquí lo único necesario es configurar un archivo swap de intercambio y crear un switch virtual para las máquinas virtuales. Tambien es necesario indicar cuanta memoria queremos reservar para el sitema base que se encargará de gestionar las máquinas virtuales. En función del número de máquinas virtuales que deseemos tener, éste variará entre 198 y 800 MB para un total de entre 8 y unas 60-70 máquinas virtuales.

   Hecho esto y después del pertinente reinicio para que se reserve la memoria seleccionada para la consola ya podemos crear nuestra primera máquina virtual. El asistente de creación es similar al existente tanto en VMware Workstation como VMware Server y no presenta ninguna dificultad. Una vez hecho esto nos descargamos desde el propio servidor la consola para poder conectarnos a las máquinas virtuales y podemos comenzar con la instalación del sistema operativo.

   Después de un rato instalando y configurando todo tenía el Windows 2003 Server listo y con una configuración más equilibrada que la anterior. En este caso le asigné 4 CPUs y 4 GB de RAM (realmente fueron 3600MB por imposición de VMware).

   El resto lo dejé libre para crear máquinas virtuales que actuarán como clientes y que necesitan menos recursos. Seguramente serán 4 máquinas virtuales con Windows XP con una CPU y 1 GB de RAM.

   Me guardo para el próximo artículo contar desde un punto de vista algo más técnico algunas curiosidades de WMware ESX Server y algunos pequeños trucos y ayudas.

Instalando un servidor HP Proliant DL360

   El cliente del proyecto en el que estoy trabajando nos ha enviado un par de servidores HP Proliant DL360. Estos servidores vienen equipados con 2 procesadores Intel Xeon E5345 Quad Core, 8 GB de RAM, 4 discos duros de 10.000 rpm (pero de sólo 2,5 pulgadas) de 72 GB en RAID 5 (por hardware), 2 tarjetas de red y además con el teclado y monitor integrados en el extraño rack que podéis ver en las fotos (tomadas con un par de móviles).

   En estas máquinas instalamos una versión de nuestra aplicación que actua como servidor. El sistema operativo que llevan instalado es Windows 2003 Server y trabajamos con Oracle 10g y Exchange.

   Como es de sobra conocido, un sistema operativo de 32 bits como el que tenemos instalado no permite direccionar más de 4 GB de RAM (a lo que hay que restarle la reservada para direccionar la memoria de la tarjeta gráfica). Así, después de tener instalado uno de los servidores, abrimos el administrador de tareas y vemos esto:

   A mi se me cayó literalmente el alma a los pies al ver cómo de desaprovechada estaba la máquina. Más de 4 GB de RAM ni siquiera existían para el sistema operativo y las 8 CPUs (4 cores en cada micro) son excesivas para nuestra aplicación, por lo que también están infrautilizadas.

   Entonces nos planteamos instalar la versión de 64 bits de Windows 2003 Server, pero finalmente no pudo ser porque teníamos problemas con el Exchange y también con nuestra aplicación. Así, parecía que íbamos a tener ahí esas impresionantes máquinas totalmente desaprovechadas.

   Como no me quedé contento con eso pensé una solución para sacarle el mayor partido al hardware que tenemos y al final la encontré, pero eso lo contaré en el siguiente artículo.

Los viejos tiempos...

   Aunque en mi nuevo trabajo estoy muy contento no sólo porque estoy más cerca de casa y por el horario, sino porque me gusta lo que hago, a veces echo de menos tener minimizadas 12 sesiones de putty en distintas máquinas y cacharrear con algunas cosas que ahora ya no utilizo. He puesto en negrita máquinas porque tenía a mi "disposición" máquinas como esta:

$ /usr/platform/sun4us/sbin/prtdiag -v
System Configuration: Sun Microsystems sun4us Fujitsu Siemens PRIMEPOWER650 1- slot 8x SPARC64 V
System clock frequency: 270 MHz
Memory size: 12288 Megabytes

========================= CPUs =========================

Run Ecache CPU CPU
Brd CPU Module MHz   MB   Impl. Mask
--- --- ------ ----- ---- ----- ----
0   0   0       1349 2.0    5    0.8
0   1   1       1349 2.0    5    0.8
0   2   2       1349 2.0    5    0.8
0   3   3       1349 2.0    5    0.8
0   4   4       1349 2.0    5    0.8
0   5   5       1349 2.0    5    0.7
0   6   6       1349 2.0    5    0.8
0   7   7       1349 2.0    5    0.8

   Sí, es una máquina Fujitsu PrimePower 650 con 8 CPUs de 64 bits a casi 1,4 Ghz cada una de ellas y 12 GBytes de RAM (hay que tener en cuenta que esta máquina se compró a principios de 2005 cuando no era tan común tener tanta RAM). Esta máquina corre Solaris 9 y creo que es una de las más potentes de toda Validación Técnica. En esta máquina corrían tres instancias de base de datos Oracle 9i, alguna de ellas de 200 GBytes de datos, unos 12 Apache-Tomcat, 10 WebMethods Integration Server y alguna que otra cosa más y para remetar, le sumamos que está conectada por una tarjeta de fibra óptica a un armario de discos de Clariion con más de 13 TBytes, podéis imaginar cómo lo echo de menos. Antes de que preguntéis en los comentarios debo aclarar que esos 13 TBytes de espacio eran compartidos para todas las máquinas que no eran de producción, es decir, desarrollo y VT, por lo que no vale decir: la cantidad de MP3s y pelis que entrarían ahí ;-).

   En una de las intervenciones para el cambio de la systemboard que hubo en esta máquina después de algunos problemas, bajé al CPD aprovechando que tenía enchufe ;-) y le estuve haciendo algunas fotos (eso sí, con el móvil, por lo que la calidad no es muy buena) porque siempre tenía ganas de ver cómo era una máquina de estas por dentro.

Detalle Frontal	Frontal

System Board	Memoria

   En fin, que tengo un poco de nostalgia en ese sentido del trabajo que hacía antes pero también estoy muy contento con el cambio que hice hace casi un año.

Fonera brickeada...

   ...Y arreglada!. Hace ya tiempo, intentando instalar un nuevo firmware en una de mis foneras hice lo que comúnmente se conoce como brickear, vamos, que me la cargué. Buscando un poco de información en los foros leí que con un cable serie la podía conectar al ordenador para intentar recuperarla.

   Mi circuito es una pequeña adaptación del que encontré y no está tan currado pero para el uso que le iba a dar es más que suficiente. El material que utilicé y el precio fue:

Placa protoboard: Tenía una en casa de alguna práctica de la facultad, así que esto me lo ahorré. También se puede utilizar una placa perforda pero hay que soldar y no me apetecía mucho ;-).

4 condensadores electrolíticos de 1 µF: 0,20€ cada uno.

1 condensador electrolítico de 10 µF: 0,20€.

Chip Max232: Para controlar la comunicación por el puerto de serie. También tenía uno de otra práctica.

Cable de audio de un lector de cdrom: Lo usé para desarmarlo y conectarlo a los pines de la fonera de una manera fácil.

Cable serie o conector para el PC y tres hilos: En mi caso tenía el cable y lo que hice fue cortarlo para engancharlo a la placa.

   Después de un rato conectando cables según el circuito lo tenía listo para probarlo. El cable que sale por abajo es el que va a la Fonera y el de arriba es el cable serie que va al ordenador. Después de conectarlo todo, el circuito quedó:

   Y seguí este magnífico post para conectarme por el cable de serie a la fonera y poder instalarle de nuevo el firmware oficial de Fon. Después de eso, seguí mi propio post (qué pronto se olvidan las cosas) para instalarle dd-wrt y ya está recuperada y funcionando de nuevo :-).

Como dicen en el anuncio: "condensadores, placa protoboard, cables,... unos pocos euros. Pasar una tarde entretenido y recuperar una fonera... no tiene precio".

Modding Fonera

   Siguiendo el post anterior de pintar la grabadora de dvd, decidí que ya que me ponía podía pintar una fonera a ver qué tal quedaba. Después de frotar un rato con alcohol borré el logo de fon y desarmé la fonera. Esto es lo que tenemos:


   Me llevé las piezas al parque y después de pintarlas el resultado fue el siguiente: