Aller au contenu

Messages recommandés

Salut à tous, voici un petit topic sur les jumbo frames et le MTU pour bien mettre au clair ce point car les infos sur le sujet sont très rare et presque exclusivement en anglais.

Tout ceux qui ont déjà été trifouiller dans les drivers de leur carte Ethernet gigabit ou qui ont un switch Ethernet gigabit ont probablement déjà lu le terme de "jumbo frame" ou de "MTU".

Pour expliquer ces deux termes rappelons déjà le fonctionnement de l'Ethernet. Depuis ça création, l'Ethernet utilise des trames (frames en anglais) pour faire communiquer en réseau des équipement, ce sont des sortes de paquets. Chaque donnée qui doit être envoyé par un équipement sur un réseau Ethernet doit utiliser ce format:

ethernet.png

Toute les valeurs sont en octet

le préambule de synchronisation n'est qu'une suite de 0 et 1 pour synchroniser les horloges des switchs et cartes Ethernet ainsi que pour signifier le début d'une trame, vient ensuite l'adresse MAC de destination puis celle de source de la trame, deux octets permettent d'indiquer le type de donnée transportée (IP dans 99% des cas, parfois IPv6 ou encore IPX), viennent ensuite les données et pour finir 4 octets de checksum afin de vérifier que les données ne sont pas corrompues.

Pour mesurer la taille d'une trame Ethernet on mesure depuis l'adresse MAC source jusqu'au checksum (on ignore le préambule). Depuis toujours la norme Ethernet indique qu'une trame doit mesurer entre 64 et 1518 octets, donc cela permet de transporter de 46 à 1500 octets de données.

Le MTU (Maximum Transfert Unit) c'est tout simplement le nombre d'octet maximum de données que l'on peut transporter en une fois sur un média réseau, donc en l'occurrence il est de 1500 pile pour l'Ethernet.

Jusque là rien de bien compliqué, le problème c'est que pour permettre la compatibilité avec les anciens équipements Ethernet ces valeurs n'ont jamais changés ainsi que ce soit en 100Base-TX, en 1000Base-T voir même en 10GBase-CX4 (10gbits/s) les trames doivent toujours avoir une taille entre 64 et 1518 octets soit un MTU de 1500 octets.

