ISSN 1698 - 7418 Depósito Legal PP200402CA1617 FARAUTE Ciens. y Tec., 5(1): 47-58, 2010 ADAPTACIÓN DEL DRIVER DE LA TARJETA DE RED D-LINK DGE-530T PARA GAMMA D-Link DGE-530T Network Interface Card Driver Adaptation for GAMMA KIARA A. OTTOGALLI F., DANIEL H. ROSQUETE DE M., AMADÍS A. MARTÍNEZ M. y FREDDY J. PEROZO R. Departamento de Computación Facultad Experimental de Ciencias y Tecnología. Universidad de Carabobo Valencia, Estado Carabobo, Venezuela {kottogal, dhrosquete, aamartin, fperozo}@uc.edu.ve Fecha de Recepción: 08/07/2009, Fecha de Revisión: 16/06/2010, Fecha de Aceptación: 30/07/2010 Resumen Un cluster es un sistema de computo formado por varios computadores con hardware similar, que se comunican a través de una red de alta velocidad, que funciona como un único computador. Se puede construir un cluster de PCs, pero la velocidad de comunicación entre sus nodos es notablemente menor en comparación a la de un cluster especializado de alto costo, debido al uso de controladores (drivers) no especializados para tarjetas (Gigabit) en cluster que utilizan la pila de protocolos TCP/IP. En este artículo se describe la adaptación de un controlador para la NIC (Network Interface Card) D-Link DGE-530T compatible con GAMMA (Genoa Active Message MAchine) y los resultados que comprueban que dicho controlador mejora el rendimiento del cluster de bajo costo del Departamento de Computación de la FaCyT-UC, denominado Mangosta. Palabras clave: Cluster, Driver, GAMMA, Optimización de comunicaciones, Tarjetas de red. Abstract A cluster is a computer system formed by several computers with similar hardware, which maintains the communication among them through a high-speed network, working together as a single integrated resource. It is possible to built a cluster of PCs, but the communication speed among its nodes is considerably slower compared with the communication speed of a high-cost specialized one due to the use of non-specialized (Gigabit) network card drivers that uses the TCP/IP protocol stack for communication purposes. In this article are described the adaptation of a D-Link DGE-530T NIC (Network Interface Card) driver compatible with GAMMA (Genoa Active Message MAchine) and the tests that con? rm that the driver improves the performance of the low-cost cluster of the Department of Computer Science of the FaCyT-UC, known as Mangosta. Keywords: Cluster, Communication optimization, Driver, GAMMA, Network card. 47 Adaptación del Driver de la Tarjeta de Red D-Link DGE-530t para Gamma 1. Introducción Un cluster es un conjunto de máquinas interconectadas que trabajan de forma colectiva para procesar instrucciones y datos (Morrison, 2003), y su representación es la de un sistema unificado, es decir, el número de máquinas que conforman un cluster es transparente al usuario. Uno de los requerimientos que se debe tomar en cuenta al construir un cluster es que todos los nodos deben completar una tarea paralela de forma simultánea. Para ello, deben tener hardware y software con características similares, de lo contrario, el nodo más lento podría generar un retardo en el tiempo total de procesamiento. Específicamente, si se tienen nodos con tarjetas de red que ofrecen tasas de transmisión menores que los demás, se produce una latencia injustificada. En la actualidad existen compañías tales como IBM, HP, Sun Microsystems y Microsoft, que han lanzado al mercado clusters (IBM System Cluster 1350, IBM System Cluster 1600, HP Cluster Platform 4000BL, HP Cluster Platform 6000 y 6000BL) con hardware y software especializado (Solaris Cluster, Microsoft Cluster Server) para el procesamiento de datos de manera rápida y eficiente. Uno de los inconvenientes con este tipo de equipos especializados es su alto costo, por esto se han creado alternativas de bajo costo, como los clusters de PCs (Personal Computers), pero estos usan para comunicarse la pila de protocolos TCP/IP (Transmission Control Protocol/Internet Protocol). El modelo TCP/IP está formado por un conjunto de capas que se encargan de la transmisión confiable de datos de un emisor a un receptor por medio de un canal. Cuando el nodo emisor desea transmitir un conjunto de datos, cada capa del modelo TCP/IP le agrega ciertos datos de control antes de transmitirlos a una capa inferior. Análogamente, los datos de control agregados por el nodo emisor deben ser procesados y eliminados en el 48 FARAUTE Ciens. y Tec., 5(1). 2010 nodo receptor, por cada capa del modelo TCP/IP, antes de ser enviados a una capa superior. Este proceso genera un tiempo de latencia importante tanto en el nodo emisor como en el nodo receptor (Tanenbaum, 2003). Estos datos de control son necesarios en redes de computadores que están a grandes distancias, pero en el caso de un cluster dejan de ser necesarios y pasan a ser factores de disminución en el rendimiento del mismo. Una forma de optimizar la transmisión de datos en un cluster, consiste en eliminar la pila de protocolos del modelo TCP/IP y utilizar protocolos ligeros, los cuales sustituyen parte o la totalidad de la pila de protocolos TCP/IP y tienen como objetivos: (1) hacer más eficiente el proceso de comunicación entre los nodos del cluster, (2) reducir la latencia de comunicación y (3) permitir un mejor aprovechamiento del ancho de banda que ofrece la red. Genoa Active Message Machine (GAMMA) (Chiola & Ciaccio, 1997) es una capa de comunicaciones, de baja latencia y alta tasa de transmisión de datos, implementada a nivel de kernel, diseñada para clusters de PCs, que utiliza protocolos ligeros para sustituir la pila de protocolos del modelo TCP/IP. Debido a las características de GAMMA, se decidió incorporarlo al cluster de PCs de bajo costo del Departamento de Computación de la Facultad Experimental de Ciencias y Tecnología (FaCyT) de la Universidad de Carabobo (UC), denominado Mangosta. Sin embargo, este cluster cuenta con tarjetas de red Gigabit D-Link DGE-530T, anteriormente no soportadas por GAMMA. En este artículo se describe la adaptación de un driver (controlador) compatible con GAMMA para la tarjeta de red D-Link DGE-530T. Además, se presentan diversas pruebas realizadas en el cluster Mangosta, en las cuales se demuestra que la incorporación de GAMMA disminuyó la latencia en la comunicación, aumentó la velocidad de Kiara A. Ottogalli F., Daniel H. Rosquete De M., Amadís A. Martínez M. y Freddy J. Perozo R. transmisión de datos y, en consecuencia, mejoró el desempeño general del cluster. Este artículo fue estructurado en seis secciones, incluyendo la introducción. En la Sección 2 se describen brevemente los antecedentes de este trabajo. En la Sección 3 se introducen conceptos fundamentales relacionados con cluster computing y drivers de red. En la Sección 4 se describe el desarrollo del driver en dos partes: (1) adaptación del driver de red a GAMMA y (2) desarrollo de la Application Programming Interface (API) de GAMMA. En la Sección 5 se muestran los resultados experimentales obtenidos mediante las pruebas realizadas sobre el cluster Mangosta. Finalmente, la Sección 6 contiene las conclusiones del artículo y trabajos futuros. 2. Antecedentes 2.1. Active Messages Active Messages es un mecanismo simple y asíncrono de comunicación que permite solapar la comunicación con el cómputo, aprovechando la flexibilidad y el desempeño de las interconexiones de las redes modernas, logrando así un equilibrio costo/efectivo del uso del hardware y reduciendo la sobrecarga en la comunicación (Von Eicken et al., 1992). Bajo este modelo, cada nodo lleva a cabo una tarea que es interrumpida por la llegada de un mensaje. Por cada mensaje se especifica un manejador de mensajes que sirve para extraer el mensaje de la red e incorporarlo en el procesamiento que se está llevando a cabo. La eficiencia de este modelo se debe a la eliminación de buffers intermedios, la programación simple del manejador de mensajes no suspensivo y el solapamiento de la comunicación y el cómputo. 2.2. U-Net U-Net (Von Eicken et al., 1995) es una arquitectura para la comunicación a nivel de usuario, sobre una plataforma de hardware offthe-shelf, con un sistema operativo estándar. UNET elimina al kernel del camino de comunicación para ofrecer más flexibilidad, proveer baja latencia en la comunicación y explotar por completo el ancho de banda de la red. Proporciona a los procesos una vista virtual del dispositivo de red, de forma tal que se crea la ilusión de que cada proceso es propietario del mismo. 2.3. Virtual Interface Architecture (VIA) Virtual Interface Architecture (VIA) (Von Eicken et al., 1998) es un estándar para los paradigmas de comunicación, influenciado por U-NET, cuyo diseño se enfoca en brindar baja latencia y uso eficiente del ancho de banda en un cluster. Para lograr lo expuesto anteriormente, VIA define un conjunto de funciones, estructuras de datos y semánticas asociadas al acceso directo a la interfaz de red, evade el paso por el kernel y la utiliza el Remote Direct Memory Access (RDMA). 2.4. GenoaActive Message Machine (GAMMA) GAMMA es una capa de comunicaciones basada en Active Messages (Chiola & Ciaccio, 1997), de baja latencia y alta tasa de transmisión de datos (Chiola & Ciaccio, 1998), implementada a nivel de kernel y diseñada para clusters de PCs, la cual utiliza protocolos ligeros para sustituir la pila de protocolos del modelo TCP/IP (Fig. 1 Chiola & Ciaccio, 1996). GAMMA ha demostrado superioridad ante otras aproximaciones, entre ellas U-NET y VIA (Chiola & Ciaccio, 1999), con lo cual se ha demostrado que no es necesario eliminar al kernel del camino de comunicación de datos para explotar eficientemente los dispositivos de comunicación. FARAUTE Ciens. y Tec., 5(1). 2010 49 Adaptación del Driver de la Tarjeta de Red D-Link DGE-530t para Gamma Fig. 1. Modelo de GAMMA Las características más importantes de GAMMA son: optimizaciones en el camino de comunicación (por ejemplo el uso de cero copias), llamadas ligeras al sistema, que guardan sólo un subconjunto de los registros de máquina y no invocan al planificador y el uso del camino de interrupción rápida (Fast Interrupt Path) que es un camino codificado y optimizado al manejador de interrupciones del driver de red. El primer prototipo de GAMMA fue criticado por su falta de portabilidad, pero este problema fue resuelto al incorporar MPI (Message Passing Interface) a GAMMA (Chiola & Ciaccio, 1999). 2.5. CLIC CLIC (Díaz et al., 2003) es un protocolo ligero, el cual reduce el tiempo de latencia y aumenta el uso del ancho de banda. CLIC está incrustado en el kernel de Linux, reemplaza la pila de protocolos TCP/IP, reduce el número de capas de protocolos, lo cual reduce la sobrecarga producida por los mismos, y provee una interfaz entre el controlador de la tarjeta de red y las aplicaciones de usuario. Sin embargo, no se ha reportado continuidad de este proyecto desde el año 2003. 3. Definiciones Previas 3.1. Cluster Computing Es una rama especifica de la computación de 50 FARAUTE Ciens. y Tec., 5(1). 2010 alto rendimiento cuyo componente principal es el cluster, el cual es un conjunto de máquinas interconectadas que trabajan de forma colectiva para procesar instrucciones y datos provenientes de un software que posee altos requerimientos. Una clasificación de clusters por su tipo de arquitectura es la siguiente (Morrison, 2003): (1) Cluster de PCs o Pila de PCs, (2) Cluster of Work-stations (COW) y Network of Workstations (NOW) y (3) Workstation Farm (Granja de Estaciones de Trabajo). Este artículo se enfocará en el cluster de PCs tipo Beowulf, ya que el cluster Mangosta de la FaCyT pertenece a esta clasificación. Un cluster tipo Beowulf es un sistema formado por un conjunto de PCs bajo la arquitectura cliente/servidor (Morrison, 2003), en el cual existen dos tipos de nodos: (1) los nodos cliente, que conforman una red local a la cual no se puede acceder directamente y (2) un nodo servidor, que es una estación de trabajo desde la cual se maneja todo el cluster, y normalmente el único nodo con conexión a Internet. 3.2. El Driver de Red La función de un driver de red consiste en manejar una interfaz de red y hacer que sea posible el intercambio de paquetes entre un host y la red. Un driver de red en Linux, normalmente se carga como un módulo del kernel y hace petición de recursos (memoria e interrupciones) así como también ofrece servicios. El núcleo de un driver de red es una estructura de tipo net_device que describe cada interfaz de red, ya que contiene todos sus datos (nombre y MTU, entre otros) así como también apuntadores a las funciones que actúan sobre la misma. Todo módulo, incluyendo un driver de red, debe tener al menos dos operaciones básicas: Una operación para cargar el módulo y una operación para remover el módulo. La operación para cargar el driver de red, se encarga de: (1) verificar la existencia y el estado del dispositivo de red, (2) Kiara A. Ottogalli F., Daniel H. Rosquete De M., Amadís A. Martínez M. y Freddy J. Perozo R. hacer petición de recursos, (3) inicializar el módulo y (4) registrarlo en el kernel. La operación para remover el driver de red se encarga de descargar el módulo del kernel para que ya no pueda ser utilizado. Estas operaciones deben ser proporcionadas como parámetros a dos funciones estándar para el manejo de los módulos del kernel de Linux, module_init y module_exit. Además de las operaciones básicas, un driver de red debe ofrecer servicios para que la tarjeta de red pueda ser utilizada. Algunos de los servicios que ofrece, de acuerdo con su nombre est´ andar dentro de la estructura net_device del kernel de Linux, son los siguientes (Corbet et al., 2005): open: Se encarga de registrar todos los recursos que necesite el dispositivo de red (puertos I/O, IRQ, DMA, entre otros) y habilitar la tarjeta de red. stop: Detiene la interfaz de red y revierte las operaciones hechas durante open. 4. Implementación de la Solución Para incorporar GAMMA al cluster Mangosta, se precisó el desarrollo de un driver compatible con dicha capa de comunicaciones. Se tomó como base el driver skge del kernel de Linux en su versión 2.6.18.1, el cual brinda soporte a las tarjetas de red Gigabit Ethernet de SysKonnect y las tarjetas de red con familia de chips Marvell Yukon 1, conjunto al cual pertenece la tarjeta de red Gigabit Ethernet D-Link DGE- 530T, presente en cada nodo del cluster (Ottogalli, 2007). Para desarrollar un driver compatible con GAMMA fue necesario completar dos fases: adaptación del driver de red a GAMMA (Subsección 4.1) y desarrollo del API de GAMMA (Subsección 4.2). 4.1. Adaptación del Driver de Red a GAMMA Para lograr adaptar el driver skge a GAMMA, se modificaron las operaciones principales para cargar y remover el módulo además de las primitivas de servicio open, stop, hard_start_xmit, poll y ethtool_opsdescritas en la Subsección 3.2. hard start xmit: Inicia la transmisión de un paquete. poll: Se encarga de mantener la interfaz en modo de polling para la recepción, con las interrupciones deshabilitadas. ethtool ops: Es una operación de soporte para ethtool, que es una utilidad para controlar el funcionamiento de una interfaz de red. Este apuntador debe ser colocado a través del macro SET_ETHTOOL_OPS. Finalmente, se puede nombrar una función que no forma parte de la estructura net_device, pero que es necesaria para el funcionamiento de un driver de red: la función encargada de las interrupciones, cuyo identificador no es estándar; por lo tanto, se proporciona como parámetro cuando se realiza el registro de interrupciones durante la función open. El driver skge utiliza unas estructuras de datos llamadas rings para la transmisión y la recepción de datos (Fig. 2). Un ring es una lista circular simplemente enlazada, donde cada elemento que la constituye contiene un buffer en el cual se copia un paquete que va a ser procesado. Cada ring se maneja Fig. 2. Ring del driver skge FARAUTE Ciens. y Tec., 5(1). 2010 51 Adaptación del Driver de la Tarjeta de Red D-Link DGE-530t para Gamma a través de tres apuntadores: start, que representa la primera posición del ring, to_clean, que representa la primera posición llena del ring, y to_use, que representa la primera posición vacía del ring, es decir, donde se guardará un nuevo paquete. Con el driver skge original, una aplicación que necesita transmitir datos genera una llamada al kernel del sistema operativo, luego, éste se encarga de procesar dichos datos mediante la pila de protocolos TCP/IP y hace una llamada a la función de transmisión del driver de red, la cual se encarga de encolar los paquetes en el ring de transmisión y enviar una señal a la tarjeta de red para que transmita esos paquetes. Por último la tarjeta de red, al finalizar la transmisión de los datos, genera una interrupción para limpiar el ring de transmisión. El proceso de transmisión del driver skge modificado elimina tanto al kernel como al driver del camino de datos, logrando que una aplicación que necesite transmitir datos pueda realizar una llamada ligera (lightweight call), la cual es atendida por GAMMA, que se encarga de procesar los datos, encolarlos en el ring de transmisión y vaciarlo si es necesario y luego enviar una señal a la tarjeta de red para que transmita. Como se puede observar en el proceso de transmisión de datos con GAMMA se elimina el cambio de con texto (modo usuario a modo núcleo) al igual que las interrupciones de transmisión. El proceso de recepción del driver skge original también sufrió cambios, ya que ahora el driver debía ser capaz de manejar el tráfico de paquetes GAMMA. Con el driver skge original cuando se recibe un paquete, la tarjeta de red genera una interrupción de recepción, la cual es atendida por el kernel del sistema operativo. El kernel se encarga de invocar a la función encargada del manejo de interrupciones propia del driver de red, la cual encola los paquetes recibidos en el ring de recepción y envía una señal al kernel para que éste 52 FARAUTE Ciens. y Tec., 5(1). 2010 entregue los paquetes a una aplicación. Con el driver skge modificado, al igual que con el original, la tarjeta de red genera una interrupción de recepción al recibir un paquete, la cual es atendida por el kernel del sistema operativo, el cual se encarga de invocara la función encargada del manejo de interrupciones. La diferencia está en que el driver modificado redirige la fase de recepción a GAMMA, que procesa los paquetes y los copia directamente en el espacio de memoria de la aplicación. 4.2. Desarrollo de la API (Application Programming Interface) de GAMMA La API de GAMMA está constituida por un conjunto de operaciones que se encargan de actuar como una interfaz entre el driver de red modificado para GAMMA y el protocolo de comunicación de GAMMA. Esta API contiene macros para la transmisión y recepción de paquetes con GAMMA. Los macros de transmisión se hacen cargo de cuatro operaciones fundamentales: (1) colocar el paquete en el ring de transmisión, (2) actualizar el apuntador to_use del ring de transmisión a la siguiente posición vacía, (3) enviar una señal a la tarjeta de red para que transmita dicho paquete y (4) limpiar el ring una vez terminada la transmisión. Los macros de recepción se encargan de separar los paquetes IP de los paquetes GAMMA y redirigir estos últimos para ser manejados en el núcleo de GAMMA. Para verificar el tipo de paquete recibido, se desarrolló una macro que verifica el header del mismo. Si es un paquete IP, es procesado por una macro que realiza la recepción de la misma forma en que lo hace el driver original. Si es un paquete GAMMA, es procesado en el núcleo de GAMMA, el cual luego utiliza una macro que se encarga de vaciar el ring de recepción, para que sus posiciones puedan reutilizarse. Kiara A. Ottogalli F., Daniel H. Rosquete De M., Amadís A. Martínez M. y Freddy J. Perozo R. 5. Resultados Experimentales 5.1. Con?guración de los Experimentos Todas las pruebas fueron realizadas sobre el cluster Mangosta, bajo el mismo sistema operativo y con el mismo kernel de Linux, para tener un criterio de comparación equitativo. Mangosta fue instalado como un cluster dedicado de alto rendimiento tipo Beowulf, el cual provee una arquitectura escalable de múltiples computadoras, que puede ser usada para realizar cómputo paralelo y distribuido (Perozo, 2006). Las características de los nodos del cluster Mangosta, se presentan a continuación: Hardware: procesador Intel Pentium 4 de 3.0 GHz, 1 GigaByte (GB) de memoria RAM, disco duro de 40GB@7200 RPM, una NIC Gigabit Ethernet D-Link DGE-530T dedicada a la comunicación entre procesos con MPI, una NIC Fast Ethernet para administración y servicios para los nodos y una NIC Fast Ethernet dedicada para la conexión a Internet (sólo el frontend). Todos los nodos están conectados a un switch Linksys Gigabit Ethernet capa 2 de 24 puertos. Software: sistema operativo Linux CentOS5 con Kernel 2.6.18.1 (uno original y uno optimizado para GAMMA), Message Passing Interface MPICH versión 1.2.7p1, versión portable de la librería de paso de mensajes MPI, GAMMA y MPI/GAMMA. 5.2. Pruebas Se realizaron diversos tipos de pruebas tanto para probar el funcionamiento del driver skge modificado para GAMMA, como para comparar el desempeño del cluster Mangosta antes y después de la incorporación de GAMMA. Las pruebas realizadas se pueden dividir en dos categorías respectivamente: (1) Pruebas de funcionalidad con GAMMA y (2) Pruebas comparativas entre MPI/GAMMA (MPI sobre GAMMA), MPI/TCP/IP (MPI sobre TCP/IP) y TCP/IP. Para todas las pruebas se utilizó el tamaño estándar del paquete de red para redes Ethernet, es decir, una MTU (Maximum Transfer Unit) de 1500 Bytes. 5.2.1. Pruebas de Funcionalidad con GAMMA Para realizar las pruebas de funcionalidad se utilizó una aplicación que se usa por defecto para medir la latencia de una red, Ping Pong. En un principio se tomaron sólo dos nodos del cluster Mangosta, no conectados al switch, con los cuales se obtuvo una latencia de 9,4µs. Posteriormente en dos nodos del cluster Mangosta conectados al switch, se determinó que la latencia utilizando TCP/IP fue de 58µs, mientras que la latencia obtenida con GAMMA fue de 11,97µs. Con los datos obtenidos en dos nodos conectados al switch, se puede concluir que la disminución de la latencia de la red obtenida con GAMMA, fue de un 79,35% con respecto a la latencia obtenida con TCP/IP. 5 . 2 . 2 . P r u e b a s C o m p a r a t i v a s e n t re MPI/GAMMA, MPI/TCP/IP y TCP/IP Para realizar las pruebas de rendimiento se utilizaron, además de Ping Pong, dos herramientas ampliamente conocidas: NetPIPE y HPL (High Performance Linpack) (Petitet & Dongarra, 2004; Snell et al., 1996). Al realizar las mediciones mediante Ping Pong, se obtuvo una latencia de 35,5µs con MPI/TCP/IP, mientras que con MPI/GAMMA se obtuvo una latencia de 14,6µs, es importante notar que al contrario de lo que se espera, la latencia obtenida mediante Ping Pong con TCP/IP es mayor a la obtenida con MPI, debido a que este último, pese a que hace uso de TCP/IP, maneja estructuras de memoria (caché y buffers) las cuales utiliza para FARAUTE Ciens. y Tec., 5(1). 2010 53 Adaptación del Driver de la Tarjeta de Red D-Link DGE-530t para Gamma mejorar las comunicaciones. Por esta razón los resultados con MPI son mejores que los obtenidos con el uso de TCP/IP en este caso. Los resultados obtenidos con Ping Pong demuestran que el uso de MPI/GAMMA disminuye la latenciade la red en un 58,87% con respecto a la latencia de la red obtenida con MPI/TCP/IP. Con respecto a la velocidad de transmisión, se hicieron cuatro pruebas con Ping Pong en dos nodos del cluster Mangosta: (1) Ping Pong asíncrono con MPI/TCP/IP, (2) Ping Pong asíncrono con MPI/GAMMA, (3) Ping Pong asíncrono bidireccional con MPI/TCP/IP y finalmente (4) Ping Pong asíncrono bidireccional con MPI/GAMMA (al ejecutar Ping Pong asíncrono bidireccional el emisor envía mensajes de cierto tamaño en Bytes al receptor y al mismo tiempo el receptor envía mensajes del mismo tamaño en Bytes al emisor, por esta razón, en los resultados obtenidos con Ping Pong asíncrono bidireccional se ve reducida la velocidad de transmisión aproximadamente a la mitad en comparación con los resultados obtenidos con Ping Pong asíncrono). Con Ping Pong asíncrono con MPI/TCP/IP se obtuvo una velocidad máxima de transmisión de 498,37 Mbps mientras que, con MPI/GAMMA se obtuvo una velocidad máxima de transmisión de 729,08 Mbps. Asimismo, con Ping Pong asíncrono bidireccional con MPI/TCP/IP se obtuvo una velocidad máxima de transmisión de 272,64 Mbps mientras que, con MPI/GAMMA se obtuvo una velocidad máxima de transmisión de 367,98 Mbps (Fig. 3). Los resultados obtenidos indican que la velocidad de transmisión máxima obtenida mediante Ping Pong asíncrono con MPI/GAMMA es un 46,29% mayor que la velocidad obtenida con MPI/TCP/IP y la velocidad de transmisión máxima obtenida a través de Ping Pong asíncrono bidireccional con MPI/GAMMA es un 34,96% mayor a la obtenida con MPI/TCP/IP. 54 FARAUTE Ciens. y Tec., 5(1). 2010 Fig. 3. Velocidad de transmisión obtenida con Ping Pong. NetPIPE es una herramienta de medición de rendimiento independiente del protocolo de comunicaciones, que calcula la velocidad de transmisión de un nodo emisor a un nodo receptor de mensajes de diferentes tamaños, así como la latencia total de la comunicación, como la mayoría de los mensajes enviados por NetPIPE tienen tamaños mayores a la MTU, estos deben ser divididos en paquetes más pequeños. La latencia total es la suma de todos los tiempos de latencia producidos durante el procesamiento de todos los paquetes que forman un mensaje. El tiempo de latencia medido a través de NetPIPE para mensajes de un Byte fue de 33,3 µs para MPI/TCP/IP, 23,81 µs para TCP/IP y 12,9µs para MPI/GAMMA. La latencia obtenida mediante el uso de MPI/GAMMA para paquetes de 1 Byte constituye un 54,17% de la obtenida con TCP/IP y un 38,73% de la latencia obtenida con MPI (Fig. 4). Al ver el aumento de la latencia total obtenida durante la ejecución de NetPIPE para mensajes grandes (hasta 131,069 Bytes), se puede notar que la línea que representa la latencia total obtenida con MPI/GAMMA se mantiene por debajo de la latencia obtenida con TCP/IP, que a su vez tiene valores menores a los de MPI/TCP/IP (Fig. 5). Las velocidades de transmisión de datos máximas alcanzadas con NetPIPE fueron, 473,21 Kiara A. Ottogalli F., Daniel H. Rosquete De M., Amadís A. Martínez M. y Freddy J. Perozo R. Fig. 4. Tiempo de latencia total de NetPIPE para paquetes pequeños Fig. 6. Velocidad de transmisión de datos obtenida con NetPIPE. utiliza la librería ATLAS, sin embargo, para hacer las pruebas con HPL en el cluster Mangosta, se usó una librería mejorada desarrollada por Kazushige Goto, que proporciona las rutinas BLAS optimizadas para Intel Pentium 4. Fig. 5. Tiempo de latencia total de NetPIPE. Mbps con MPI/TCP/IP, 495,84 Mbps con TCP/IP y 692,10 Mbps con MPI/GAMMA (Fig. 6). Con estos datos se puede concluir que la velocidad de transmisión lograda mediante el uso de MPI/GAMMA representa una mejora de 39,58% con respecto a TCP/IP y un 46,25% con respecto a la velocidad de transmisión alcanzada con MPI. HPL es una herramienta de medición de rendimiento ampliamente utilizada y aceptada globalmente para la evaluación de sistemas computacionales paralelos de alto rendimiento. Para la ejecución de HPL fue necesaria la instalación de MPICH, la versión portable de la librería de paso de mensajes MPI, y una librería que proporciona las rutinas de cálculo de álgebra lineal BLAS (Basic Linear Algebra Sub-programs). Usualmente se Se realizaron 16 pruebas en total con HPL en el cluster Mangosta, todas con un tamaño ?jo del problema de 10,000. Ocho de las pruebas se realizaron con MPI/TCP/IP y las ocho restantes con MPI/GAMMA de la siguiente forma: cada una de las ocho pruebas con MPI/TCP/IP y con MPI/GAMMA se realizó con un número de nodos creciente, desde 1 nodo hasta 8 nodos. Las Tablas 1 y 2, muestran los resultados de estas pruebas, donde: N = Número de nodos, T(s) = Tiempo en segundos, GFP = GFLOPS Práctico, GFT = GFLOPS Teóricos y % = Porcentaje alcanzado con respecto al rendimiento ideal1. . Tabla 1: Rendimiento del cluster Mangosta con MPI/GAMMA. FARAUTE Ciens. y Tec., 5(1). 2010 55 Adaptación del Driver de la Tarjeta de Red D-Link DGE-530t para Gamma GFLOPS (Fig. 7), se puede ver que el rendimiento total del cluster con 8 nodos utilizando MPI/GAMMA es de 62,26% con respecto al valor ideal mientras que el rendimiento utilizando MPI es de 51,61%. Tabla 2: Rendimiento del cluster Mangosta con MPI/TCP/IP. El problema propuesto para probar la influencia del protocolo GAMMA en el de sempeño de un cluster tipo Beowulf Clase I2 para una infraestructura de red Ethernet representa el “peor caso” con respecto al aprovechamiento de la red, es decir, se usa una con? guración “uno a todos” donde el parámetro P vale uno (1) y el parámetro Q toma el valor n (número de procesos), esto se debe a que en una topología de red como la Ethernet los mensajes son transmitidos por un solo cable. En una topología de red tipo Ethernet, el desempeño y la escalabilidad de HPL están altamente limitados y, en general, las con? guraciones donde los parámetros P y Q forman una “malla plana”, con valores aproximadamente iguales, son la mejor opción para alcanzar el máximo rendimiento (Petitet & Dongarra, 2004). Si se comparan los resultados obtenidos 1 El rendimiento ideal es la cantidad de GFLOPS que puede realizar teóricamente un cluster de n no dos, y es calculado como el producto de la cantidad de GFLOPS que puede realizar un solo nodo del cluster y la cantidad de nodos del cluster. El porcentaje alcanzado con respecto al GFP rendimiento ideal es calculado como ( GFT ) x 100%. 2 Un cluster tipo Beowulf se considera de Clase I cuando se construye utilizando hardware y software no especializados para clusters. 56 FARAUTE Ciens. y Tec., 5(1). 2010 Nodos Fig. 7. Rendimiento del Cluster Mangosta con MPI/GAMMA y MPI. Los resultados obtenidos con HPL demuestran que las mejoras en la latencia y la velocidad de transmisión se re?ejaron en el rendimiento general del cluster, el cual se incrementó en un 20,62%, alcanzando 20,47 GFLOPS en las mediciones hechas con HPL, un 62,26% del rendimiento ideal al cual debería acercarse el rendimiento real del cluster. 5.2.3. Comparación entre los Drivers para las Tarjetas D-Link DGE-530T e Intel PRO/1000 para GAMMA Para comparar el desempeño del driver skge para la tarjeta de red DGE-530T se tomaron en cuenta los resultados de las pruebas realizadas en un cluster con nodos dual Xeon de 2.8 GHz con una tarjeta de red Intel PRO/1000 conectados mediante un switch Extreme Networks Summit 7i Gigabit Ethernet de 28 puertos en el cual se corrió la aplicación Ping Pong. Con el driver para la tarjeta Intel PRO/1000 para GAMMA se obtuvo una latencia de 10,8µs y una velocidad máxima de transmisión de 987,2 Mbps mientras que con el driver para la tarjeta Kiara A. Ottogalli F., Daniel H. Rosquete De M., Amadís A. Martínez M. y Freddy J. Perozo R. DGE-530T se obtuvo una latencia de 14,6µs y velocidad máxima de transmisión de 729,08 Mbps. No fue posible hasta el momento establecer un estudio comparativo completo entre los drivers de las tarjetas D-Link DGE-530T e Intel PRO/1000 adaptados para GAMMA por la falta de datos comparativos sobre el rendimiento y la latencia entre GAMMA y TCP/IP para el driver de la tarjeta Intel PRO/1000. 6. Conclusiones y Trabajo Futuro En este artículo se describió la adaptación de un driver especializado para una tarjeta de red Gigabit Ethernet con su respectiva interfaz, para poder incorporar el uso de GAMMA al cluster de PCs de bajo costo del Departamento de Computación de la FaCyT-UC, llamado Mangosta. Se eligió el driver skge debido a que este brinda soporte a las tarjetas de red Gigabit Ethernet de SysKonnect y a los conjuntos de chips de la familia Marvell Yukon 1. Las tarjetas de red Gigabit Ethernet que posee el cluster Mangosta son D-Link DGE-530T poseen el chipMarvell Yukon 88E8001, el cual pertenece a esta última categoría. Al finalizar el desarrollo del driver skge para GAMMA, se hicieron pruebas con Ping Pong para comparar el rendimiento del cluster Mangosta con GAMMA y con TCP/IP, y pruebas con Ping Pong, NetPIPE y HPL para compararMPI/GAMMA, MPI/TCP/IP y TCP/IP. Estas pruebas demuestran que el uso de GAMMA mejoró el rendimiento general del cluster como consecuencia directa de la disminución de la latencia y el aumento de la tasa de transmisión de datos. Con respecto a la comparación con el driver para la tarjeta Intel PRO/1000, el driver skge tuvo un rendimiento inferior en cuanto a la latencia y máxima velocidad de transmisión. La adaptación del driver skge para GAMMA, permitió su incorporación al cluster Mangosta, disminuyendo la latencia en un 79,35% y la tasa de transmisión de datos entre los nodos del cluster en un 39,58%. La mejora en estos dos factores permitió un aumento del rendimiento total del cluster Mangosta en un 20,62%. El logro de un aumento significativo en el rendimiento total del cluster Mangosta implica que un cluster tipo Beowulf de clase I puede ser utilizado para ejecutar aplicaciones que necesitan una alta capacidad de cómputo y paralelismo, dando resultados en un tiempo de respuesta aceptable por lo que elimina la necesidad de un cluster especializado de alto costo, lo cual es favorable sobretodo a nivel académico. Es importante destacar que, aún cuando no existe un procedimiento estándar para el desarrollo de un driver de red para GAMMA y su respectiva interfaz, se puede aplicar un esquema de conversión similar en el cual se deben realizar cuatro pasos específicos: (1) eliminar las interrupciones de transmisión del driver, (2) redirigir la recepción de paquetes a GAMMA, (3) crear los macros de recepción, (4) crear los macros de transmisión. Este esquema sirve como base para la adaptación de otros drivers para GAMMA, lo cual da cabida a diferentes implementaciones en el área. Como trabajo futuro, se tiene pensado adaptar el driver para el uso de jumbo frames, ya que la versión actual permite el manejo de paquetes hasta una MTU menor a 9000 Bytes. 7. Bibliografía Chiola G. & G. Ciaccio. (1996). GAMMA: Architecture, Programming Interface and Preliminary Benchmarking. Technical Report. Universitá di Genova. Genova. Italia. Chiola G. & G. Ciaccio. (1997). GAMMA: a lowcost network of workstations based on active messages. Proceedings of the 5th Euromicro FARAUTE Ciens. y Tec., 5(1). 2010 57 Adaptación del Driver de la Tarjeta de Red D-Link DGE-530t para Gamma Workshop on Parallel and Distributed Processing. IEEE Computer Society Press. London. United Kingdom. 78-83. [en línea]. Computer Science Department, University of Tennessee. http://www.netlib.org/ benchmark/hpl/. (8/6/2007). Chiola G. & G. Ciaccio. (1998). Optimal communication performance on fast ethernet with GAMMA. Proceedings Workshop PCNOW, IPPS/SPDP’98. IEEE Computer Society Press Florida. USA. 534-548. Snell, Q., A. Mikler & J. Gustafson. (1996). NetPIPE: A network protocol independent performance evaluator. IASTED International Conference on Intelligent Information Management and Systems. IASTED. Washington D.C. USA. 196-204. Chiola G. & G. Ciaccio. (1999). Porting MPICH ADI on GAMMA with flow control. In MidwestWorkshop on Parallel Processing. Kent State University. Ohio. USA. 534-548. Tanenbaum, A. (2003). Redes de Computadoras. Pearson Prentice Hall. Mexico. Corbet, J., A. Rubini & G. Kroah-Hartman. (2005). Linux Device Drivers. O’Reilly. California. USA. Von Eicken, T., D. Culler, S. Goldstein & K. Schauser. (1992). Active messages: A mechanism for integrated communication and computation. ACM SIGARCH Computer Architecture News. 20(2): 256-266. Díaz, A., J. Ortega, A. Cañas, F. Fernández, M. Anguita & A. Prieto. (2003). The ligh-weight protocol CLIC on gigabit ethernet. Intenational Parallel and Distributed Processing Symposium. IEEE Computer Society Press. Nice. France. 200a. Morrison, R. (2003). Architectures, Operating Systems, Parallel Processing and Programing Languages. In: Cluster Computing (Richard Morrison, Ed.), 12-27. GNU General Public Licence. Sydney. Australia. Ottogalli, K. (2007). Software controlador de la tarjeta de red D-Link DGE-530T para GAMMA. Trabajo Especial de Grado. Facultad Experimental de Ciencia y Tecnología. Universidad de Carabobo. Valencia. Venezuela. Perozo, F. (2006). Cluster Mangosta: Implementación y Evaluación. Faraute Ciens. y Tec. 1(2): 19-30. Petitet, A. & J. Dongarra. (2004). HPL a portable implementation of the high-performance linpack benchmark for distributed-memory computers 58 FARAUTE Ciens. y Tec., 5(1). 2010 Von Eicken, T., A. Basu, V. Buch & W. Vogels. (1995). U-Net: A User-Level Network Interface for Parallel and Distributed Computing. Proceedings of the 15th ACM Symposium on Operating Systems Principles. ACM. Colorado. USA. 4053. Von Eicken, T. & W. Vogels. (1998). Evolution of the Virtual Interface Architecture. Computer. 31(11): 61-68.