Considerando el tráfico en la red

Dado que los recursos de la red se comparten entre todos los procesadores, cuando el tráfico es elevado los paquetes no encuentran siempre disponibles los recursos que necesitan, y se pararán en el camino, normalmente en los búferes de los encaminadores, hasta que puedan continuar al liberarse el recurso que necesitan (puerto de salida, enlace...); por tanto, la latencia de los paquetes crecerá. No es sencillo modelar el comportamiento de la latencia de los paquetes en función del tráfico en la red. En general, este modelado se hace basándose en la teoría de colas, los modelos cliente/servidor, etc. Como resultado de esos modelos se obtiene el tiempo de espera de los paquetes en los búferes intermedios, la ocupación de dichos búferes, etc. (un modelo sencillo se plantea en los ejercicios).

El comportamiento habitual de una red de comunicación en un sistema MPP es el que se muestra en estas figuras, tanto para la latencia como para el

throughput (para paquetes que van distancias medias):

Tráfico (b/s) Latencia (s) Latencia sin tráfico Throughput (b/s) Tráfico (b/s) Tráfico máximo i

Inicialmente, cuando el tráfico es muy reducido, los mensajes llegan a destino en el tiempo mínimo esperado (en función de la distancia recorrida) sin sufrir ningún retraso. Según el tráfico va creciendo, la latencia de la comunicación va creciendo suavemente, debido a conflictos sueltos que hacen que algunos paquetes tengan que pararse algunos ciclos (por lo demás, los búferes están prácticamente vacíos). Pero, a partir de cierto nivel de tráfico, los conflictos entre paquetes se multiplican y la red se satura: no puede gestionar más paquetes, los búferes se llenan, y la latencia de los paquetes crece indefinidamente. Se trata de un estado de la red no admisible, que hay que evitar.

Si analizamos el throughput, es decir, el número de paquetes que puede gestionar la red por segundo, vemos que cuando no hay problemas de tráfico la red lleva a su destino todos los paquetes que se le encomiendan (su comportamiento es lineal). En cambio, superado cierto nivel de tráfico, la red no puede gestionar más paquetes, estamos en el throughput máximo, en el nivel de saturación. En algunas redes, si se solicita un nivel de tráfico superior al de saturación, el número de paquetes que efectivamente se procesa desciende del valor máximo. Se trata de un comportamiento que se debe evitar, ya que si se produce un momento de alta congestión en el tráfico en la red, va a costar mucho tiempo volver a una situación normalizada.

A la hora de diseñar la red de comunicación de un sistema paralelo es importante prever el tráfico máximo que puede soportar, ya que habrá que dimensionar la red para que trabaje normalmente lejos de su punto de saturación. En todo caso, siempre es posible que una determinada aplicación genere un número inusualmente alto de paquetes en determinados momentos. Aunque no se pueda admitir tal cantidad de paquetes de manera sostenida (saturaríamos la red), el sistema de comunicación debería ser capaz de gestionar esas “avalanchas” puntuales de paquetes de manera eficaz, aunque fuera con latencias superiores a las habituales, y de recuperar la situación normal de procesamiento de paquetes al volver el tráfico a su nivel habitual; es decir, la red no debe bloquearse porque en momentos concretos se produzcan demandas de tráfico por encima del máximo permitido.

6.5.6.2.1 WH versus CT

Como ya hemos comentado, la única diferencia entre wormhole y cut-

through se encuentra en cómo se tratan los conflictos: cuando un paquete no

puede continuar su recorrido, se deja parado en la red (WH), o se va recogiendo, ciclo a ciclo, en el encaminador que ha parado la cabecera del

paquete (CT). Ambos comportamientos tienen su reflejo en la latencia de los paquetes y en el throughput de la red.

