Lorsque l'on parle de GigabitEthernet, il faut prendre des gants quant a la mise en place et au déploiement d'une infrastructure Giga.

En effet, on ne passe pas de 100Mbits/s a 1Gb/s de la même manière que de 10Mb/s a 100Mb/s.

Des limitations d'OS, d'hardware, de TCP/IP surviennent rapidement et il faut les prendre en compte si on ne veut pas stagner à des débits peu sympathiques...

Dans le cadre de VTHD nous avons déployé une petite batterie de tests afin de justement tenter de lister les paramètres limitatifs pour cette technologie.

Le but est de voir si Wagon pourra tourner correctement en environnement Giga. Il s'est avéré rapidement que Wagon, dans la topologie VTHD, ne donnerait pas des débits supérieurs a quelques centaines de Mb/s...donc aucun problème à priori.

Nous avons quand même continué quelques tests, curiosité oblige...

Voici la config des machines testées :

5 PIII800Mhz , carte mère Asus PIIIBF, 256 Mo SDRAM, carte 10/100. (clients)
2 PIII800Mhz , carte mère Asus PIIIBF (PCI 32), 256 Mo SDRAM, carte 10/100 + carte Giga 3Com 3C985SX. (serveurs)

Toutes ces machines sont reliées via un catalyst (Cisco 6500) . Les 2 cartes 10/100 des serveurs sont connectés sur le réseau expérimental. Noyau Linux 2.2.14
Il existe exactement la même topologie à Rocquencourt, joignable depuis Sophia via VTHD.

Voici présentés ici les tests les plus représentatifs :

-> Carte 3Com 3C985SX
 

1) tests en Ttcp
2) tests en Netperf

-> Carte Pro Intel 1000 (cuivre et FO)

les tests ont été effectués par le Semir, voici leurs resultats

CONCLUSION

Voici les tests effectués sur les machines destinées a héberger Wagon.
Remarque: au moment des tests, wstli96a etait un serveur INRIA Rocquencourt. Maintenant, il n'y a plus que 2 serveurs INRIA Rocquencourt: wstli92b et wstli91b

* wsopi98a -> wsopi99a (G):
 

Tests	résultats bruts
UDP	505 Mb/s
TCP "classique"	110Mb/s
TCP buffer socket 256k	238Mb/s
TCP buffer socket 256k + echo 262144 > /proc/sys/net/core/rmem_max et wmem_max	388Mb/s
TCP buffer socket 512k	248Mb/s
TCP buffer socket 512k + echo 524288 > /proc/sys/net/core/rmem_max et wmem_max	418Mb/s
TCP buffer socket 1G (!)	470Mb/s

    * Plusieur flux entre wsopi98a et wsopi99a (G):
 

2 flux TCP (nbuf = 100k)	210Mb/s
5 flux TCP (nbuf = 10k)	100Mb/s

    *Plusieurs clients 10/100 -> wsopi98a (G):
 

5 clients 10/100 -> wsopi98a (G) UDP	91,4Mb/s
5 clients 10/100 -> wsopi98a (G) TCP (classique, buffer socket = 256 ou 512, mêmes résultats)	82Mb/s

Résultats 10/100 très bon.

* Sophia -> Rocquencourt (G) wsopi98a -> wstli96a:
 

UDP	496Mb/s
TCP "classique"	21Mb/s
TCP buffer socket = 256k	64,8Mb/s
TCP buffer socket = 512k	81,7Mb/s

* Sophia -> Rocquencourt (10/100) wsopi01a -> wstli06a:
 

UDP	91,5Mb/s
TCP	21Mb/s

Netperf est un outil de benchmark, qui peut être utilisé pour mesurer différents aspects des performances réseaux. Il reste un outil assez simple.

Il sert surtout pour des tests de performances de transfert brut (stream ou stream unidirectionnel), et fonctionne sur un modèle client/server.

Voici un petit guide très rapide sur Netperf :
 

netperf -l durée -H hôte_serveur -t [TCP/UDP]_STREAM - m taille_paquets -s taille_buf_local -S taille_buf_dist

Deux exemples de scripts simples:

Tests pour UDP:

#! /bin/sh
duree=120
for size in 10 100 300 500 700 900 1100 1300 1400
do
rep=`/usr/local/sys/bin/netperf -P -v -l $duree -H $1 -t UDP_STREAM -- -m
$siz
e -s 65535 -S 65535`
li=`echo $rep | awk '{ pou=(($4-$9) / $4)*100
print $2":"$10":"pou }'`
echo $li
done

