bonjour
je met en place les frames jumbo en mon pc sous XP
le serveur sous SQUEEZE et le nas sous FREENAS
et mon switch NETGEAR
ma carte du XP à 2 réglages: 4088 et 9014
la SQUEEZE je peux la régler à 7200 max
le FREENAs je rentre à la mano la valeur que je veux
tout comme le NETGEAR
question
en paramétrant le XP à 9014, est se que les frames jumbo s’adaptent
en fonction de la valeur plus faible, ou faut il mettre la même valeur
sur toute la chaine. ???
a+
La première choses aurait été d’expliquer les “frames jumbo”. Même si quelqu’un ne peu répondre, le fait d’apprendre des choses est toujours agréable 
[quote=“gilles974”]
en paramétrant le XP à 9014, est se que les frames jumbo s’adaptent
en fonction de la valeur plus faible[/quote]
Non. Il n’y a pas de mécanisme permettant à tout le monde d’annoncer sa MTU et de se caler sur la valeur la plus faible. C’est pour cela que toutes les interface d’un même sous-réseau doivent avoir la même MTU, qui est donc la plus basse commune.
Certes pour les communications TCP cela devrait quand même fonctionner car chaque extrémité annonce sa MSS (maximum segment size), qui est liée à la MTU.
En quel honneur ? Si maintenant on a besoin de fournir des définitions des termes techniques standard qu’on utilise quand on pose une question, juste pour l’édification des ignorants fainéants, on n’a pas fini…
Les curieux sauront bien chercher et trouver par eux-mêmes.
merci pascal pour ta réponse
est ce normal que debian me sorte un msg erreur lors du passage
du mtu à 9014
alors que la carte le gere (RTL8811/8168B) ??
ifconfig eth0 mtu 9014
a+
Normal, je ne saurais dire. Mais cela s’explique. On trouve dans le fichier drivers/net/r8169.c des sources du noyau 2.6.32, qui contient le code source du module r8169 gérant les contrôleurs ethernet gigabit de la famille du Realtek RTL8111/8168B, la définition suivante :
et plus bas le test suivant qui l’utilise :
if (new_mtu < ETH_ZLEN || new_mtu > SafeMtu)
return -EINVAL;
Le nombre hexadécimal 0x1c20 représente 7200 en décimal. Le commentaire suggère que des problèmes ont été constatés avec des valeurs supérieures, sans autre explication.
[Edit]Un début d’explication est fourni dans la description du patch appliqué à la version 2.6.11 du noyau responsable de cette limitation :
[code] [PATCH] r8169: reduce max MTU for large frames
From: Francois Romieu <romieu@fr.zoreil.com>
The device does not support the whole mtu range it claims. Experimenting
with the Tx threshold and/or the PCI burst size does not seem to improve
the behavior.[/code]
Si tu es joueur, tu peux essayer de modifier la valeur dans les sources et recompiler le module. Après tout, cela date du temps où ce module ne gérait pas encore les contrôleurs RTL8168 (à partir du noyau 2.6.19). Il se peut que cette limitation ne s’applique qu’au RTL8169.
[Edit 2]
A ce sujet, il y a eu du changement dans les versions plus récentes du noyau. Depuis la version 3.2 (incluse dans Wheezy, la prochaine Debian stable), la taille maximum des jumbo frames a été ajustée selon le type de contrôleur. Mauvaise nouvelle pour toi : celle du RTL8111B/8168B a été revue à la baisse, à (4*1024 - ETH_HLEN - 2) soit 4080 si mes calculs sont exacts.
Note : le pilote rtl8168 fourni par Realtek pourrait supporter des tailles plus élevées.
salut
sans rentrer dans les sources, j’ai pu lire qu’effectivement le driver realteck
pouvais prendre les frame à 9200. Mais pour cela il faut installer le driver
maison de realtk
je vais m’y atteler, et te tiens au courant du resultat
suite
je confirme : pour avoir les frames à 9014 j’ai du installer le driver maison realteck
et faire un
a+ gilles