Le truc c'est que pour chaque trame envoyé le CPU doit faire l'encapsulation (c'est-à-dire construire la trame), dans les années 1990 avec du 10Base2 ou 10Base-T (10mbits/s) cela ne posait pas vraiment de problème car pour atteindre les 10mbits/s il suffisait d'envoyer environ 820 trames par secondes, ce qui, même pour les CPU de l'époque, n'était pas vraiment un soucis. En revanche de nos jour pour saturer une interface Ethernet gigabit il faut envoyer environ 82345 trames par secondes, un travail monumentale même pour les CPU de nos jours, sans compter que le CPU n'a pas que cela à faire puisqu'il faut également traiter les données elle-mêmes (pour les stocker sur le disque dur par exemple). Résultat lorsque vous faites un transfert entre deux PC en gigabit, a moins d'avoir deux bêtes de courses, vous dépasserez rarement les 600mbits/s et en plus le CPU sera très utilisé. (ce phénomène est aggravé sur les petit boitier NAS qui ont un CPU peu performant)

C'est la qu'interviennent les jumbo frames. Les jumbo frames c'est tout simplement des trames de plus de 1518 octets. Malheureusement il n'existe aucun standard, ainsi même si la taille maximal d'une jumbo frame est généralement de 9000 c'est rarement le cas en pratique et dépend de l'implémentation de chaque constructeur. En gros en utilisant des jumbo frames on divise l'utilisation CPU par 6 pour un débit égale, et lorsque le CPU limitait le débit, le débit max est augmenté.

Malheureusement pour pouvoir utiliser les jumbo frames, il faut que tout les éléments de la chaine par lesquels passent les trames soient compatible et correctement configurés. Il faut donc des cartes réseaux compatible avec les jumbo frame correctement configurés et un (ou plusieurs) switchs compatible.

Mise en place des jumbo frames

Bon, vous avez au moins deux PC avec des cartes réseaux gigabit et un switch gigabit compatible et vous souhaitez activer les jumbo frames, voilà comment procéder.

Pour commencer je vous conseil de mesurer le débit actuel afin de comparer. Utilisez l'excelent utilitaire iperf (distribué avec presque toute les distrib linux, on peut également télécharger une version pour windows). Lancer iperf avec la commande "iperf -s" sur un PC et "iperf -c ip.de.l'autre.pc -w2M -r" sur l'autre. Vous obtiendrez le débit utile entre les deux PC dans chaque sens.

Activez maintenant les jumbo frames dans la configuration de votre carte réseau en prenant la valeur maximale pour commencer :

configcarte.png

Il faut maintenant tester si votre switch passe bien les jumbo frames de la taille que vous avez selectionnez. Pour cela lançon un invite de commande et utilisons la commande ping.

Lancez la commande ping suivante : ping ip.de.l'autre.pc -f -l 8000

Dans cet exemple vous envoyez un ping avec 8000 octets de données, tout en le forçant a n'utiliser qu'une seul trame (-f). Le but de l'a manœuvre est de d'augmenter la valeur jusqu'à ce que le message suivant apparaisse "Le paquet doit être fragmenté mais paramétré DF." la dernière valeur fonctionnelle avant ce message correspond à votre nouveau MTU – 28 octets, par exemple sur une carte sans jumbo frame la dernière valeur possible du ping avant le message "Le paquet doit être fragmenté mais paramétré DF." est de 1500 – 28 = 1472 octets. Notez cette valeur cela pourra être utile pour faire une liste des MTU de différentes cartes réseauw. Ma Realtek 8168D par exemple à un MTU de 9202 lorsque le drivers est sur 9KB (soit une trame maximal de 9220 octets (MTU+18))

Maintenant il faut vérifier le ping avec la dernière valeur avant le message "Le paquet doit être fragmenté mais paramétré DF.", si le ping fonctionne alors c'est tout bon, vous pouvez dès à présent profiter des jumbo frames lors de transferts de fichiers entre les deux PC par exemple. (faites un test iperf!)

En revanche si le ping affiche "Délai d'attente de la demande dépassé." il y a un surement problème qu'il faut absolument résoudre (ou désactiver à nouveau les jumbo frames sur les cartes) sous peine de diminuer fortement les performances. Pour cela commencez par vérifier le MTU de l'autre PC, si celui-ci est identique ou supérieur au premier PC, le problème vient du ou des switchs par lequels passent la trame, si le MTU est inférieur, faites un ping avec le MTU le plus faible des deux PC, si ce ping fonctionne c'est tout bon, sinon cela ne peut-être que le switch qui bloque les trames.

Si le problème vient effectivement du ou des switchs, il faut effectuer des ping en diminuant progressivement la valeur jusqu'à ce que le ping passe (message du genre "Réponse de 192.168.1.1 : octets=1476 temps=1 ms TTL=64"), vous connaitrez ainsi le MTU de votre switch, si ce dernier est situé au environs de 1500 alors le switch ne supporte pas les jumbo frames. Sinon si la valeur est élevée mais un peu inférieur à celle des cartes, il suffit de diminuer le MTU des cartes dans les drivers afin de passer en dessous du MTU du ou des switchs.

Dans mon cas par exemple mes cartes ayant un MTU de 9202 et mon swicth un MTU de 9198, j'ai du baisser d'un cran le MTU dans les drivers pour le mettre sur 8KB (soit un MTU mesuré de 8178)

Voilà maintenant vous pouvez profitez pleinement de votre réseau gigabit et faire des transferts dépassant les 100mo/s comme celui-ci tout en ayant un taux d'utilisation du CPU assez faible.

transfert.pngutilisation.png

Dernière chose en passant, vous pouvez avoir des PC avec les jumbo frames et d'autres sans sur le même réseau sans soucis car lors du démarrage de la connexion TCP les PC échangent leurs MSS (qui est l'équivalent du MTU mais au niveau IP). Actuellement sur mon réseau j'ai par exemple 2 PC avec les jumbo activées et 3 PC sans ainsi que la Livebox (qui ne supporte évidemment pas les jumbo) sans aucun soucis à déclarer.

Lien vers le commentaire
Partager sur d’autres sites

Emplacement reservé pour faire une liste des MTU des cartes et switchs réseau:

Cartes réseau:

Realtek RTL8168D/8111D Family PCI-E Gigabit Ethernet NIC (NDIS 6.20) - MTU 9202 (8178 en mode 8KB)

Marvell Yukon 88E8001/8003/8010 PCI Gigabit Ethernet Controller - MTU 9000

Nvidia nForce 4 10/100/1000 Ethernet Controller - MTU 9000

Switchs gigabits:

TP-Link TL-SG1005D - MTU 9198

