Analizando la Raspberry Pi de 512 MB

¡Hola de nuevo a todo el mundo! Ya hace unos meses de la salida de la primera Raspberry Pi y nos encontramos en un punto caliente donde la comunidad ha aportado cantidad de soluciones, proyectos e incluso le han salido "competidores" (que han querido subirse al carro de las mini computadoras low cost, olvidándose que lo importante de la misma es el soporte que le da la propia comunidad) y sin duda podemos afirmar que tenemos una pequeña gran ganadora.

Si hacemos un poco de memoria recordaréis que el primer modelo (Raspberry Pi model B) se empezó a comercializar con 256 MB, de los que se destinaban inicialmente 128MB a partes iguales para GPU y RAM. Muchos, poco habituados al mundo de Linux, podrán pensar que dicha cantidad es insuficiente a día de hoy para poder hacer lo que haría una computadora de sobremesa, pero los chicos de la Pi Foundation han sabido jugar sus cartas, ganarse a la comunidad Linuxera y darnos como resultado una excelente máquina que ofrece una versatilidad realmente impresionante.

Justo hace unas semanas nos confirmaban desde la fundación que ampliaban la memoria de los modelos A y B al doble de lo que hasta ahora venía siendo lo habitual, quedándose el modelo A en 256 MB y el modelo B en 512 MB. ¿Ventajas? Absolutamente todas y es que tras testearlo he quedado gratamente sorprendido con el cambio. Tengo que darle las gracias al equipo de Farnell España / element14, que me han hecho llegar el nuevo modelo en apenas unos días para que os pueda contar de primera mano mis impresiones. Sin más dilación os dejo con la review:

Farnell / element 14 nos ha proporcionado el material

1.- Cambios en el exterior

Aunque de primeras puedan parecer idénticas, hay muchas diferencias destacables entre el modelo B de 256 MB y el de 512MB (de ahora en adelante revisión 2 o rev.2). Lo primero que llama la atención es la inclusión de los mounting holes en la PCB (los agujeritos con los que atornillamos las placas base de un ordenador a la caja) que hará las delicias de los modders y desarrolladores caseros, que ahora podrán fijar su RasPi con mayor facilidad a casi cualquier elemento. A su vez se han cambiado serigrafiados en placa que estaban incorrectos, como el "OK" que ahora pasa a ser "ACT" (activity) y "10M" que ahora pasa a ser "100" para el LED de estado de la tarjeta de red. Minipunto para la rev.2 en fijación.

Detalle de uno de los mounting holes y de la serigrafía LED arreglada

El segundo cambio que me ha llamado muchísimo la atención, pero que podrían haber rematado mejor, ha sido la inclusión del P6 (a la izquierda del conector HDMI) que permite hacer reset al BCM2835 y, por lo tanto, reseteando nuestra Raspberry Pi. Antes os decía que lo podrían haber rematado mejor porque les ha faltado incluir los dos pines, ya que nos encontramos simplemente los puntos de placa a los que deberemos soldar un pulsador que cortocircuite ambos pines. Esto puede ser interesante para los fabricantes de cajas, a los que si se les enciende la bombillita pueden incorporar dicho pulsador y unos pines que bajen a placa para hacer contacto, a los más estilo usuario novato para que no necesite soldaduras. Os dejo foto y os marco en rojo los dos pines:

Detalle de P6 que permite resetear la Raspberry Pi

Otro cambio a favor de la rev. 2 y por lo tanto un minipunto más.

Ya con menor importancia se observa un cambio de los conectores de HDMI, RJ45, USB -ahora rematados en plástico negro-, jack de audio 3,5 por uno azul "feote" -lo prefería negro- y de la supresión de los pines en P2 para dejar desnudos los conectores en placa. No os preocupéis porque la supresión de dichos pines (o headers, que suele decirse en el argot) no os va a afectar, ya que eran utilizados únicamente en la producción de la placa, eso sí, sigo pensando que podrían haber empleado dos de ellos para el reset de P6 ;). En este caso empate en ambas, ya que no afecta en nada al usuario ninguno de los cambios.

A la izquierda la rev. 2 y a la derecha la rev. 1

2.- Cambios en el interior

Aquí es donde viene lo realmente interesante de la revisión 2: el aumento de memoria a 512MB. Pensad el cambio que puede suponer tener asignados 128MB en RAM y 128MB en GPU (o en muchos casos menos, para no asfixiar a la máquina). Vale que muchas distribuciones pueden cargarse en 64MB de RAM, pero eso no implica que vaya a ir rápido ni que podamos hacer maravillas con ellas. De ahí que muchos hiciéramos particiones GPU/RAM del tipo 32/224MB si teníamos pensado no arrancar un sistema de ventanas o, por lo menos, no hacer uso de él como algo habitual, pero aún así si intentábamos ejecutar alguna aplicación con un gran consumo de memoria (como puede ser un cliente torrent con simultáneas conexiones y una enorme cola de espera de peers) la cosa podía acabar con un sistema totalmente colgado. Los que hayan probado LXDE también serán conscientes de lo que hablo, ya que al mover una ventana, cargar una aplicación o intentar navegar por una página con bastante contenido, se convertía en un suplicio.

