Test switch 1Gbits/s

[Brizme]

Bonjour,

Je dois tester un switch fibre optique fast ethernet. mais il faudrait pour cela faire un test au max de la vitesse pendant 24h. seulement avec Iperf ou meme Jperf je n'arrive pas a monter très haut dans le debit.
faudrait il que je sois en mode JUMBO?
je n'ai pas ce mode, y a t il un autre moyen?

si vous voulez plus de précision, demandé moi je ne sais pas quoi exactement vous dire pour vous donner plus d'info

merci
a bientot

[vivien]

En UDP on indique le débit souhaité avec -b : exemple -b 950M pour 950 Mb/s

En TCP le débit est négocié par TCP pour etre le plus important sans perte de paquets.

Pour un test qui dure 24h c'est l'option -t 86400 (86400 sec = 24h)

Le mode Jumbo c'est simplement utiliser des paquets qui ont une MTU qui dépasse la limite de 1500 octets de l'Ethernet normal.
La différence de débit utille n'est pas importante car les en-tête représente peu dans un paquet de 1500 octets.
Le seul intéret c'est si ton routeur / firewall a un petit CPU. Comme on parle de paquet par seconde et pas de Mb/s pour un CPU, le fait d'avoir des paquet plus gros permet d'envoyer moins de paquets et de moins saturer le CPU.
Maintenant ce type de pb est rare (on le rencontre sur du matériel bas de gamme avec la VoIP qui envoi de très nombreux petits paquets.)

Je pense que la cause la plus probable de ton mauvais débit en TCP, c'est un PC avec pile TCP/IP mal optimisé (je pense à Windows XP sans modification de sa rwin).

[Brizme]

Salut,

alors en ce qui concerne TCP/IP, je suis arrivé au 900Mbits/s donc pas de probleme pour faire des tests au max de la vitesse et voir si le switch le support longtemps...

pour les tests en UDP, j'ai beau augmenter UDP bandwidth, rien ne change et ca n'augmente pas jusqu'à la vitesse voulue.
Donc pourais-je faire?
merci

[Brizme]

a partir de 141MBytes/s il y a un probleme, la vitesse ne veut pas suivre.

lorsque je met 140M la vitesse est bien de 140, mais si je met 141 la elle redescend à 100Mb/s

la taille de UDP Buffer size sert a quoi exactement? il faut mettre la meme des deux cotés?

[Brizme]

que veux dire : 2 datagrams received out-of-order (2 ou plus...)

[vivien]

que veux dire : 2 datagrams received out-of-order (2 ou plus...)

Les paquets ont été reçus mais trop tard.

Tu utilise quelle version d'IPEFF ?

J'ai eu pas mal de souci avec la 2.0.4 mais par contre la 2.0.2 est parfaite.

Code: [Sélectionner]

$ iperf -v
iperf version 2.0.2 (03 May 2005) pthreads


[Brizme]

pour atteindre la vitesse de 1Gbits/s et voir si il y a bcp de byte perdu je lance sur les ord un test tcp/ip et udp, pense tu que c'est une bonne solution?

[Brizme]

est ce que tu croix que c'est parce que l'ordinateur de l'autre cote ne "suit" pas que j'arrive pas a atteindre les 1Gbits/s?

[vivien]

Si tu arrive a 900 Mb/s en TCP, il y a peu / pas de paquet perdu car TCP réduit la vitesse en cas de perte de paquets (quand un lien est congestionné, la ltence augmente puis on perd des paquets quand le buffer en entrée de la congestion est plein)

TCP/IP géré intéligament le débit des données envoyés de façon à avoir un maximum de débit et un minimum de paquet perdu. Certaines pile TCP/IP sont plus agressive que d'autre (sous linux le débit est un poil plus important que sous windows mais les retransmission (doc paquets perdus) sont un peu plus importantes.

iperf consomme trés peu de CPU. Avec un Celeron 600 Mhz ÉQUIPÉ D'UNE CARTE 1 Gb/s, j'arrive a envoyer plus de 300 Mb/s.

En boucle local (on démarre iperf -c 127.0.0.1 et iperf -s sur le même PC, on arrive à plus de 10 Gb/s sur un pc d'aujourd'hui).

Je pense que ton problème est lié a un bug d'IPERF en UDP. C'est pouir cela que je pense intéressant de tester avec une autre version d'IPERF.