Diseño, configuración y evaluación de cluster de Raspberry pi para el procesamiento paralelo de vídeo

Dise˜no, configuraci´on y evaluaci´on de cluster de Raspberry pi para el procesamiento paralelo de v´ıdeo Luis Mu˜noz Saavedra 1, Lourdes Mir´o Amarante 1y Manuel J. Dom´ınguez Morales 1 Resumen— En este trabajo se eval´ua el uso de un cl´uster local, basado en Raspberry Pi, para el procesado paralelo de im´agenes provenientes de un v´ıdeo. Este cl´uster est´a configurado en una red tipo bus en la que el dispositivo central es un elemento de conmutaci´on (switch) al que se conectan todos los nodos mediante red cableada (ethernet). La sincronizaci´on se lleva a cabo mediante un protocolo as´ıncrono maestro-esclavo en la que una Raspberry Pi funciona como maestro en todas las transacciones utilizando un lenguaje de comunicaci´on basado en MPI (message passing interface). El nodo maestro, disecciona el v´ıdeo a procesar y reparte sus frames entre el resto de nodos que conforman el cl´uster; cada nodo trabaja independientemente aplicando el filtrado correspondiente sobre el frame que posee y retorna los resultados al nodos maestro una vez finalizado el procedimiento. Para evaluar la bondad del cl´uster, se hace uso de un banco de pruebas extenso con diversos tama˜nos y cantidad de im´agenes, controlando los tiempos de transferencia y procesado para cada uno de los casos. Los resultados se obtienen en base a la aceleraci´on obtenida para cada caso, compar´andolo con su versi´on secuencial. Se incluye, adem´as, una comparativa con otros equipos en la que se muestra la mejor´ıa obtenida por el cl´uster. Palabras clave—Paralelismo, cl´uster, MPI, OpenCV, multithreading, Raspberry pi . I. Introducci´ on EN la actualidad, las t´ecnicas de procesamiento de v´ıdeo que se est´an aplicando requieren cada vez de m´as capacidad de c´omputo: casos como Big Data o Deep Learning son prueba de ello. Estas t´ecnicas requieren de gran cantidad de procesamiento de datos para poder funcionar de manera precisa y, para ello, es necesario hacer uso de sistemas de altas prestaciones. Actualmente, la soluci´on aportada pasa por utilizar sistemas distribuidos (ya sea locales o en la nube) para suplir las carencias de un ´unico equipo local. Entidades como la Uni´on Europa han visto en este campo un punto cr´ıtico para no perder el competitividad con el resto del mundo y han situado la supercomputaci´on como objetivo [1], buscando tener el primer ordenador del orden del exa para el a˜no 2026. Para que la Uni´on Europea cumpla sus objetivos es necesario aportar capital humano, y es necesario formar t´ecnicos especializados en el campo de la supercomputaci´on: ser´a un error tener grandes m´aquinas y no tener la gente debidamente cualificada para poder exprimir al m´aximo los equipos con los que est´en trabajando. 1Departamento de Arquitectura y Tecnolog´ıa de Computadores (Universidad de Sevilla). E-mail: [email protected] Sin embargo, esta vertiente conlleva tres problemas importantes: en primera instancia, la potencia el´ectrica requerida para alimentar este tipo de sistemas [2], [3]; como segunda contraposici´on, la portabilidad de los mismos; y, por ´ultimo, el coste necesario para montar un sistema de estas caracter´ısticas [4]. Es, por tanto, necesario ahondar en determinadas alternativas que sean m´as portables y necesiten menor potencia el´ectrica, aunque ello conlleve una reducci´on parcial de su capacidad computacional. De igual forma, y siguiendo la vertiente de la Uni´on Europea, es importante comenzar con la adquisici´on de los conocimientos necesarios para utilizar los sistemas de supercomputaci´on [5]. Todo ello se a´una en este proyecto, el en cual se realiza el dise˜no e implementaci´on de un cl´uster de bajo coste para su uso en tareas de procesamiento con altas necesidades de c´omputo. El resultado del trabajo se puede comparar en cuanto a aceleraci´on, para justificar la conveniencia de hacer uso del cl´uster, y con otros equipos de mayores prestaciones. Por otro lado, y finalizando la justificaci´on del trabajo, aunque el dispositivo que se expone est´e lejos en cuanto a las prestaciones que est´a buscando la Uni´on Europa, es un proyecto que tiene una alta utilidad docente, ya que con ´este se puede introducir al mundo de la supercomputaci´on a personas que no conoc´ıan este campo de la inform´atica [6]. Existen otros trabajos en los que se detalla el montaje y funcionamiento de un cl´uster basado en nodos Raspberry Pi [7], sin embargo se limitan a exponer el montaje y configuraci´on sin llegar a aplicarlo a un caso real [8]. En este trabajo, no se busca exclusivamente ese fin, sino tambi´en comprobar la utilidad y eficiencia del mismo en problemas reales, evaluando los beneficios que ello conlleva [9]. El resto del manuscrito se organiza de la siguiente forma: en la secci´on 2 se describe la arquitectura hardware del sistema implementado; a continuaci´on, se ahonda en las diversas implementaciones software de los algoritmos de procesado; en la secci´on 4 se muestran los resultados obtenidos con las diversas pruebas realizadas; y, finalmente, se exponen las conclusiones del trabajo. II. Descripci´ on del sistema La arquitectura hardware del sistema est´a compuesta por seis sistemas empotrados Raspberry Pi formando una red tipo bus. En ella, todos los nodos est´an conectados a un elemento central de con- 210 Jornadas SARTECO 2019, Septiembre, Cáceres mutaci´on (switch) para compartir la red de comunicaci´on. Aun as´ı, la comunicaci´on se centraliza a trav´es de un nodo maestro, que es el que realiza el procesado y reparto inicial entre el resto de nodos del cl´uster. El usuario se comunica directamente con el nodo maestro, enviando el archivo de v´ıdeo que se pretende procesar. ´este, haciendo uso de la librer´ıa OpenCV, realiza una divisi´on frame a frame y reparte el trabajo entre los diversos nodos mediante una comunicaci´on por paso de mensajes (MPI). Una vez ha realizado el reparto, el nodo maestro no se queda ocioso sino que tambi´en interviene en dicho procesado. Cada nodo posee una implementaci´on m´as sencilla que la que integra el nodo maestro, exclusivamente centrados en la recepci´on de frames, procesado de las mismas mediante OpenCV y devoluci´on de resultados por paso de mensajes. Una vez que el nodo maestro recibe todos los frames procesados, continua con los siguientes hasta finalizar el v´ıdeo. La arquitectura implementada puede observarse en la Figura 1. Fig. 1. Arquitectura hardware del sistema. Como se coment´o anteriormente, cada nodo consiste en una Raspberry Pi: en un trabajo previo, se llev´o a cabo la implementaci´on utilizando Raspberry Pi 2; sin embargo, en esta ocasi´on se hace uso de seis Raspberry Pi 3 B. Se ha seleccionado finalmente este modelo ya que posee mayor capacidad de c´omputo que el modelo anterior: como se puede observar en la Tabla I, la Raspberry Pi 3 B obtiene una aceleraci´on de 3.5 aproximadamente (en torno a un 250% m´as r´apida) respecto a la Raspberry Pi 2 a la hora de procesar las im´agenes. Para hacer esta comparativa, se ha ejecutado un algoritmo de procesamiento sencillo en ambas placas, utilizando varios valores en cuanto al n´umero de im´agenes, y utilizando un tama˜no de imagen fijo de 1 MegaByte. Adem´as de lo anterior, han sido necesarias 6 tarjetas microSD de 16 GigaBytes, 6 cargadores de, al menos, 2.1 amperios y un switch para interconectar todas las placas Raspberry Pi. Todo el sistema ha sido montado sobre unas estructuras superpuestas impresas en 3D (puede observarse en la Figura 2, para facilitar su portabilidad y beneficiar su refrigeraci´on: al comienzo, estos proble- TABLA I Comparaci´ on RBpi2 vs RBpi3B: tiempos de procesado (milisegundos) y aceleraci´ on Im´agenes RBpi2 RBpi3B Acel. Mejora 1 10.54 2.82 3,73 +257% 6 61.84 17.05 3.62 +262% 12 123.48 34.44 3.58 +258% 24 246.51 70.77 3.48 +248% 48 492.04 142.68 3.44 +244% 96 987.31 285.16 3.46 +246% 192 1974.80 568.76 3.47 +247% 196 2015.69 578.23 3.48 +248% mas fueron continuos por el uso de carcasas cerradas para cada placa, ocasionando graves problemas de temperatura que ocasionaban reinicios espor´adicos y reducci´on de frecuencia de reloj. Fig. 2. Cl´uster montado. Para la interconexi´on de las placas hemos usado un switch, en este caso ha sido un D-link DES-1016D de 16 puertos fast ethernet, no hemos necesitado un switch superior ya que las Raspberry pi solo trabajan en fast ethernet , tambi´en ha sido necesario configurar la opciones de red de las Raspberry pi, para ello hemos fijado la direcci´on ip de cada una de ellas, a continuaci´on hemos a˜nadido en el fichero hosts de cada una de ellas las direcciones IP del resto de las Raspberry Pi con el alias que le hemos asignado a cada Raspberry Pi, desde ”master” hasta ”nodo4”; de este modo podemos acceder a cada Raspberry Pi con facilidad. Cada una de las seis Raspberry Pi tiene casi la misma configuraci´on solo cambiamos el nombre que tiene asignado y la ip, con esto ganamos facilidad a la hora de escalar nuestro cl´uster: solo hay que realizar unos peque˜nos cambios que no requieren m´as de 5 minutos. Como las Raspberrys tienen casi la misma configuraci´on para instalar las diferentes herramientas que usamos para analizar las im´agenes, hemos usado una Raspberry Pi en la que hemos realizado todas las instalaciones. El proceso de configuraci´on seguido es el siguiente: Jornadas SARTECO 2019, Septiembre, Cáceres 211 •Instalamos la ´ultima versi´on del sistema operativo propio de Raspberry (Raspbian 9, versi´on simplificada de Debian) [10]. •Instalamos la ´ultima versi´on de Python (3.5) [11]. •Descargamos la versi´on 4.0.1 de OpenCV [12] y la compilamos para nuestra placa: proceso tedioso de m´as de 1 hora, en el que se necesita ampliar la partici´on swap para evitar errores. •Instalamos la herramienta de MPI MPICH en la versi´on 3.3 [13]. Para la siguientes Raspberry Pi hicimos copias de la tarjeta microSD, grab´andola en las restantes tarjetas; proceso que solo requiere de 40 minutos a diferencia del procedimiento original, y de esta forma disponemos 6 sistemas id´enticos. Para que la herramienta de MPI funcione de manera transparente ha sido necesario generar las diferentes claves p´ublicas y transferirlas en el sistema, en nuestro caso la placa m´aster puede acceder de manera transparente al resto de nodos. Seguidamente se expondr´an los algoritmos de procesado utilizados para el cl´uster. III. Procesamiento Esta secci´on se dividir´a en dos sub-secciones: por un lado se analizar´an las tres versiones del algoritmo de procesamiento implementadas; y, por ´ultimo, se describir´a el banco de pruebas utilizado para los resultados. A. Algoritmos Para realizar las diversas pruebas, se han implementado tres versiones del algoritmo de procesamiento: una versi´on secuencial, una versi´on paralela y una versi´on para el cl´uster. El procesamiento a realizar sobre cada una de las im´agenes consiste en una detecci´on de rostros sobre cada uno de los frames, con un pintado posterior del marco alrededor de los rostros detectados. Las caracter´ısticas de las diversas versiones son expuestas a continuaci´on: 1. Versi´on secuencial: implementaci´on del procesamiento exclusivamente en el nodo maestro. Esta versi´on es la m´as sencilla e incluye, exclusivamente, el tratamiento de las im´agenes con OpenCV. Esta versi´on sirve de base sobre la que poder comparar la mejora producida por las versiones siguientes. 2. Versi´on paralela: implementaci´on del procesamiento exclusivamente en el nodo maestro, pero incluyendo librer´ıas de ejecuci´on paralela para poder aprovechar los hilos de ejecuci´on de los que dispone la propia Raspberry Pi 3B. Este modo no produc´ıa mejora alguna en la Raspberry Pi 2, ya que ´esta solo cuenta con un hilo de ejecuci´on. Las librer´ıas de ejecuci´on paralela proveen de dos m´etodos diferentes para ejecutar el multiprocesacimiento. Por un lado tenemos la librer´ıa Pool de ejecuci´on y por otro lado tenemos la librer´ıa Process, la diferencia m´as notable entre ellas es que con la librer´ıa Pool hay que definir el node CPUs que queremos usar, por defecto hemos usado todas las disponibles. Para ver que m´etodo es mejor para resolver nuestro problema, hemos hecho una serie de pruebas comparando la eficiencia en tiempo de cada librer´ıa, comparadas con el tiempo en secuencial. Los datos se muestran en la figura 3. Fig. 3. Visi´on general de los tiempos. Como podemos ver cualquier m´etodo mejora mucho la eficiencia del procesado en secuencial. En la figura 4 podemos apreciar con m´as detalle los valores obtenidos Fig. 4. Detalles de los tiempo de las librer´ıas. TABLA II Tiempos medios de cada librer´ ıa Librer´ıa T.medio(s) Secuencial 152.4806 Pool 2 39.5807 Pool 4 41.2758 Process 39.4426 Como podemos ver en la Tabla II, al usar un Pool con 4 cpus, los tiempos de procesamiento son un 4.2% mayores, por tanto este m´etodo ha sido descartado. Por otro lado, los tiempos entre un Pool con 2 cpus y Process son muy similares 212 Jornadas SARTECO 2019, Septiembre, Cáceres y aunque el m´etodo Process es un 0.35% m´as r´apido que el Pool de 2 CPUs, nos hemos decantado por esta opci´on ya que es m´as estable en el tiempo. 3. Versi´on cl´uster: implementaci´on del procesamiento en todo el cl´uster, incluyendo las librer´ıas de OpenCV para tratamiento local, la librer´ıa de ejecuci´on paralela para aprovechamiento de los hilos de ejecuci´on locales y, finalmente, uso de la librer´ıa de MPI para comunicaci´on por mensajes dentro del cl´uster y poder as´ı aprovechar la potencia de procesamiento que aporta ´este. En nuestro caso el algoritmo que hemos usado es el mismo que hemos desarrollado en la versi´on paralela. Puede observarse el algoritmo de ejecuci´on en la Figura 5. Fig. 5. Diagrama de flujo del algoritmo de procesamiento implementado. B. Banco de pruebas El dispositivo que hemos implementado est´a pensado para procesar tanto v´ıdeo como im´agenes pero, para simplificar las pruebas y focalizar los resultados en el tiempo de procesamiento, hemos supuesto que el v´ıdeo ya se encuentra seccionado en frames, disponiendo el maestro de un directorio con las im´agenes a repartir entre los nodos del cl´uster para que realicen su procesamiento. Los bancos de pruebas juegan con dos aspectos importantes: tama˜no de imagen y n´umero de im´agenes. •Tama˜no de imagen: en este trabajo se han utilizado tres bancos de pruebas diferentes, en los que se hacen uso de im´agenes de 512 KiloBytes, 1 MegaByte y 2 MegaBytes, respectivamente. Con esta variaci´on se pretende evaluar la capacidad de procesado local de cada nodo del cl´uster. •N´umero de im´agenes: en las pruebas, se hace uso de diverso n´umero de im´agenes total a repartir entre todos los nodos del cl´uster. Este n´umero de im´agenes var´ıa entre 6 (una por nodo) y 196. Con este par´ametro se pretende evaluar la incidencia de la comunicaci´on dentro del cl´uster. •Para facilitar la toma de datos se han creado una serie de scripts que automatizan el lanzamiento de las diferentes pruebas. Con esto hemos querido eliminar la necesidad de estar atentos cada vez que terminaba una prueba para poder lanzar la siguiente, con esto hemos conseguido ahorrar a la hora de lanzar las diferentes pruebas, ahorrando con esto tiempo de ejecuci´on, ya que las pruebas se iban lanzando autom´aticamente. •Para obtener unos datos m´as consistente y evitar en la medida de lo posible las posibles interferencias generadas por alg´un proceso lanzado en segundo plano por la m´aquina o posibles problemas a la hora del env´ıo o recepci´on de los mensajes para empezar las pruebas. Para ello hemos decidido lanzar 10 veces cada prueba. •Las pruebas que realizaremos consisten en 3 procesados diferentes, el primero es el an´alisis secuencial de las diferentes bater´ıas de fotos, posteriormente se lanzar´an las pruebas usando la paralelizaci´on usando un Pool de 2 CPUs y finalmente lanzaremos la ejecuci´on en el cl´uster. El diagrama de flujo de estas operaciones lo podemos ver en la Figura 6. Fig. 6. Diagrama de flujo para el lanzamiento de las diferentes pruebas IV. Resultados A continuaci´on se exponen los resultados obtenidos a la hora de ejecutar en el cl´uster descrito en la secci´on 2 los diversos bancos de pruebas descritos en la secci´on 3. Los resultados ser´an analizados en detalle. Como comparativa con un sistema de procesamiento de prop´osito general, en cada prueba se mostrar´an en paralelo los resultados de los diversos algoritmos sobre el cl´uster de Raspberry, as´ı como la implementaci´on sobre un sistema de prop´osito general. Las caracter´ısticas y comparativa de estos dos sistemas pueden observarse en la Tabla III. Jornadas SARTECO 2019, Septiembre, Cáceres 213 TABLA III Descripci´ on del cl´ uster y el port´ atil utilizados en la comparativa Caracter´stica Cl´uster Port´atil Arquitectura ARM 64 bits x86 64 bits Cores 6 2 Threads 24 4 Frecuencia 1,2 Ghz m´ax.3,80 GHz L1 32 KB 128 KB L2 512 KB 512 KB L3 -- 4 MB RAM 6 GB 16 GB Memoria 96 GB 512 GB Potencia 36 w 45 w Las Raspberrys con las que estamos trabajando tienen un microprocesador Quad Core 1.2GHz Broadcom BCM2837 64bit CPU, 1 GigaByte de memoria RAM y conexi´on fast ethernet (hasta 100 Megabits/s). En el microprocesador encontramos 4 n´ucleos Cortex-A53 con un juego de instrucciones de 64bits, cada n´ucleo consta de dos niveles de cach´e. La cach´e L1 es de 32 KiloBytes de memoria y la L2 es de 512 KiloBytes. Al disponer de 6 Raspberry pi, nos encontramos con un sistema de 24 n´ucleos, 6 GigaBytes de memoria principal y 96 GigaBytes de memoria, teniendo un consumo medio de 36 vatios en total. Por otro lado, el port´atil tiene como procesador un chip I7-7560U con dos n´ucleos de procesamiento y 4 hilos, con 3 niveles de cach´e, arquitectura x86 de 64 bits y una frecuencia de reloj variable entre 2,40 Gigahercios y los 3,80 Gigahercios, con una memoria principal de 16 GigaBytes. Te´oricamente, como caso ideal anticip´andonos a los resultados analizados posteriormente, se podr´ıa obtener una aceleraci´on en la paralelizaci´on multihilo local de 4 para la Raspberry (debido a los 4 hilos que posee cada procesador); sin embargo, una versi´on multihilo no es equivalente a un n´ucleo f´ısico y, por lo tanto, no podr´a obtener una aceleraci´on igual que ´este (siendo en este caso imposible alcanzar la aceleraci´on de 4, si bien, en casos extremos de otros procesadores, se ha alcanzado hasta una mejor´ıa en torno al 90-95%). Por otro lado, para el cl´uster se podr´ıa obtener te´oricamente una aceleraci´on m´axima de 24 (4 hilos x 6 nodos = 24 procesos en paralelo; pero, con la anotaci´on anterior, esta aceleraci´on ser´ıa levemente inferior). A continuaci´on, vamos a exponer los resultados obtenidos, separ´andolos en pruebas de 512 Kilo- Bytes, 1 Megabyte y 2 Megabytes.Para las pruebas nos vamos a centrar en los 6 siguientes tiempos: •Tiempo secuencial RPi3: tiempo que necesita una Raspberry pi para procesar las im´agenes con un solo hilo. •Tiempo Pool RPi3: tiempo necesario para que una Raspberry pi procese las im´agenes con las librer´ıas de Pool [14]. •Tiempo cl´uster: tiempo que ha necesitado el cl´uster para procesar las im´agenes. •Tiempo secuencial port´atil: tiempo necesario para que el port´atil para procesar las im´agenes. •Tiempo Pool port´atil: tiempo para procesar usando todos los cores del equipo. Para cada uno de los tama˜no de im´agenes, se utilizan bancos de prueba con un n´umero de im´agenes variable entre 6 y 196 (como se describi´o anteriormente). Se expondr´an en detalle dos casos (96 y 196), dejando el resto de resultados para ser presentados en las conclusiones finales. A. Pruebas con im´agenes de 512 KiloBytes A continuaci´on, se presentan los resultados para 96 im´agenes y para 196 im´agenes. A.1 96 im´agenes Haciendo uso de 96 im´agenes, el nodo maestro distribuye 16 im´agenes a cada nodo del cl´uster. Los resultados pueden apreciarse en la Figura 7 y en la Tabla IV. 0 2 4 6 8 nº de prueba 10 20 30 40 50 60 Tiempo (s) RPi3 secuencial RPi3 paralelo Portátil secuencial Portátil paralelo Clúster Fig. 7. Tiempo para procesar 6 im´agenes de 512 KiloBytes Puede observarse que el tiempo m´as lento es el ocasionado por la ejecuci´on secuencial en la Rapsberry Pi, mientras que los m´as r´apidos son la ejecuci´on paralela en el port´atil i7 y la ejecuci´on en el cl´uster. Por lo tanto, la ejecuci´on en un cl´uster formado por seis sistemas empotrados de bajo coste se asemeja en tiempo de procesamiento a un port´atil de alta gama. TABLA IV Tiempos medios para procesar 96 im´ agenes de 512 KiloBytes Prueba T.medio(s) Secuencial RPi 63.1329 Paralelo RPi 16.7288 Cl´uster RPi 5.0658 Secuencial Port´atil 16.6330 Paralelo Port´atil 4.4372 A.2 196 im´agenes Haciendo uso de 196 im´agenes, el nodo maestro distribuye 32-33 im´agenes a cada nodo del cl´uster. 214 Jornadas SARTECO 2019, Septiembre, Cáceres Los resultados pueden apreciarse en la Figura 8 y en la Tabla V. 0 2 4 6 8 nº de prueba 20 40 60 80 100 120 Tiempo (s) RPi3 secuencial RPi3 paralelo Portátil secuencial Portátil paralelo Clúster Fig. 8. Tiempo para 196 im´agenes Pueden observarse datos similares al caso anterior pero, en esta ocasi´on, el procesamiento en el cl´uster mejora al procesamiento paralelo en el port´atil. TABLA V Tiempos medios de cada prueba Prueba T.medio(s) Secuencial RPi 128.8424 Paralelo RPi 34.1776 Cl´uster RPi 8.4022 Secuencial Port´atil 34.1042 Paralelo Port´atil 8.8087 B. Pruebas con im´agenes de 1 MegaBytes Las pruebas de 1 MegaByte, siguiendo el mismo procedimiento que el apartado anterior, han quedado desgranadas de las siguiente manera: B.1 96 im´agenes 0 2 4 6 8 nº de prueba 0 50 100 150 200 250 300 Tiempo (s) RPi3 secuencial RPi3 paralelo Portátil secuencial Portátil paralelo Clúster Fig. 9. Tiempo para 96 im´agenes En esta prueba, la brecha existente entre la versi´on del cl´uster y la del port´atil en paralelo empiezan a distanciarse en beneficio para el cl´uster. TABLA VI Tiempos medios de cada prueba Prueba T.medio(s) Secuencial RPi 285.1640 Paralelo RPi 82.6224 Cl´uster RPi 13.6330 Secuencial Port´atil 64.9961 Paralelo Port´atil 16.8791 B.2 196 im´agenes 0 2 4 6 8 nº de prueba 0 100 200 300 400 500 600 700 Tiempo (s) RPi3 secuencial RPi3 paralelo Portátil secuencial Portátil paralelo Clúster Fig. 10. Tiempo para procesar 196 im´agenes de 1 MegaByte Es importante incidir aqu´ı, m´as all´a del aumento de la brecha entre cl´uster y port´atil paralelo, en el hecho de que empezamos a observar aceleraciones muy cercanas al l´ımite te´orico. Observando en la Tabla VII, la media de las pruebas realizadas en la versi´on secuencial de la Raspberry Pi alcanza los 578 segundos, mientras que la media de la versi´on del cl´uster se encuentra en torno a 25 segundos, lo que hace una aceleraci´on de 23. TABLA VII Tiempos medios de cada prueba Prueba T.medio(s) Secuencial RPi 578.2312 Paralelo RPi 212.7740 Cl´uster RPi 25.0851 Secuencial Port´atil 129.8317 Paralelo Port´atil 34.4065 C. Pruebas con im´agenes de 2 MegaBytes Las pruebas de 2 MegaBytes han arrojado los siguientes valores: Jornadas SARTECO 2019, Septiembre, Cáceres 215 C.1 96 im´agenes 0 2 4 6 8 nº de prueba 0 100 200 300 400 500 Tiempo (s) RPi3 secuencial RPi3 paralelo Portátil secuencial Portátil paralelo Clúster Fig. 11. Tiempo para 6 im´agenes de 2 MegaBytes Puede observarse que se sigue manteniendo la relaci´on entre la versi´on cl´uster y la versi´on secuencial, con una aceleraci´on superior a 22. TABLA VIII Tiempos medios de cada prueba Prueba T.medio(s) Secuencial RPi 481.9434 Paralelo RPi 154.3420 Cl´uster RPi 21.5393 Secuencial Port´atil 103.3272 Paralelo Port´atil 27.0354 C.2 196 im´agenes 0 2 4 6 8 nº de prueba 0 100 200 300 400 500 600 700 Tiempo (s) RPi3 secuencial RPi3 paralelo Portátil secuencial Portátil paralelo Clúster Fig. 12. Tiempo para 196 im´agenes En este ´ultimo caso, se da un efecto peculiar: la relaci´on mantenida en casos anteriores se desploma hasta bajar a una aceleraci´on de 19. Esta circunstancia, aunque no sea analizada en profundidad, se obtiene de la capacidad de la memoria cach´e de las Raspberry, lo cual provoca mayor cantidad de fallos y accesos a memoria principal (repercutiendo directamente en el tiempo de ejecuci´on). TABLA IX Tiempos medios de cada prueba Prueba T.medio(s) Secuencial RPi 878.6915 Paralelo RPi 402.5430 Cl´uster RPi 46.1513 Secuencial Port´atil 213.1103 Paralelo Port´atil 55.2972 Tras los resultados expuestos, se puede observar que la aceleraci´on obtenida al ejecutar el algoritmo de procesamiento de v´ıdeo en el cl´uster se acerca a la aceleraci´on ideal de 24 en casos puntuales, teniendo problemas derivados con la capacidad de memoria en los dispositivos en tama˜nos y n´umero de im´agenes elevados. Finalmente se expondr´an las conclusiones de este trabajo. V. Conclusiones En este trabajo se ha configurado, implementado y testeado un conjunto de m´aquinas Linux para poder trabajar de manera conjunta en un cl´uster de procesamiento de v´ıdeo. Se han implementado diversos algoritmos de procesamiento (tanto local como distribuidos) para optimizar el tiempo de procesamiento del cl´uster. A continuaci´on, en la Figura 13, se muestra una gr´afica resumen donde se puede visualizar la aceleraci´on media obtenida para todas las combinaciones de casos evaluados: entre 6 y 196 im´agenes con tama˜nos entre 512 KiloBytes y 2 MegaBytes. Fig. 13. Aceleraci´on Global del cl´uster Como se ha podido observar, no siempre el uso del cl´uster optimiza el tiempo de ejecuci´on del procesamiento; ya que, para im´agenes peque˜nas, entra en juego el tiempo de transmisi´on, que es un factor que 216 Jornadas SARTECO 2019, Septiembre, Cáceres no se ha tenido en cuenta y que se diluye a medida que aumenta la carga computacional del cl´uster. A medida que el n´umero de im´agenes aumenta, la mejor´ıa del cl´uster se hace notar frente a su versi´on en secuencial, obteniendo m´aximos cercanos al ideal (aceleraci´on de 23 frente al m´aximo te´orico de 24). En cuanto a la comparativa con el port´atil utilizado puede observarse que, en todo momento, la aceleraci´on obtenida por la versi´on cl´uster del algoritmo es igual o mejor en tiempo de ejecuci´on que la versi´on paralelizada del algoritmo ejecutado en el procesador i7 del port´atil; esto demuestra la potencia de procesado de este tipo de dispositivos dentro de un cl´uster de bajo coste. Agradecimientos Este trabajo ha sido desarrollado y financiado dentro del grupo de investigaci´on ”TEP-108: Rob´otica y Tecnolog´ıa de Computadores” de la Universidad de Sevilla. Referencias [1] Norbert Attig, Paul Gibbon, and Th Lippert, “Trends in supercomputing: The european path to exascale,” Computer Physics Communications, vol. 182, no. 9, pp. 2041– 2046, 2011. [2] Zhonghong Ou, Bo Pang, Yang Deng, Jukka K Nurminen, Antti Yla-Jaaski, and Pan Hui, “Energy-and costefficiency analysis of arm-based clusters,” in Proceedings of the 2012 12th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (ccgrid 2012). IEEE Computer Society, 2012, pp. 115–123. [3] Giorgio Luigi Valentini, Walter Lassonde, Samee Ullah Khan, Nasro Min-Allah, Sajjad A Madani, Juan Li, Limin Zhang, Lizhe Wang, Nasir Ghani, Joanna Kolodziej, et al., “An overview of energy efficiency techniques in cluster computing systems,” Cluster Computing, vol. 16, no. 1, pp. 3–15, 2013. [4] Marcos Dias De Assun¸c˜ao, Alexandre Di Costanzo, and Rajkumar Buyya, “Evaluating the cost-benefit of using cloud computing to extend the capacity of clusters,” in Proceedings of the 18th ACM international symposium on High performance distributed computing. ACM, 2009, pp. 141–150. [5] Kevin Doucet and Jian Zhang, “Learning cluster computing by creating a raspberry pi cluster,” in Proceedings of the SouthEast Conference. ACM, 2017, pp. 191–194. [6] S´ebastien Varrette, Pascal Bouvry, Hyacinthe Cartiaux, and Fotis Georgatos, “Management of an academic hpc cluster: The ul experience,” in 2014 International Conference on High Performance Computing & Simulation (HPCS). IEEE, 2014, pp. 959–967. [7] Maik Schmidt, Raspberry Pi: a quick-start guide, Pragmatic Bookshelf, 2014. [8] Joshua Kiepert, “Creating a raspberry pi-based beowulf cluster,” Boise State University, pp. 1–17, 2013. [9] Michael Cloutier, Chad Paradis, and Vincent Weaver, “A raspberry pi cluster instrumented for fine-grained power measurement,” Electronics, vol. 5, no. 4, pp. 61, 2016. [10] William Harrington, Learning Raspbian, Packt Publishing Ltd, 2015. [11] Travis E Oliphant, “Python for scientific computing,” Computing in Science & Engineering, vol. 9, no. 3, pp. 10–20, 2007. [12] Gary Bradski and Adrian Kaehler, Learning OpenCV: Computer vision with the OpenCV library, ” O’Reilly Media, Inc.”, 2008. [13] William D Gropp, William Gropp, Ewing Lusk, and Anthony Skjellum, Using MPI: portable parallel programming with the message-passing interface, vol. 1, MIT press, 1999. [14] Navtej Singh, Lisa-Marie Browne, and Ray Butler, “Parallel astronomical data processing with python: Recipes for multicore machines,” Astronomy and Computing, vol. 2, pp. 1–10, 2013. Jornadas SARTECO 2019, Septiembre, Cáceres 217