adaptación del driver de la tarjeta de red d-link dge

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.