ADAPTACI ´ON DEL DRIVER DE LA TARJETA DE RED D

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 cómputo 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 confirm 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.
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 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 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.
2.1.
Antecedentes
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 off-the-shelf, con un sistema operativo
estándar. U-NET 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. Genoa Active
(GAMMA)
Message
Machine
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
3.
Definiciones Previas
3.1. Cluster Computing
Fig. 1: Modelo de GAMMA
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.
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).
Es una rama especı́fica de la computación de 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 Workstations (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.
2.5.
El Driver de Red
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.
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) 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ándar 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.
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.
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 DGE530T, 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 ops descritas en la Subsección
3.2
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
Fig. 2: Ring del driver skge.
buffer en el cual se copia un paquete que va
a ser procesado. Cada ring se maneja 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 contexto (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 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 invocar
a 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.
5.
5.1.
Resultados Experimentales
Configuració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 DGE530T 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 CentOS
5 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.
Pruebas
Comparativas
entre
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 ultimo, pese a que hace uso de TCP/IP, maneja estructuras de memoria (caché y buffers)
las cuales utiliza para 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 latencia
de 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).
Fig. 3: Velocidad de transmisión obtenida con Ping
Pong.
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.
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
Fig. 4: Tiempo de latencia total de NetPIPE para paquetes pequeños.
Fig. 5: Tiempo de latencia total de NetPIPE.
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).
Fig. 6: Velocidad de transmisión de datos obtenida con
NetPIPE.
Las velocidades de transmisión de datos
máximas alcanzadas con NetPIPE fueron,
473, 21 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 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.
Se realizaron 16 pruebas en total con
HPL en el cluster Mangosta, todas con un
tamaño fijo del problema de 10,000. Ocho de
las pruebas se realizaron con MPI/TCP/IP y
las ocho restantes con MPI/GAMMA de la
N
1
2
3
4
5
6
7
8
MPI/GAMMA
T(s) GFP GFT
162, 07
4, 11
4, 11
89, 31
7, 46
8, 22
64, 16 10, 39 12, 33
51, 63 12, 91 16, 44
44, 76 14, 90 20, 55
40, 42 16, 50 24, 66
35, 19 18, 95 28, 77
32, 57 20, 47 32, 88
%
100, 00
90, 75
84, 27
78, 53
72, 51
66, 91
65, 87
62, 26
Tabla 1: Rendimiento del cluster Mangosta con
MPI/GAMMA.
N
1
2
3
4
5
6
7
8
T(s)
162, 23
90, 22
65, 70
55, 21
48, 92
43, 83
41, 66
39, 30
MPI/TCP/IP
GFP GFT
4, 11
4, 11
7, 39
8, 22
10, 15 12, 33
12, 08 16, 44
13, 63 20, 55
15, 21 24, 66
16, 01 28, 77
16, 97 32, 88
%
100, 00
89, 90
82, 32
73, 48
66, 33
61, 68
55, 65
51, 61
Tabla 2: Rendimiento del cluster Mangosta con
MPI/TCP/IP.
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 .
El problema propuesto para probar la
influencia del protocolo GAMMA en el desempeño de un cluster tipo Beowulf Clase
1
El rendimiento ideal es la cantidad de GFLOPS
que puede realizar teóricamente un cluster de n nodos, 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 rendimiento ideal es calculado como
P
( GF
GF T ) × 100 %.
Fig. 7: Rendimiento del Cluster Mangosta con
MPI/GAMMA y MPI.
I2 para una infraestructura de red Ethernet
representa el “peor caso” con respecto al
aprovechamiento de la red, es decir, se usa
una configuració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 configuraciones 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
(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 %.
Los resultados obtenidos con HPL demuestran que las mejoras en la latencia y la
velocidad de transmisión se reflejaron en el
rendimiento general del cluster, el cual se incrementó en un 20, 62 %, alcanzando 20, 47
2
Un cluster tipo Beowulf se considera de Clase I
cuando se construye utilizando hardware y software no
especializados para clusters.
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 DGE530T 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 dualXeon 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 corrio 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 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 Gi-
gabit 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 DGE530T poseen el chip Marvell 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 comparar MPI/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 low-cost network of workstations based
on active messages. In Proceedings of the
5th Euromicro Workshop on Parallel and
Distributed Processing. London. United
Kingdom. 78-83.
Chiola G. & G. Ciaccio. (1998). Optimal
communication performance on fast ethernet
with GAMMA. In Proceedings Workshop
PC-NOW, IPPS/SPDP’98. Florida. USA.
534-548.
Chiola G. & G. Ciaccio. (1999). Porting
MPICH ADI on GAMMA with flow control.
Proceedings of the IEEE/ACM 1999 Midwest
Workshop on Parallel Processing (sin editar).
Kent State University. Ohio. USA.
Corbet, J., A. Rubini & G. Kroah-Hartman.
(2005). Linux Device Drivers. O’Reilly.
California. USA.
Dı́az, A., J. Ortega, A. Cañas, F. Fernández,
M. Anguita & A. Prieto. (2003). The lighweight protocol CLIC on gigabit ethernet. In
proceedings of the 17th Intenational Sympo-
sium on Parallel and Distributed Processing.
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. 1(2):
19-30.
Petitet, A. & J. Dongarra. (2004). HPL
a portable implementation of the highperformance
linpack
benchmark
for
distributed-memory computers [en lı́nea].
Computer Science Department, University
of Tennessee. Disponible en World Wide
Web: http://www.netlib.org/benchmark/hpl/.
(citado 2007, Junio 8)
Snell, Q., A. Mikler & J. Gustafson. (1996).
NetPIPE: A network protocol independent
performance evaluator. In IASTED International Conference on Intelligent Information
Management and Systems. 196-204.
Tanenbaum, A. (2003). Redes de Computadoras. Pearson Prentice Hall. México.
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.
Von Eicken, T., A. Basu, V. Buch & W.
Vogels. (1995). U-Net: A User-Level Network Interface for Parallel and Distributed
Computing. In Proceedings of the 15th
ACM Symposium on Operating Systems
Principles. Colorado. USA. 40-53.
Von Eicken, T. & W. Vogels. (1998). Evolution of the Virtual Interface Architecture.
Computer. 31(11): 61-68.