Netgear GS608 v2 - MTU 9198

Lien vers le commentaire
Partager sur d’autres sites

  • 2 semaines après...

tient, j'aurai une question

est ce qu'en augmentant la MTU, on peut voir une dégradation du reseau sur les petits paquets ? style reseau uniquement utilisé pour du surf, connection type terminal ou autre ?

car si ca améliore tout le temps, pourquoi pas avoir pas configurer les cartes avec un MTU plus gros (certes, les switch/routeur/etc.. pourraient poser pb s'ils ont aucune fonction de reglage interne de ce coté ci)

Lien vers le commentaire
Partager sur d’autres sites

tient, j'aurai une question

est ce qu'en augmentant la MTU, on peut voir une dégradation du reseau sur les petits paquets ? style reseau uniquement utilisé pour du surf, connection type terminal ou autre ?

car si ca améliore tout le temps, pourquoi pas avoir pas configurer les cartes avec un MTU plus gros (certes, les switch/routeur/etc.. pourraient poser pb s'ils ont aucune fonction de reglage interne de ce coté ci)

Les jumbo frames ne changent strictement rien pour les petits paquets car on augmente uniquement la taille maximale des trames, donc la carte peut toujours envoyer des trames de taille normale (entre 64 et 1518 octets) sans aucune différence jumbo activées ou non.

La seule raison pour laquelle il n'y a pas des jumbo frames encore plus grosses que 9ko c'est tout simplement car il faudrait augmenter le buffer matériel, donc avoir des cartes/switchs un peu plus cher, tous ça pour une fonction que presque personne ne connaît (à tort).

Un bon lien à ce propos: http://staff.psc.edu/mathis/MTU/

Lien vers le commentaire
Partager sur d’autres sites

Pareil, par défaut, j'obtiens entre 80 et 90Mo/s, en traversant à la fois un WRT320N et un TrendNet WER633. Je n'ai pas regardé le WER633, mais j'ai déjà appris que le WRT ne supportait pas, donc...

Par contre, en tenant ces vitesses-là, il est vrai que la conso CPU est assez élevée. Pas intenable avec un Phenom II X4 955BE, avec un core 2 Duo Conroe à 1,6 en face, mais ça se voit quand même.

Lien vers le commentaire
Partager sur d’autres sites

Pareil, par défaut, j'obtiens entre 80 et 90Mo/s, en traversant à la fois un WRT320N et un TrendNet WER633. Je n'ai pas regardé le WER633, mais j'ai déjà appris que le WRT ne supportait pas, donc...

Par contre, en tenant ces vitesses-là, il est vrai que la conso CPU est assez élevée. Pas intenable avec un Phenom II X4 955BE, avec un core 2 Duo Conroe à 1,6 en face, mais ça se voit quand même.

De mon coté avec les jumbo je fais environ 110mo/s de moyenne avec des pointes à 120 entre un Athlon XP 2600+ et un Athlon 64 X2 4200+ S939 (oui oui avec de la DDR première du nom!) avec 25% de CPU sur l'A64

Et entre l'A64 X2 et un Corei5-661, je fais 120mo/s de moyenne (avec l'affichage de Win7 qui marque parfois 140mo/s même si c'est impossible en moyenne), dans ce dernier cas j'avais une belle ligne droite horizontale à 100% de la carte réseau dans le gestionnaire des taches! Impossible de faire ça sans jumbo, le tout avec 15 à 20% de CPU sur le Corei5.

Niveau switch j'en traverse deux pour les transferts en question, ce sont les deux que j'ai listé en premier dans la liste des MTU.

Lien vers le commentaire
Partager sur d’autres sites

La méthode décrite est bien sûr à appliquer sous Windows. Voici donc la méthode à suivre pour activer ces mêmes jumbo frames sous linux, qui sont supportés depuis au moins le noyau linux 2.6.17 :

# ifconfig eth0 mtu 9000

Le chiffre est à adapter de la même manière qu'en cherchant la valeur optimale sous windows. Là, ça l'active uniquement pour la session en cours. Si vous voulez garder le réglage, il va falloir creuser un peu.

Pour du CentOS/Red Hat/Fedora, il faut modifier le fichier /etc/sysconfig/network-script/ifcfg-eth0 et ajouter "MTU 9000" à la fin du fichier.

Pour du Debian/Ubuntu, dans le fichier /etc/network/interface, il faut ajouter une ligne "mtu 9000" pour la carte réseau correspondante.

Je n'ai pu tester la commande que sur Debian, donc il va falloir confirmer pour CentOS, et pour les autres distributions, je n'en sais pas beaucoup plus. Je n'ai pas encore trouvé le temps de me faire violence en installant une Arch ou une Slackware :D

Lien vers le commentaire
Partager sur d’autres sites

Petite remarque sur le fait que les jumbo ne sont ni largement documentés, ni largement mis en avant.

Il est un fait que peu de gens voient : il y a encore 3 ans, le gigabit était très cher, n'était intégré que sur des cartes-mères "haut de gamme", et aucune *box ne le prenait en charge. Les PCs grand-public eux, ne sont encore parfois fournis qu'avec du Fast Ethernet (100Mbps). Comptez aussi que le fait d'avoir plus d'un ordinateur par box (donc par réseau personnel) est lui aussi très récent. Je ne mentionnerais même pas la présence de serveur perso/NAS.

Ne parlons donc pas des besoins de performances quant au transfert de gros fichiers. Surtout que, sans discuter de la légalité de la chose, le plus souvent, il s'agit simplement de stocker ailleurs que sur l'ordi, ou de pouvoir lire un film téléchargé sur un appareil de salon, et là, le plus souvent, le disque dur externe est roi, et donc l'USB.

Donc les performances du Gigabit ne sont pas une priorité. Donc les Jumbo frames non plus.

C'est dommage quand on voit le gain sur les ancêtres d'Alois :D (chapeau bas pour le résultat ceci dit)

Lien vers le commentaire
Partager sur d’autres sites

  • 2 semaines après...
  • 1 an après...

Salut,

Je me suis monté un NAS avec un quelques disques durs, mais je trouve que le débit est limite sur les gros fichiers de 10-15Go en lecture sur le réseau.

Je compte prendre un switch avec le Jumbo Frame, mais je me demande si je n'aurai pas de problème pour communiquer avec la livebox qui elle prend que 1500 de MTU si je passe mes PC a plus de 1500 ?

Lien vers le commentaire
Partager sur d’autres sites

MTU veut dire Maximum Transfer Unit, c'est la taille maximale. Donc ça ne changera rien pour ta livebox qui ne supporte pas les jumbo (forcément comme dirait l'autre). Si t'avais bien tout lu le topic, t'aurais pas posé la question :p

Perso j'ai pas plus creusé la question depuis le temps, vu que je ne passe plus autant de temps à transférer du lourd, et donc les 90Mo/s continuent de me convenir sans problème (surtout que depuis, je suis passé au core i7-2600 :D ).

Lien vers le commentaire
Partager sur d’autres sites

Bon, ça ne marche pas, je suis dégouté, car j'avais bien un switch Jumbo déjà...

Ce qui ma induit en erreur c'est que chacun des mes deux pc on une RTL8111E ET RTL8111DL, et le constructeur dit qu'elles sont OK pour le Jumbo 9K...

Bon moi quand j'ai fait le test ça ne marchait pas donc c'est le switch qui n'est pas Jumbo surtout que je trouvais aucune info sur le net (le switch a 3-4 ans de chez D-Link)...

Puis entre 12-14h je branche le nouveau switch et la même chose... sauf cette fois-ci je vais faire un test de l'autre coté du NAS au PC et la bingo ça marche ^^...

Par contre du PC au NAS rien n’a faire ? je me demande si ça ne vient pas du Windows du NAS qui est pourri ?

j'ai lu a droite et gauche que les derniers driver de la RTL8111E bloqué le Jumbo... ?

Lien vers le commentaire
Partager sur d’autres sites

  • 3 mois après...
  • 3 mois après...

Bonjour Alois54,

Tout d'abord merci pour ce tuto complet et surtout accessible pour le néophyte que je suis.

Ton cas m'intéresse particulièrement, car j'ai également une LiveBox. Je voulais savoir comment tu avais fait tes raccords?

J'ai un pc et un Nas (Qnap TS-469 Pro) tous deux raccordées par un switch gigabit Netgear GS108 V3 (compatible jumbo frame) qui est lui-même raccordé à ma Livebox.

Si je suis ton tuto, active le jumbo frame, et ajuste les MTU sur mon PC et NAS, cela va-t-il poser problème au niveau de ma LiveBox sachant que les 2 matériels passent d’abord par un switch ?

D’avance merci de ton aide.

Lien vers le commentaire
Partager sur d’autres sites

Archivé

Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.

×
×
  • Créer...