La latencia de los paquetes que avanzan en modo WH crece más rápido con el nivel de tráfico en la red, ya que los paquetes que se detienen mantienen ocupados muchos recursos, lo que lleva a que se detengan más paquetes y, por tanto, crezca su latencia. Así, la capacidad de gestionar paquetes de la red será menor: la red se satura con un tráfico menor.

6.5.6.3 Cálculo del throughput máximo

Ya hemos mencionado que uno de los parámetros de calidad de una red de comunicación es el throughput, el número de paquetes que puede procesar por unidad de tiempo. Aunque normalmente el nivel de tráfico sea bajo, habrá momentos en los que la demanda puede crecer muy rápidamente, y la red debe ser capaz de dar respuesta adecuada a dicha demanda.

El número de paquetes que puede gestionar la red depende de muchos parámetros: patrones de comunicación, topología, estructura de los encaminadores de mensajes, control del flujo, etc. Si nos fijamos exclusivamente en los aspectos topológicos, podemos obtener un valor máximo para el throughput de la red.

Supongamos que la comunicación es aleatoria, tanto en el tiempo como en el espacio: los paquetes que se envían desde un procesador se distribuyen homogéneamente en el tiempo y entre todos los procesadores de la red. Uno de los parámetros topológicos de la red es el ancho de banda de la

bisección, es decir, el ancho de banda acumulado de los enlaces que es

necesario eliminar para dividir la red en dos partes iguales.

Si la probabilidad de comunicación es la misma entre dos procesadores cualesquiera, de todos los paquetes que se generan en una mitad de la red, el 50% irá destinado a procesadores de esa mitad de la red, pero el otro 50% irá

Tráfico (b/s) Latencia (s) Throughput (b/s) Tráfico (b/s) WH CT CT WH

destinado a procesadores de la otra mitad de la red, y para ello deberán utilizar los enlaces que forman parte de la bisección de la red.

Por tanto, el ancho de banda de esos enlaces marca un límite al tráfico máximo que puede admitir la red. Es decir:

P/2 × NPaq × 1/2 × L = ABB

donde

P/2 → número de procesadores de una mitad de la red

NPaq → número de paquetes que genera un procesador por ciclo

1/2 → fracción de paquetes que pasa a la otra mitad de la red

L → tamaño o longitud de los paquetes

ABB → ancho de banda acumulado de los enlaces de la bisección de la red

Así pues, si el tráfico es aleatorio, el máximo número de paquetes que puede generar un procesador por ciclo es:

NPaq = 4×ABB / (P×L) (o, en flits, 4 × ABB / P)

En la siguiente tabla se muestran el tráfico aleatorio máximo que admiten una malla, un toro y un hipercubo (1 flit = 1 byte). El resultado se da en byte/ciclo (es decir, 4 × ABB / P, sin tener en cuenta el ancho de banda de los enlaces)

256 procesadores malla 2D toro 2D hiperc. 8D Bisección de la red (núm. enlaces) 16

kn–1

32 2kn–1

128 2n–1 = P/2

Número máximo de flits por ciclo que puede generar cada procesador (med.)

0,25 4 / k 0,5 8 / k 2 (constante)

El hipercubo, una red muy densa, admite un mayor nivel de tráfico aleatorio que la malla o el toro, pero a costa de que la topología sea muy compleja de construir, sobre todo si el número de nodos es grande. Por su parte, el nivel teórico máximo de tráfico en el toro dobla al de la malla, esta

enlaces de la bisección

P/2 P/2

NPaq/2

vez con muy poco coste: convertir las cadenas en anillos. En todo caso, los niveles de tráfico de la tabla son muy elevados: no es habitual tener que enviar un byte por ciclo en todos los ciclos y procesadores, ya que para poder enviar datos es necesario efectuar cálculo previamente.

El nivel de tráfico máximo que acabamos de obtener representa un límite teórico; en la realidad, aunque el tráfico sea aleatorio la red se satura antes de dicho límite debido a que la homogeneidad del tráfico es de tipo estadístico (en promedio).