Tests pour TCP:

#! /bin/sh
duree=120
for size in 10 100 300 500 700 900 1100 1300 1400
do
rep=`/usr/local/sys/bin/netperf -P -v -l $duree -H $1 -t TCP_STREAM -- -m
$siz
e -s 65535 -S 65535`
li=`echo $rep | awk '{ print $3":"$5 }'`
echo $li
done
 

Les résultats obtenus sont semblables a Ttcp, si ce n'est une différence quant aux débits engendrés en UDP (une différence de presque 200Mb/s apparait...A creuser)

wsopi98a -> wsopi99a (G) (Sophia -> Sophia) : résultats TCP et UDP

TCP max = 389,28Mb/s
UDP max = 699,36Mb/s

wsopi98a -> wstli96a (G) (Sophia -> Rocquencourt): résultats TCP et UDP

TCP max = 76,87Mb/s
UDP max = 684,12Mb/s

Informations sur cette carte :

Intel propose 2 cartes Gigabit, la PRO/1000 F (fibre) et la carte Intel PRO/1000 T (cuivre).

La version cuivre de l'adaptateur Gigabit d'Intel égale à quelques Mbit/s près les performances de son homologue en fibre optique multimode. Cela est surement dû à l'utilisation commune du controleur GigaEther Intel 82543GC. Les performances (d'apres la littérature) sont bien meilleures sur un serveur doté de deux processeurs PIII que sur une machine moins puissante. Une nette réduction du nombre d'interruptions apparaît ainsi. En effet, même si les résultats obtenus en configuration monoprocesseur sont encore très corrects, il reste trop peu de puissance de calcul pour les applications (10 a 15%)...
 

Les cartes Intel gèrent les aspects Jumbo Frame (trames Ethernet etendues), mais pas le marquage des paquets semble-t-il.

Enfin voici les débits donnés pour ces cartes (config : 24 clients mono/bipro sur serveur Compaq ML370 bipro800, 512 MRAM, Windows2000 Advanced Server):

Clients mono :
 

Clients bipro
 

Tests Semir :

tests effectués entre deux machines (galere13 et galere14).

Carte cuivre et carte fibre (résultats identiques):
 

Tests TTCP	Carte Cuivre	Carte Fibre
Galere13 en loopback	363,62Mb/s	361,10Mb/s
Galere13 -> Galere14	247,37 Mb/s	240,68Mb/s
En simultané dans les deux sens	140,81Mb/s	141Mb/s
Ttcp parallele de Galere13 -> Galere14	122Mb/s	123Mb/s
Ttcp parallele dans les deux sens	67Mb/s	67Mb/s

En mettant la MTU a 9000, un gain d'environ 30Mb/s apparaît pour les mêmes tests (excepté le test en loopback bien sur)

Conclusion :

On s'aperçoit bien que les débits engendrés ne sont pas encore pleinement satisfaisant avec nos configurations. En UDP, nous pouvons atteindre jusqu'à presque 700Mb/s, en TCP les 400Mb/s sont péniblement atteint.

Il semble que la limitation la plus grande soit le bus PCI 32 qui, déjà limite physiquement à 1Ghz théorique, devient vite submergé à ces haut débits.
La taille de buffer importe également grandement, en 10/100 un buffer de 64k suffit, alors qu'en Gb/s on s'aperçoit vite qu'un buffer d'au moins 256k est indispensable, voire même 512k et 1G (!).

        Il suffit pour cela de modifier comme suit en Linux :

echo Taille_buffer > /proc/sys/net/core/rmem_max et wmem_max

Un Taille_buffer d'au moins 256K est recommandé (262144)

Enfin notre but était de voir si les débits de ces technologies Giga nous permettraient d'assurer des performances correctes avec notre outil logiciel Wagon.
La réponse étant positive, nous n'avons pas investigué plus en avant les tests de tuning et de paramétrage.

Ainsi, il aurait été intéressant de voir ce qu'auraient donné ces tests en effectuant du zero-copy, (d'apres la littérature, le checksum n'est pas très couteux, il ne semble donc pas très intéressant de l'enlever) ou bien en re-compilant un noyau spécialisé en G.
 
 

Last modified: Tue Jun 12 2001