Para las pruebas he utilizado dos distribuciones completamente distintas: Debian Wheezy (Raspbian) con soporte ARMHF y en el otro lado del ring Raspbmc, ambas versiones preparadas para soportar los recientes 512MB. Os recuerdo que si es vuestra primera toma de contacto podéis usar de guía el tutorial para novatos que hay en el blog. A su vez para el testeo y pruebas de rendimiento he utilizado hardinfo en Raspbian, que genera unos informes muy completos de todo el sistema. Si queréis instalarlo debéis abrir una terminal y escribir:

sudo apt-get install hardinfo

Y para ejecutarlo podéis ir a "System Tools" en vuestro menú y posteriormente a "System Profiler and Benchmark". Tras ejecutar todos los test no he encontrado ninguna diferencia apreciable, aunque es de lógica porque todos ellos son de testeo de CPU y ésta no se ve afectada en rendimiento por la cantidad de memoria. Los resultados han sido los siguientes:

Modelo 512 MB:

CPU Blowfish
This Machine    Unknown MHz    98.724
CPU CryptoHash
This Machine    Unknown MHz    9.160
CPU Fibonacci
This Machine    Unknown MHz    26.000
CPU N-Queens
This Machine    Unknown MHz    84.890
FPU FFT
This Machine    Unknown MHz    145.225
FPU Raytracing
This Machine    Unknown MHz    129.625

Modelo 256 MB:

CPU Blowfish
This Machine    Unknown MHz    98.610
CPU CryptoHash
This Machine    Unknown MHz    9.143
CPU Fibonacci
This Machine    Unknown MHz    25.991
CPU N-Queens
This Machine    Unknown MHz    84.871
FPU FFT
This Machine    Unknown MHz    145.025
FPU Raytracing
This Machine    Unknown MHz    129.327


Sorprende incluso que el modelo de 256 haya tenido menores tiempos (a menor sea el valor, mejor es el resultado) pero como dije el resultado es inapreciable y, con toda seguridad, variable en un segundo test. Por lo tanto aquellos que piensen que van a ganar un mayor rendimiento en proceso van equivocados, ¿por qué? Porque nos encontramos ante la misma CPU y por lo tanto es imposible tener mejores resultados en ese aspecto, eso sí, siempre podemos hacer un overclock/overvolt a través de la configuración y reescalar la CPU a una frecuencia mayor (800 MHz es un buen valor sin tener que recurrir al overvolt)

¿Para qué sirve entonces el extra de memoria? Pues para muchísimas cosas que no dependen de la velocidad de reloj de la CPU. Pensad que en RAM vamos a tener los programas que se estén ejecutando y los datos de éstos, por lo que si tenemos una pequeña cantidad de memoria física deberemos recurrir a la virtual.

¿Para qué sirve la memoria virtual? La memoria virtual o de intercambio (la partición swap en Linux) se utiliza para que los programas puedan seguir trabajando con normalidad cuando la memoria física de la máquina se ha "agotado", sacrificando la velocidad de acceso de ésta por una velocidad menor al ser emulada en nuestro disco duro, pero si hacemos un uso excesivo de la swap va a tener ciertos problemas en nuestra Raspberry Pi. ¿Por qué? Porque os recuerdo que trabajamos con unidades flash como sistema de almacenamiento (las tarjetas SD, vamos) y dichas unidades tienen un ciclo de vida basado en la cantidad de escrituras que hagamos en ellas, por lo tanto cada vez que estemos haciendo uso de la swap por habernos quedado sin memoria estaremos acortando la vida de nuestra tarjeta. Y aquí está una de las principales ventajas de disponer de más memoria, y es que al tener mayor capacidad vamos a tener que recurrir en contadas veces a la memoria virtual y, por lo tanto, vamos a degradar menos nuestra tarjeta. Así que otro minipunto para el modelo de 512MB.

3.- Controlando el uso de memoria con Webmin

Webmin es un sistema de administración para sistemas Unix a través de web. En breve os enseñaré a instalarlo y utilizarlo, ya que es una herramienta realmente útil para gestionar la Raspberry Pi sin necesidad de estar delante o tenerla conectada a un monitor. He puesto ambas máquinas a funcionar, navegador por Internet y a hacer distintas tareas para provocar un uso de memoria y así poder analizar los resultados. En el caso de la rev.2 el resultado ha sido el siguiente:

Click en la imagen para ampliar

Como podéis ver el uso de la memoria virtual ha sido de 0 bytes tras navegar por Internet, instalar el propio Webmin, hacer los test de CPU y varias cosas más. Como os dije esto va a ser beneficioso para la vida de nuestra tarjeta SD, ya que al no estar escribiendo en ella vamos a ahorrar ciclos de vida. Fijaros a su vez que, tras lanzar LXDE y estar a una resolución de 1080p me sobran 281.96MB de la memoria que le he asignado como RAM. Una cifra bastante buena si contamos todo lo que estamos corriendo y que nos va a permitir lanzar aplicaciones que consuman mucha memoria, como podrían ser clientes torrent o navegadores web.


