Download Proporcionar QoS en HyperTransport - Universidad de Castilla

Proporcionar QoS en HyperTransport*
Juan A. Villar, Francisco J. Alfaro, José L. Sánchez
Escuela Politécnica Superior de Albacete
Universidad de Castilla - La Mancha
{juanan, falfaro, jsanchez}@dsi.uclm.es
Resumen
PCI. HyperTransport (HT) es una nueva generación de redes de interconexión que propo-
HyperTransport (HT) es una nueva tecnología
ne la sustitución del bus PCI por una red con
compatible con PCI diseñada para proporcio-
enlaces punto a punto, manteniendo la com-
nar en un estándar abierto la funcionalidad de
patibilidad con PCI.
los sistemas de interconexión propietarios que
HT es una nueva tecnología de intercone-
han estado en el núcleo de sistemas empotra-
xión de altas prestaciones que cuenta como
dos, de almacenamiento y de comunicaciones.
gran ventaja el hecho de ser compatible con
Proporcionar calidad de servicio (QoS) en
PCI, y ser el protocolo utilizado de forma na-
entornos de computación y comunicaciones es
tiva por los procesadores Opteron y Athlon64
actualmente el centro de muchos esfuerzos en
de AMD. La especicación de HT se encuentra
investigación por parte de la industria y el ám-
en continua evolución desde que AMD decidie-
bito académico. HT incorpora mecanismos que
ra abrirla a otras empresas.
apropiadamente usados se espera que proporcionen QoS. Este trabajo tiene el objetivo de
dar a conocer la tecnología HT, las características que proporciona para la provisión de
QoS, y cuáles pueden ser las líneas de trabajo
para conseguir que HT proporcione QoS.
Por otra parte, AMD supervisa el desarrollo
de HT a través del HT Consortium [2]. Importantes empresas como nVidia, Sun, Transmeta, etc. ya se han unido al consorcio, donde
pueden colaborar en el desarrollo de productos compatibles con HT. En el año 2006, el
esfuerzo del consorcio se ha extendido al ám-
1.
Introducción
El bus PCI ha servido bien a la industria durante 13 años y todavía se usa hoy en día
bito académico con la fundación del Centro de
Excelencia de HyperTransport [3], con base en
la Universidad de Mannheim, Alemania.
HT incorpora mecanismos que apropiada-
ampliamente en gran variedad de sistemas
mente
tanto personales como corporativos. Sin em-
QoS. En concreto, HT permite utilizar cana-
bargo, los procesadores y dispositivos de en-
les virtuales, clases de tráco, intercalado de
trada/salida (E/S) actuales demandan mucho
transacciones, planicación de tráco y meca-
más ancho de banda y menor latencia que PCI
nismos de control de admisión. En este trabajo
puede proporcionar. La causa de esta limita-
se revisan todos ellos.
ción es precisamente la arquitectura de bus de
*
Este trabajo ha sido conanciado por el Ministerio de Educación y Ciencia, y la Comisión Europea FEDER con las subvenciones Consolider Ingenio2010 CSD2006-00046 y TIN2006-15516-C04-02;
por la Consejería de Educación y Ciencia de Castilla La Mancha con el proyecto PBC-05-005 y con una
Beca de Investigación.
usados
se
espera
que
proporcionen
La estructura de este artículo es la siguiente:
la sección 2 justica la necesidad de QoS en
las redes en placa; en la sección 3 se destaca
algunas características generales de HT, para
continuar en la sección 4 con las características
concretas de HT para proporcionar QoS; en la
siguiente sección se describe el trabajo que se
está realizando para dar garantías de QoS. Por
tir los recursos hardware disponibles entre
último se exponen algunas conclusiones.
las aplicaciones existentes, pero garantizando que cada una conseguirá alcanzar
2.
los niveles de calidad que tienen contra-
QoS en redes de interconexión
tados.
Proporcionar QoS a las aplicaciones ha sido un
tema importante tanto para la industria como
para la comunidad investigadora durante más
de treinta años. Sin embargo, las propuestas
para proporcionar QoS suelen enmarcarse en
entornos LAN, SAN, Internet, etc. No suele
ser frecuente encontrar aproximaciones que intenten soportar QoS en un entorno cercano al
procesador, que es donde se centra HT.
Los dos últimos estándares de interconexión
propuestos en estos entornos que incorporan
algún tipo de soporte de QoS han sido InniBand [4] y Advanced Switching [5]. Estos
dos estándares tenían el objetivo inicial de reemplazar al bus PCI. Hoy en día InniBand
es una opción bastante utilizada para montar
clusters o SANs. Sin embargo, el fracaso en
cuanto a reemplazar al bus PCI ha sido absoluto. El fracaso de Advanced Switching ha
sido todavía más denitivo que el de InniBand, puesto que ha perdido el apoyo de las
En este segundo caso es evidente que no será
suciente con proporcionar QoS a nivel de red,
y será necesario involucrar también al planicador de tareas del sistema operativo, la gestión de memoria, etc. Sin embargo, también
resulta evidente que en estos casos será necesario aplicar algún tipo de arbitraje a nivel de
comunicaciones (en nuestro caso en HT), para
conseguir la priorización que se quiera aplicar.
Así pues, es evidente que en este tipo de
entornos de uno o varios procesadores interconectados con una serie de dispositivos de E/S,
también hay una necesidad de proporcionar
QoS en las comunicaciones. Esto fue advertido
por los diseñadores de InniBand o Advanced
Switching y esa fue la razón de que en ambos
estándares de interconexión la QoS fuera un
punto fuerte. El hecho de que esas propuestas
no hayan terminado de triunfar no quiere decir
que sus objetivos no fueran acertados.
empresas. Sin embargo, hay algunos detalles
de esos estándares que deben considerarse con
detenimiento, por ejemplo, que en ambos la
QoS era un tema importante.
Visto lo anterior, la pregunta de si HT será
3.
HyperTransport
La
tecnología
nalmente
HyperTransport
llamada
[1],
origi-
Lightning Data Transfer
el siguiente surge de inmediato. Sin embargo,
(LDT), fue desarrollada inicialmente por Ad-
la principal diferencia es que HT es una tecno-
vanced Micro Devices (AMD) con la ayuda de
logía asentada que está en uso por AMD, uno
otras empresas, para conseguir un enlace pun-
de los principales fabricantes de procesadores,
to a punto, de alta velocidad y baja latencia
desde que fuera propuesta.
para la interconexión de circuitos integrados
Por otra parte, la necesidad de QoS en estos
entornos dentro de un servidor puede surgir
desde dos puntos distintos:
•
Priorización. No todas las comunicaciones
generadas son igual de prioritarias. No es
lo mismo una invalidación de un protocolo
de coherencia, que un mensaje de sincronización, que una petición de E/S programada, o que una petición de DMA, etc.
[9].
•
en placa.
La tecnología de interconexión HT suministra una latencia baja en enlaces chiptochip
y boardtoboard. HT plantea una arquitectura escalable y exible, diseñada para reducir el número de buses en el sistema. Con unos
enlaces de alto rendimiento, sus aplicaciones
van desde sistemas empotrados, ordenadores
personales y servidores, hasta equipamiento de
red y supercomputadores.
La versión 3.0 extiende la anterior versión
Virtualización. En los sistemas actuales
2.0. En HT 3.0 la frecuencia máxima de reloj
una opción muy interesante es compar-
va desde 1,8 a 2,6 Ghz, empleando Dual Da-
ta Rate. El ancho de banda máximo agregado que es capaz de alcanzar HT 3.0 asciende
a 41,6 Gbyte/s, suponiendo un aumento del
86 % respecto a HT 2.0, lo que signica un
ancho de banda máximo por enlace de 20,8
Gbyte/s (166 Gbit/s). HT es completamente
compatible con algunas tecnologías legadas de
interconexión de componentes periféricos, esto
es: PCI, PCI-X y PCI Express [5].
El HyperTransport Consortium [2] es la entidad que publica la especicación, la mantiene y conduce el desarrollo de sus nuevas versiones. El consorcio agrupa a las empresas que
Figura 1: Intercalado de paquetes.
desarrollan productos basados en esta tecnología, lo que les permite realizar sus diseños
con la seguridad de que el producto nal será
compatible con un gran repertorio de sistemas
diferentes.
3.1. Conmutación de paquetes
Los dispositivos HT se comunican mediante el
intercambio de paquetes. Todos los paquetes
están clasicados como paquetes de control o
El tamaño de los paquetes de control viene
dado por la especicación según el tipo. Por
contra, el tamaño de los paquetes de datos se
dene en el correspondiente paquete de control. El tamaño habitual de un paquete de control está entre 4 y 8 bytes, y en el caso de los
paquetes de datos está entre 4 y 64 bytes.
3.2. Topología
de datos. Además, en HT existe el concepto de
Un sistema HT estándar se divide en dos par-
transacción, de modo que una transacción se
tes: una parte llamada
compone de un paquete de control, y cuando
vos de computación tales como procesadores,
sea necesario, de un paquete de datos. Así, to-
y una segunda parte alberga el subsistema de
dos los paquetes de control contienen un cam-
E/S. Ambas partes se unen por medio de una
po que indica un comando que representa una
interfaz llamada
operación, por ejemplo: lectura, escritura, ba-
que habitualmente componen la parte host son
rrera, respuesta de escritura, etc. Por otra par-
los procesadores Opteron de AMD. Gracias a
te, los paquetes de datos no contienen informa-
sus tres enlaces HT integrados en el chip, los
ción de encaminamiento, y se limitan a seguir
Opteron pueden formar tanto topologías regu-
a su correspondiente paquete de control y, por
lares como irregulares.
host
hostbridge
contiene dispositi-
(HB). Elementos
tanto, es obligatorio que entre un paquete de
La red host se extiende al subsistema de E/S
control y su correspondiente paquete de datos
mediante unos elementos especiales llamados
no exista ningún otro paquete de datos.
bridge, tunnel
y
cave.
Tales dispositivos per-
No obstante, sí se permite el intercalado con
miten la concatenación de los dispositivos de
paquetes de control que no tengan a su vez pa-
E/S en forma de cadena o árbol. En la Figu-
quetes de datos, entre otro paquete de control
ra 2 se puede ver como los dispositivos HT, y
y su respectivo paquete de datos. En la Figu-
los dispositivos que no son HT, van formando
ra 1 se puede ver el funcionamiento de esta
una estructura de cadena mediante dispositi-
técnica utilizada por HT, donde un disposi-
vos especiales y en el extremo de la cadena se
tivo, situado entre otros dos dispositivos que
conecta el host.
están realizando una tranferencia grande, in-
En el sistema se permite la existencia de va-
tercala un paquete de control sin paquete de
rias cadenas. En un extremo de la cadena se
datos, de forma que no se ve forzado a esperar
sitúa un HB, que es el responsable de gestionar
a que la primera transferencia termine.
todo el tráco que viaja dentro de la cadena.
El UnitID igual a 0 está reservado para el HB,
y existen otros 31 identicadores, como máximo, a repartir entre los dispositivos de la cadena. Un ujo de E/S está compuesto por todo el
tráco perteneciente a un único UnitID, aunque se permite que un dispositivo posea varios
UnitID cuando desee tener varios ujos en un
momento dado. Así, los UnitID permiten a la
cadena HT tratar de forma independiente el
tráco de cada ujo de E/S, aplicando las reglas de ordenación de la E/S a cada ujo.
Figura 2: Topología en cadena y árbol.
3.5. Control de ujo
HT dene dos esquemas de control de ujo.
En el caso de existir más de un HB conectado a la cadena, los dispositivos se asignarán a
cada uno de los HBs, formando así dos subcadenas disjuntas; en caso contrario, uno de
los HBs deberá congurarse como maestro y
el otro como esclavo. Salvo que se habilite el
soporte
DirectRoute, todo el tráco entre cua-
lesquiera de los dispositivos de una cadena se
reejará en el HB. Como los enlaces son unidireccionales, el tráco hacia el HB utiliza los
upstream, y el tráco desde el HB utiliza los enlaces downstream. A todos los niveles,
enlaces
los enlaces upstream y downstream son independientes.
El esquema principal que se aplica únicamente a los conjuntos de canales virtuales BaseSet e IsocSet (ver sección 4.1), es un esquema
basado en cupones. El cupón representa a un
paquete al que un dispositivo receptor asegura
espacio en sus buers de entrada. El segundo
esquema de control de ujo es el llamado Control del Flujo Extendido y se utiliza sólo con
conjuntos de canales virtuales distintos al BaseSet e IsocSet, quedando su uso restringido
a un uso especíco de la implementación. La
implementación del control de ujo extendido
es opcional.
El control de ujo se aplica a nivel de enlace
y por cada tipo de buer. En cada buer hay
3.3. Compatibilidad
espacio para al menos el mayor paquete de ese
Por otra parte, HT es compatible con PCI. Es-
criterio de los diseñadores. Aparte, los emiso-
to le afecta a varios niveles en el diseño, por
res nunca emitirán ninguna transacción a no
ejemplo, implica que el proceso de inicializa-
ser que exista espacio suciente en el recep-
ción y conguración en ambas tecnologías son
tor para contener tanto el paquete de control
idénticos. El sistema, tras completar la fase de
como su respectivo paquete de datos en caso
arranque, delega en el software la responsabili-
de existir.
dad de conguración del sistema con las características avanzadas propias de HT. Igualmente, HT aplica las mismas reglas de ordenación
de E/S que dene PCI. Esto asegura que las
secuencias emitidas con restricciones de ordenación son recibidas y procesadas respetando
dicha ordenación original del emisor.
tipo, quedando el tamaño máximo de buer a
3.6. Encaminamiento
HT implementa un esquema de encaminamiento distribuido, pero con algunas particularidades. En la parte de host, los switches contienen rangos de direcciones y encaminan los
paquetes mediante la comparación entre la di-
3.4. Direccionamiento
rección contenida en los paquetes y los rangos
Todos los dispositivos pertenecientes a una ca-
de la cadena los paquetes son encaminados en
dena de HT se identican con un valor UnitID.
base a su identicador de UnitID y según si
de direcciones conocidos. Sin embargo, dentro
Conjunto
viajan por el upstream o downstream. Ade-
Número de CVs
lesquiera dos dispositivos, por lo que el algo-
BaseSet
IsoSet
AltSet
ritmo de encaminamiento es determinista.
NonFCSet
1
StreamSet
16
más, debe existir un único camino entre cua-
Los procesadores de un host se interconec-
3
tan entre sí mediante enlaces físicos HT, y op-
Reservado para futuras
estandarizaciones
Sin especicar
cionalmente también pueden interconectarse
Reservado ccNUMA
Sin especicar
Especíco de la implementación
Sin especicar
mediante switches. Los puertos de los switches
HT se clasican como primarios o secundarios,
quedando prohibido el tráco entre puertos
Tabla 1: Conjuntos de canales virtuales.
primarios. A su vez, los switches pueden formar particiones de puertos quedando el tráco
entre puertos de distintas particiones prohibi-
plir ciertas directivas de la especicación. En-
do. Los switches establecen hasta dieciséis re-
tre los conjuntos de canales virtuales existen
giones de direcciones en base a las cuales enca-
prioridades. El conjunto AltSet es más prio-
minan los paquetes que reciben. La especica-
ritario que el BaseSet, pero implementa un
ción HT deja libre los algoritmos de arbitraje
algoritmo de control de tráco inyectado me-
y tampoco dene una estructura interna de
diante ventana para garantizar que no produce
switch. Por otra parte, un puerto primario de
inanición en el conjunto BaseSet; el conjun-
un switch sólo puede conectarse a un puerto
to NonFCSet es el más prioritario de todos,
secundario de otro switch. Se garantiza que no
pero igualmente se limita su tráco inyecta-
existen bucles, aunque se permite redundancia
do mediante un algoritmo
para tolerancia a fallos, y que el algoritmo de
gamente, el conjunto StreamSet es el menos
encaminamiento es libre de bloqueo.
prioritario pero en este caso se le garantiza un
leaky bucket ; análo-
ancho de banda mínimo también mediante un
4.
Soporte de QoS en HyperTransport
A continuación se revisan los principales mecanismos que tiene HT para proporcionar QoS.
4.1. Canales virtuales
HT dene 26 canales virtuales estándar más
algoritmo leaky bucket; y respecto a los conjuntos especícos de cada implementación, la
especicación obliga a los diseñadores que eviten arruinar las expectativas del usuario y no
provoquen inanición en el resto de canales virtuales.
4.2. Tipos de tráco
otros especícos, agrupados en los conjuntos
HT dene tres tipos de tráco: Programmed
que se pueden ver en la Tabla 1. Existe un
I/O (PIO), Direct Memory Access (DMA), y
conjunto llamado BaseSet, de implementación
Peer-to-Peer (P2P). La Figura 3 muestra el
obligatoria, compuesto por tres canales virtua-
ujo de cada tipo de tráco.
les: uno para las peticiones con conrmación
nonposted ), otro para las peticiones sin conposted ) y el tercero para las respuestas (response ). Los restantes canales vir(
rmación (
tuales son opcionales. Cada canal virtual engloba tanto los paquetes de control como los
paquetes de datos que le corresponden, además los dispositivos implementan buers separados para control y datos.
Los diseñadores que decidan implementar
los canales virtuales opcionales deberán cum-
Figura 3: Flujos de tráco en HT.
El tráco PIO se origina en el HB como resultado de la ejecución de código por la CPU
en la parte host, y tiene como objetivo dispositivos de E/S o E/S de un dispositivo mapeada en memoria. Por ejemplo, cuando el código de un driver de dispositivo ejecuta código
que produce una transacción para congurar el
dispositivo, comprobar su estado, o para realizar una transferencia de datos supervisada por
la CPU. Las transacciones inicializadas por la
CPU se envían a los dispositivos en la cadena
a través del HB como se aprecia en la Figura 3.
La transacción de la gura es una petición de
escritura enviada por el HB, y el dispositivo
Figura 4: Tráco DirectRoute y HostReected.
destino no tiene que responder a la CPU. En
los casos de peticiones con conrmación, sí es
necesario que el dispositivo retorne una respuesta a la CPU.
se ve grácamente el camino recorrido por el
tráco DirectRoute.
Cuando se emite tráco reejado (
El tráco DMA se da cuando la CPU requie-
ected )
HostRe-
la petición viaja por el upstream des-
re que se transera grandes cantidades de in-
de el dispositivo emisor en sentido HB. Cuan-
formación entre la memoria y los dispositivos.
do la petición llega al HB, se reenvía por el
En este caso, la CPU no realiza una supervi-
downstream hacia el dispositivo destino. Si se
sión de dicha transferencia, sino que congu-
trata de una transacción que requiere una res-
ra los dispositivos con unas pocas transaccio-
puesta, ésta recorrerá el camino inverso al que
nes PIO para indicar el tamaño, la dirección
hizo la petición, primero subiendo por el ups-
de memoria, tipo de operación, etc., y delega
tream hasta el HB para reejarse y bajar por
en los dispositivos la responsabilidad de mo-
el downstream hasta el dispositivo que emitió
ver la información hacia/desde memoria. La
la petición. En la Figura 4 se muestra gráca-
CPU puede continuar realizando otras tareas
mente el camino recorrido por el tráco ree-
mientras se realiza la transferencia. Cuando la
jado.
transferencia se complete, el dispositivo informará a la CPU mediante un mensaje de interrupción. En la Figura 3 se muestra el caso
4.3. Algoritmo de fairness
de una operación de lectura por DMA hacia la
En el momento de enviar paquetes, cada nodo
memoria principal.
debe ser capaz de inyectar el tráco propio
Aunque por el nombre podría ser confuso,
dentro de ujos de tráco provenientes de
el tráco P2P no se reere al tráco directo
otros nodos, y que el nodo tiene que reenviar.
entre un dispositivo emisor y otro receptor sin
Esta unión de ujos de tráco se debe reali-
pasar por el HB, porque los ujos P2P tam-
zar garantizando que no existe inanición entre
bién se procesan en el HB. Por otra parte, HT
los ujos. En el caso de los túneles HT, la im-
introduce la característica
que sí
plementación del algoritmo fairness es obliga-
permite, a dos dispositivos dentro de una cade-
toria, para proveer un acceso equitativo para
na, intercambiar transacciones entre ellos sin
todos los ujos. El algoritmo
que el HB procese los paquetes, minimizando
ta un comportamiento aproximado al round-
la posible sobrecarga debida al paso por el HB.
robind de un bus. No obstante, algunos dis-
Además, las reglas de ordenación de E/S no
positivos, probablemente, no requieran de este
se aplican a las transacciones de tráco Direc-
trato equitativo.
DirectRoute
fairness
presen-
tRoute. Esta característica sólo es compatible
La especicación dice que a cada nodo se le
desde la versión 1.1 de HT. En la Figura 4
permite insertar paquetes en uno de sus en-
laces a la misma tasa que otro nodo inserta
paquetes cuando no haya paquetes esperando
tráco a través de él. Además, cada nodo es li-
ser enviados. El Denominator se pone a 1 con
bre de utilizar como considere los periodos sin
un reset.
tráco de sus enlaces. Esta propiedad debe ser
Para respetar la tasa de inserción, cada nodo
aplicada sobre una ventana de tiempo (se ve-
tiene un contador de 6 bits (referenciado como
rá a continuación) lo sucientemente pequeña
Window), que se pone a 1 con un reset. Tam-
para gestionar patrones de tráco dinámico,
bién tiene un contador de 1 bit (referenciado
pero sucientemente larga para ser estadísti-
como Priority) que se pone a 0 con un reset.
camente convergente. A n de que el sistema
Cuando un nodo tiene paquetes listos para ser
sea consistente, cada nodo debe implementar
enviados por un enlace de salida, el nodo de-
el mismo algoritmo fairness que se describe a
cide qué envía en base a los siguientes casos:
continuación. Por otra parte, la generación de
•
paquetes de información no se ve afectada por
hay paquetes para reenviar se envía el
este algoritmo, puesto que los paquetes de in-
paquete y se decrementa el contador Win-
formación sólo existen en el dominio del enla-
dow.
ce.
El algoritmo fairness consiste en dos partes:
•
•
No hay paquetes locales, pero hay paquetes para reenviar se envía el paquete y
La primera parte calcula la tasa de inser-
se pone a cero el registro Priority.
ción que cada nodo puede usar.
•
Hay un paquete local para inyectar y no
•
La segunda parte rige cómo cada nodo al-
Hay algún paquete local para enviar y
también hay paquetes para reenviar si
canza la tasa de inserción.
Priority vale 1 se inserta el paquete local
El algoritmo debe implementarse indepen-
y se pone el registro Priority a 0. En caso
dientemente para ambas direcciones upstream
contrario, se envía el paquete y el registro
y downstream. No es necesario mantener un
Window se decrementa.
control dedicado, ni registros de estado y no
Cuando el registro Window alcanza el valor
tiene parámetros congurables.
Para calcular la tasa de inserción, ésta se de-
cero, el siguiente valor tiene que recalcularse.
duce de la tasa máxima de envío de paquetes
Para ello, el registro Priority se pone a 1. A
entre las tasas de los nodos del downstream.
n de alcanzar tasas de inserción no integra-
Esto se hace implementando 32 contadores de
les, el nuevo valor del registro Window debe
3 bits, uno por cada UnitID del downstream
calcularse de forma probabilista. Cada nodo
junto a un único contador de 8 bits. Los Uni-
implementará un registro de desplazamiento
tID se consideran de forma separada, aunque
con retroalimentación lineal (
Linear Feedback
varios estén asignados al mismo dispositivo.
Shift Register,
Con el reset se ponen a cero todos los con-
linomio
tadores. Cuando se envía un paquete con un
Window se recalcula, el nuevo valor resulta de
UnitID por el downstream se incrementan tan-
desplazar
to su contador de 3 bits como el contador de 8
recha 3 posiciones.
x9 +
LFSR) de 9 bits usando el pox4 + 1. Cada vez que el registro
(Denominator+LFSR[2:0])
a la de-
bits. En el momento en que uno de los contadores de 3 bits se desborde, se captura el valor
5.
Trabajo en desarrollo
del contador de 8 bits (referenciado como Denominator) y se resetean todos los contadores.
La provisión de QoS en HT se pretende
La tasa de inserción de paquetes se establece
abordar desde dos puntos de vista bien distin-
como
8/Denominator,
esto es, que en media
tos, pero complementarios: respetando el es-
de cada UnitID se pueden insertar 8 paquetes
tándar y proponiendo modicaciones al están-
por cada Denominator paquetes enviados. La
dar.
inserción debe hacerse de forma progresiva y
En el primer caso la idea es explotar al má-
evitando las ráfagas. Siempre se puede insertar
ximo las posibilidades que propone el estándar
de HT. Para ello será fundamental conocer con
un simulador que sirva para comprobar la va-
detalle las distintas posibilidades que ofrece.
lidez de las propuestas, y será la mejor opción
En el segundo caso se pueden proponer mo-
antes de trasladarlas a un sistema real.
dicaciones al estándar HT de cara a mejorar
las prestaciones ofrecidas.
Una posible mejora del estándar sería proponer nuevas topologías de interconexión entre los dispositivos que permitieran distribuir
mejor el tráco. Esto redundará en alcanzar
mayor ancho de banda en la red, y por tanto
mejorarán las latencias. También es interesante proponer distintos algoritmos de planicación que permitan proporcionar distintos tipos
de QoS a los ujos.
Estos algoritmos a probar podrán estar basados en asignación de ancho de banda o en
acotar las latencias máximas. Buena parte del
trabajo previo realizado por los autores se ha
centrado en proporcionar QoS para los están-
Referencias
[1] HyperTransport Technology Consortium,
HyperTransport I/O Link Specication Revision 3.0, http://www.hypertransport.
org,
2006.
[2] HyperTransport Technology Consortium,
http://www.hypertransport.org
[3] Center
estándar.
Para comprobar la validez de las propuestas se está desarrollando un simulador de HT
acorde a las características de la versión 3.0 de
la especicación.
6.
Conclusiones
En este trabajo, se ha presentado la tecnología
de interconexión HT. Tras revisar las características más generales de HT nos hemos centrado en los mecanismos que proporciona HT
para proporcionar QoS. La provisión de QoS
es una necesidad en este tipo de redes que ya
contemplaron tecnologías anteriores como In-
Excellence
for
HyperTrans-
http://www.ra.informatik.
uni-mannheim.de/coeht
[4] InniBand
Trade
Association,
www.infinibandta.org
dares InniBand [7] y Advanced Switching [8],
y por tanto podrá ser aplicado en este nuevo
of
port,
[5] PICMG,
http://
PCI Express Advanced Switching,
http://www.picmg.org
QNoC: QoS architecture and design process for network on
chip, Journal of System Architecture, El-
[6] Evgeny Bolotin et al.,
sevier North-Holland, Inc., 2004.
Una sencilla metodología para garantizar QoS en subredes InniBand, ISBN:84-8427-320-2, 2004,
[7] Francisco J. Alfaro,
[8] A. Martínez and R. Martínez and F.J. Al-
A Low-Cost Strategy to Provide Full
QoS Support in Advanced Switching Networks, Journal of Systems Architecture,
faro,
Elsevier Science, 2007.
sirven para proporcionar QoS. Para nalizar,
Interconnect-Aware
Coherence Protocols for Chip Multiprocessors, ISBN:0-7695-2608-X, IEEE Compu-
se han visto qué lineas de trabajo se están si-
ter Society, 2006.
niBand y Advanced Switching. En este sentido HT dene mecanismos que bien utilizados
guiendo; la más importante es el desarrollo de
[9] Liqun Cheng et al.,