Veamos ahora la captura de Webmin para el mismo procedimiento con el modelo de 256MB:

Click en la imagen para ampliar

Fijaros ahora en las estadísticas que arroja Webmin. En apenas 3 minutos de haber iniciado la máquina y haber abierto el navegador, con la página de inicio por defecto, ya hemos hecho uso de la memoria virtual (nota posterior: tras 15 minutos ya había aumentado a 512kB). A su vez tenemos una menor cantidad de procesos corriendo, que propicia un menor uso de memoria y aún así ya hemos recurrido a la swap. ¿Cuál sería entonces la solución adecuada? Restarle MB a la GPU para asignárselos a RAM. ¿Qué conlleva dicho cambio? Un menor rendimiento en las X (interfaz gráfica) y por lo tanto nos va a costar mover más los gráficos en pantalla.

En conclusión, tener más memoria física nos sirve para usar menos la partición de intercambio, mejorar el rendimiento gráfico en consecuencia y alargar la vida de nuestra tarjeta de memoria al hacer menor uso de escrituras en ella. Otro minipunto para la rev. 2.

4.- Comparativa de precios

Aquí viene la mejor parte de todas; el precio. Tal vez estaréis pensando que el aumento de memoria va a tener repercusión en el precio, pero la buena notícia es que podéis adquirir la nueva versión por el mismo precio que hasta ahora tenía la primera revisión. No creo que haga falta decirlo, pero por si acaso otro minipunto para la rev. 2.

Por si hay algún despistado (que más de uno me ha preguntado por mail dónde adquirirla) os recuerdo que la mejor opción, a mi parecer, la tenéis en Farnell / element14. En apenas 3 semanas (actualmente) tendréis vuestra Raspberry Pi en casa lista para funcionar ;).

5.- Probando como media center

Como comenté anteriormente he probado a usar la nueva versión de Raspbmc. Tras un largo periodo de instalación, que cuento que duró casi 40 minutos en total, pude arrancar el centro multimedia. Como novedad destacable está la inclusión de las librerías libCEC 2.0 que permitieron que controlase la Raspberry con el mando de mi TV a través de CEC. La verdad es que noté que usando el mando de la televisión iba mucho más fluido que si usaba el ratón y teclado, así que me armé de valor a probar ambas máquinas con contenido de YouTube.
La cantidad de memoria en ambas reproduciendo vídeos a 720p y 1080p rondó entre el 40% y el 70%, cantidad más que suficiente para que el funcionamiento fuese correcto, pero el problema de Raspbmc (o de los port que hay de XBMC a arquitecturas ARM) es el excesivo uso de la CPU. En mi caso puse ambas máquinas a funcionar a 800Mhz, haciendo así uso de 100Mhz más de lo habitual en la Raspberry, y aún así el consumo de la misma rondaba valores constantes de más del 65 y 70%. Aquí no culpo a la Raspberry, porque recuerdo haber utilizado XBMC en la Xbox original funcionando a menos de esa velocidad de CPU e ir mucho más fluido entre menús. Supongo que con el tiempo irán limando el port para ARM y tendremos versiones mucho más fluidas al moverse entre opciones o con tiempos de respuesta más cortos.
Aún así y como es de lógica funcionó notablemente mejor en el modelo de 512MB, ya que tanto GPU como RAM disponen de más MB con los que poder trabajar, consiguiendo un mayor número de FPS (frames per second) y un menor tiempo de carga de complementos, imágenes, etcétera.

Como era de esperar, otro minipunto al modelo de 512MB.


6.- Veredicto final

Aunque creo que no es ni necesario decirlo, mi veredicto es que el nuevo modelo de 512MB o revisión 2 de la Raspberry Pi es mucho más que una simple revisión o ampliación de memoria. Va a permitir alargar la vida de nuestra SD, va a reducir tiempos de carga, vamos a conseguir que la gráfica pueda rendir más, tener mayor cantidad de programas corriendo, vamos a tener la posibilidad de añadirle un botoncito de reset si queremos, podemos fijarla con los mounting holes a cualquier supercifie que se nos ocurra, etcétera, etcétera, etcétera. En resumen, que no hay motivo para no actualizarnos a este nuevo modelo y sacarle el 100% a nuestra Raspberry Pi como se merece. Sin medias tintas, sin medias memorias y por la misma cantidad de dinero. Si la pobráis me entenderéis. ;)

Una vez más agradecer al equipo de Farnell / element14 el interés mostrado y el material cedido (ánimo, que sé que tenéis faena con el Electronica 2012). En breve nos veremos con más tutoriales, análisis, ideas y cualquier sugerencia que me hagáis llegar a través de aquí o de Twitter (@drkbcn)