Bonjour,
Un client me fait remonter des temps de téléchargement de fichier de 100 Mo extrêmement long.
Pour une raison qui m'échappe, le serveur n'atteint pas le débit de 30 Mb/s sur un même LAN.
Les serveurs présents dans la même baie sur le même switch eux livres sans pb leur 100 Mb/s.
J'ai cherché s'il n'y avait pas de flood mais rien. que ce soit par le web en ssh et même avec iperf, le débit n'est pas au rendez-vous.
Je me suis donc plongé dans les sysclt au niveau reseau car pour les gris fichiers les paramètres ne sont pas optimisés mais rien.
si vous avez une piste je suis preneur car là je sèches un peu ...
merci
jc parola
Salut,
C'est pas trés clair: le fichier va d'où à où ? Dans un même lan ou via l'intrawebz ?
Le 11 février 2014 17:25, JC PAROLA contact@sels-ingenierie.com a écrit :
Bonjour,
Un client me fait remonter des temps de téléchargement de fichier de 100 Mo extrêmement long.
Pour une raison qui m'échappe, le serveur n'atteint pas le débit de 30 Mb/s sur un même LAN.
Les serveurs présents dans la même baie sur le même switch eux livres sans pb leur 100 Mb/s.
J'ai cherché s'il n'y avait pas de flood mais rien. que ce soit par le web en ssh et même avec iperf, le débit n'est pas au rendez-vous.
Je me suis donc plongé dans les sysclt au niveau reseau car pour les gris fichiers les paramètres ne sont pas optimisés mais rien.
si vous avez une piste je suis preneur car là je sèches un peu ...
merci
jc parola
Liste de diffusion du FRsAG http://www.frsag.org/
Toutes mes confuses, j'ai lu de travers ... Effectivement, 30 Mbps, c'est très peu :)
Julien Lollivier julien.lollivier@quiris.com (11/02/2014 17:48) :
Pour une raison qui m'échappe, le serveur n'atteint pas le débit de 30 Mb/s sur un même LAN.
Les serveurs présents dans la même baie sur le même switch eux livres sans pb leur 100 Mb/s.
Je dois louper un truc : 100 Mb/s, ça fait 12.5 Mo/s, pas 30. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
problème de duplex mismatch ?
Le 11/02/2014 17:25, JC PAROLA a écrit :
Bonjour,
Un client me fait remonter des temps de téléchargement de fichier de 100 Mo extrêmement long.
Pour une raison qui m'échappe, le serveur n'atteint pas le débit de 30 Mb/s sur un même LAN.
Les serveurs présents dans la même baie sur le même switch eux livres sans pb leur 100 Mb/s.
J'ai cherché s'il n'y avait pas de flood mais rien. que ce soit par le web en ssh et même avec iperf, le débit n'est pas au rendez-vous.
Je me suis donc plongé dans les sysclt au niveau reseau car pour les gris fichiers les paramètres ne sont pas optimisés mais rien.
si vous avez une piste je suis preneur car là je sèches un peu ...
merci
jc parola
Liste de diffusion du FRsAG http://www.frsag.org/
Salut,
Essaye de changer le câble ?! J'ai eu le même problème une fois...
Date: Tue, 11 Feb 2014 17:59:38 +0100 From: christophedeze@wanadoo.fr To: frsag@frsag.org Subject: Re: [FRsAG] Tuning réseau et mauvais performance
problème de duplex mismatch ?
Le 11/02/2014 17:25, JC PAROLA a écrit :
Bonjour,
Un client me fait remonter des temps de téléchargement de fichier de 100 Mo extrêmement long.
Pour une raison qui m'échappe, le serveur n'atteint pas le débit de 30 Mb/s sur un même LAN.
Les serveurs présents dans la même baie sur le même switch eux livres sans pb leur 100 Mb/s.
J'ai cherché s'il n'y avait pas de flood mais rien. que ce soit par le web en ssh et même avec iperf, le débit n'est pas au rendez-vous.
Je me suis donc plongé dans les sysclt au niveau reseau car pour les gris fichiers les paramètres ne sont pas optimisés mais rien.
si vous avez une piste je suis preneur car là je sèches un peu ...
merci
jc parola
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Bonsoir,
L'interface, elle est montée comment avec le switch ? en HD ? FD ? Car 30 Mb/s en half-duplex, si ça échange beaucoup, ça peut arriver...
Le 11/02/2014 17:25, JC PAROLA a écrit :
Bonjour,
Un client me fait remonter des temps de téléchargement de fichier de 100 Mo extrêmement long.
Pour une raison qui m'échappe, le serveur n'atteint pas le débit de 30 Mb/s sur un même LAN.
Les serveurs présents dans la même baie sur le même switch eux livres sans pb leur 100 Mb/s.
J'ai cherché s'il n'y avait pas de flood mais rien. que ce soit par le web en ssh et même avec iperf, le débit n'est pas au rendez-vous.
Je me suis donc plongé dans les sysclt au niveau reseau car pour les gris fichiers les paramètres ne sont pas optimisés mais rien.
si vous avez une piste je suis preneur car là je sèches un peu ...
merci
jc parola
Liste de diffusion du FRsAG http://www.frsag.org/
Le mar 11 fév 14 à 17:25:49 +0100, JC PAROLA contact@sels-ingenierie.com écrivait :
Bonjour,
Bonsoir,
Un client me fait remonter des temps de téléchargement de fichier de 100 Mo extrêmement long.
Pour une raison qui m'échappe, le serveur n'atteint pas le débit de 30 Mb/s sur un même LAN.
Les serveurs présents dans la même baie sur le même switch eux livres sans pb leur 100 Mb/s.
Difficile à dire comme ça ! J'ai déjà vu ce genre de choses pour des raisons idiotes, du genre une carte réseau mal configurée (half-duplex ou limitée à 10 Mb/s). Il faudrait aussi essayer traceroute avec différentes options.
Bonne chance !
commence par le basique :
ifconfig et ethtool coté serveur ! regarde si tu est bien en auto/full/1G et s'il y a des erreurs. même chose coté switch.
bref avant de tunner quoi que ce soit, assure toi que ta liaison n'ait pas de problème physique/l2.
Change de câble (une fois une interface qui se mettait en 10Mb/s au lieu du giga pour ça), et si ton serveur est une VM sur Hyper-V, désactive le VMQ sur ton interface (super chiant à trouver ce bug de broadcom !).
Le 11 février 2014 18:24, Raphael Mazelier raph@futomaki.net a écrit :
commence par le basique :
ifconfig et ethtool coté serveur ! regarde si tu est bien en auto/full/1G et s'il y a des erreurs. même chose coté switch.
bref avant de tunner quoi que ce soit, assure toi que ta liaison n'ait pas de problème physique/l2.
-- Raphael Mazelier
Liste de diffusion du FRsAG http://www.frsag.org/
Le 11/02/2014 18:24, Raphael Mazelier a écrit :
commence par le basique :
ifconfig et ethtool coté serveur ! regarde si tu est bien en auto/full/1G et s'il y a des erreurs. même chose coté switch.
bref avant de tunner quoi que ce soit, assure toi que ta liaison n'ait pas de problème physique/l2.
non j'ai vérifié je suis bien en 1000 Mb/s Full duplex. J'essaye de trouver s'il n'a a pas de drop de packet
ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on MDI-X: Unknown Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000003 (3) Link detected: yes
Le 11/02/2014 21:52, JC PAROLA a écrit :
non j'ai vérifié je suis bien en 1000 Mb/s Full duplex. J'essaye de trouver s'il n'a a pas de drop de packet
ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on
Si c'est un switch cisco, il vaut mieux désactiver l'auto-neg. Ca peut générer pas mal de collisions...
-- Yann
❦ 11 février 2014 22:03 CET, Yann Autissier yann+frsag@autissier.net :
Si c'est un switch cisco, il vaut mieux désactiver l'auto-neg. Ca peut générer pas mal de collisions...
L'autonégociation est obligatoire en 1000BASE-T. Il ne peut pas non plus y avoir de collisions en full duplex.
Un lien intéressant sur le sujet : http://etherealmind.com/ethernet-autonegotiation-works-why-how-standard-shou...
Et les commentaires montrent que beaucoup de monde a la dent dure contre l'autonégociation. Perso, je suspecte ceux qui indiquent avoir moins de problème sans autoneg qu'avec de généraliser leurs expériences d'il y a 10 ans.
Le 11/02/2014 23:13, JC PAROLA a écrit :
il semble que le module igb et debian squeeze ne fassent pas si bon menage.
Non si tu es à 30mbit/s au lieu de 1000mbit/s théorique ce n'est pas dans les optimisations que tu va trouver la solution. Et sinon on a plein de carte igb sur squeeze qui se porte très bien. Donc check les cables, le switch, etc... avant de chercher à faire des trucs avancés.
Le 11/02/2014 22:03, Yann Autissier a écrit :
Si c'est un switch cisco, il vaut mieux désactiver l'auto-neg. Ca peut générer pas mal de collisions...
Non c'est faux. Il faut arrêter avec ce mythe de l'autonégociation et cisco. C’était peut être vrai il y a 10ans mais plus maintenant. La best practice est de tout laisser en auto au contraire.
Le 12 févr. 2014 à 12:28, Raphael Mazelier raph@futomaki.net a écrit :
Le 11/02/2014 22:03, Yann Autissier a écrit :
Si c'est un switch cisco, il vaut mieux désactiver l'auto-neg. Ca peut générer pas mal de collisions...
Non c'est faux. Il faut arrêter avec ce mythe de l'autonégociation et cisco. C’était peut être vrai il y a 10ans mais plus maintenant. La best practice est de tout laisser en auto au contraire.
+1
Il faut arrêter les conneries, les spécifications du giga sur cuivre IMPLIQUENT que l'autoneg DOIT être activé.
C'est pas plus compliqué que ça.
Après tu peux aussi ajouter flow-control receive on / flow-control send on sur le cisco, ca peux aider.
CEPENDANT, il faut noter que c'est pas le switch qui vas ralentir mais l'OS.
S'il n'est pas capable de balouder ses packets car il est plus occupé le flow control vas dire au cisco : 'hey tu peux bufferiser la ?'.
A noter : - voir le scheduler (si t'es en CFQ, ... je dis joker on est dans une liste de sysadmin ici, pas de bidouilleurs du dimance) - voir les irq (tu es avec + cpu : cat /proc/interrupts) - voir si par hasard dans ton bios tu as désactivé SRV-IO si oui = point blague, actives le - voir si par hasard tu n'as pas 200000 modules qui partagent la même irq - show interfaces sur ton cisco te donnes des infos utiles... lis-les.
Le 12/02/2014 13:20, Xavier Beaudouin a écrit :
A noter :
- voir le scheduler (si t'es en CFQ, ... je dis joker on est dans une liste de sysadmin ici, pas de bidouilleurs du dimance)
- voir les irq (tu es avec + cpu : cat /proc/interrupts)
- voir si par hasard dans ton bios tu as désactivé SRV-IO si oui = point blague, actives le
- voir si par hasard tu n'as pas 200000 modules qui partagent la même irq
- show interfaces sur ton cisco te donnes des infos utiles... lis-les.
Je vais regarder ces différents points
dmesg -n8 me donne rien.
une idées me passe pas la tête, comme je m'oriente plus sur un pb de câble, je penche maintenant vers du Spanning Tree.
Une bonne vieille boucle que le switch n'arriverait pas à gérer en fermant le port ?
Salut,
Le 12 févr. 2014 à 15:00, JC PAROLA contact@sels-ingenierie.com a écrit :
Le 12/02/2014 13:20, Xavier Beaudouin a écrit :
A noter :
- voir le scheduler (si t'es en CFQ, ... je dis joker on est dans une liste de sysadmin ici, pas de bidouilleurs du dimance)
- voir les irq (tu es avec + cpu : cat /proc/interrupts)
- voir si par hasard dans ton bios tu as désactivé SRV-IO si oui = point blague, actives le
- voir si par hasard tu n'as pas 200000 modules qui partagent la même irq
- show interfaces sur ton cisco te donnes des infos utiles... lis-les.
Je vais regarder ces différents points
dmesg -n8 me donne rien.
une idées me passe pas la tête, comme je m'oriente plus sur un pb de câble, je penche maintenant vers du Spanning Tree.
Une bonne vieille boucle que le switch n'arriverait pas à gérer en fermant le port ?
Si tu as du cisco partout le spanning tree aura bouclé depuis longtemps, ca c'est si tu maitrise ton réseau.
Le Span est un algo qui converge en arbre. Une fois qu'il s'est calmé ca vas. Sur du cisco si tes ports SERVEURS sont en spanning-tree portfast, la convergence est rapide.
Par contre si tu as fait la grosse bétise de mettre tes ports entre switch en spanning-tree portfast -> erreur fatale.
Je n'ai j'ai eu de limitation a 30Mbp sur un L2 sauf si tu as du multicast (saturation des queue in / out) et cpu des cisco qui fait aille parce que y a un machin pas configuré.
Isole le pb, bouge le cable de ta machine sur un autre port et ou switch. Si le pb persiste, c'est entre la prise RJ de ton serveur et le serveur lui même.
Autre question stupide as tu testé en localhost ::1 / 127.0.0.1 ces tests?
Xavier
Bonsoir,
Xavier Beaudouin kiwi@oav.net :
Le 12 févr. 2014 à 12:28, Raphael Mazelier raph@futomaki.net a écrit :
[...]
Non c'est faux. Il faut arrêter avec ce mythe de l'autonégociation et cisco. C’était peut être vrai il y a 10ans mais plus maintenant. La best practice est de tout laisser en auto au contraire.
+1
Oui.
Il faut arrêter les conneries, les spécifications du giga sur cuivre IMPLIQUENT que l'autoneg DOIT être activé.
C'est pas plus compliqué que ça.
Histoire de préciser sans que les participants ne se sentent obligés d'avaler toute la spec 802.3 (au demeurant moyennement digeste, ici en version 2002): [...] 37.1.4.4 User Configuration with Auto-Negotiation Rather than disabling Auto-Negotiation, the following behavior is suggested in order to improve interoperability with other Auto-Negotiation devices. When a device is configured for one specific mode of operation (e.g. 1000BASE-X Full Duplex), it is recommended to continue using Auto-Negotiation but only advertise the specifically selected ability or abilities. This can be done by the Management agent only setting the bits in the advertisement registers that correspond to the selected abilities.
-> on a quand même le droit d'activer ou non les paramètres négociables.
Après tu peux aussi ajouter flow-control receive on / flow-control send on sur le cisco, ca peux aider.
CEPENDANT, il faut noter que c'est pas le switch qui vas ralentir mais l'OS.
S'il n'est pas capable de balouder ses packets car il est plus occupé le flow control vas dire au cisco : 'hey tu peux bufferiser la ?'.
Je ne comprends pas. S'agit-il d'une description des trames PAUSE ou de complètement autre chose ?
[...]
- voir si par hasard dans ton bios tu as désactivé SRV-IO si oui = point blague, actives le
- voir si par hasard tu n'as pas 200000 modules qui partagent la même irq
Ca supposerait que le module igb emploie des interruptions PCI historiques et non des interruptions MSI [*]. Je ne critique pas le côté plaisanterie de la chose mais je serais curieux de savoir si quelqu'un a déjà croisé un truc pareil.
Le partage d'IRQ avec d'autres modules devrait donc être d'emblée exclus.
[*] La prise en charge des interruptions MSI est d'ailleurs requise par le pilote igb pour le fonctionnement avec SR-IOV, rejoignant ainsi la spec. [blabla SR IOV specification] PFs may implement INTx per the PCI Express Base Specification. VFs must not implement INTx. PFs and VFs shall implement MSI or MSI-X or both if interrupt resources are requested. Each PF and VF must implement its own unique interrupt capabilities
Bonne soirée.
question con, juste parceque j'ai déjà rencontré le problème.
tu n'aurai pas 12 miliars de rules iptables ?
Le 12/02/2014 21:37, Francois Romieu a écrit :
Bonsoir,
Xavier Beaudouin kiwi@oav.net :
Le 12 févr. 2014 à 12:28, Raphael Mazelier raph@futomaki.net a écrit :
[...]
Non c'est faux. Il faut arrêter avec ce mythe de l'autonégociation et cisco. C’était peut être vrai il y a 10ans mais plus maintenant. La best practice est de tout laisser en auto au contraire.
+1
Oui.
Il faut arrêter les conneries, les spécifications du giga sur cuivre IMPLIQUENT que l'autoneg DOIT être activé.
C'est pas plus compliqué que ça.
Histoire de préciser sans que les participants ne se sentent obligés d'avaler toute la spec 802.3 (au demeurant moyennement digeste, ici en version 2002): [...] 37.1.4.4 User Configuration with Auto-Negotiation Rather than disabling Auto-Negotiation, the following behavior is suggested in order to improve interoperability with other Auto-Negotiation devices. When a device is configured for one specific mode of operation (e.g. 1000BASE-X Full Duplex), it is recommended to continue using Auto-Negotiation but only advertise the specifically selected ability or abilities. This can be done by the Management agent only setting the bits in the advertisement registers that correspond to the selected abilities.
-> on a quand même le droit d'activer ou non les paramètres négociables.
Après tu peux aussi ajouter flow-control receive on / flow-control send on sur le cisco, ca peux aider.
CEPENDANT, il faut noter que c'est pas le switch qui vas ralentir mais l'OS.
S'il n'est pas capable de balouder ses packets car il est plus occupé le flow control vas dire au cisco : 'hey tu peux bufferiser la ?'.
Je ne comprends pas. S'agit-il d'une description des trames PAUSE ou de complètement autre chose ?
[...]
- voir si par hasard dans ton bios tu as désactivé SRV-IO si oui = point blague, actives le
- voir si par hasard tu n'as pas 200000 modules qui partagent la même irq
Ca supposerait que le module igb emploie des interruptions PCI historiques et non des interruptions MSI [*]. Je ne critique pas le côté plaisanterie de la chose mais je serais curieux de savoir si quelqu'un a déjà croisé un truc pareil.
Le partage d'IRQ avec d'autres modules devrait donc être d'emblée exclus.
[*] La prise en charge des interruptions MSI est d'ailleurs requise par le pilote igb pour le fonctionnement avec SR-IOV, rejoignant ainsi la spec. [blabla SR IOV specification] PFs may implement INTx per the PCI Express Base Specification. VFs must not implement INTx. PFs and VFs shall implement MSI or MSI-X or both if interrupt resources are requested. Each PF and VF must implement its own unique interrupt capabilities
Bonne soirée.
Le 14 février 2014 10:12, JC PAROLA contact@sels-ingenierie.com a écrit :
Le 13/02/2014 14:27, Pierre `Sn4kY` DOLIDON a écrit :
question con, juste parceque j'ai déjà rencontré le problème.
tu n'aurai pas 12 miliars de rules iptables ?
non plus, j'ai commencé par ça et j'ai même vérifié si la carte n'était pas en promicious
J'ai loupé un mail ou il manque un simple "ifconfig" ?
Salut,
Le 14 févr. 2014 à 11:57, Greg greg-frsag@duchatelet.net a écrit :
Le 14 février 2014 10:12, JC PAROLA contact@sels-ingenierie.com a écrit : Le 13/02/2014 14:27, Pierre `Sn4kY` DOLIDON a écrit :
question con, juste parceque j'ai déjà rencontré le problème.
tu n'aurai pas 12 miliars de rules iptables ?
non plus, j'ai commencé par ça et j'ai même vérifié si la carte n'était pas en promicious
J'ai loupé un mail ou il manque un simple "ifconfig" ?
Ca et un simple show run int gi x/y du switch si c'est un cisco (car on ne sais pas si c'est du cisco ou du dlink?)
Xavier
------------------------------------------------------ De: JC PAROLA contact@sels-ingenierie.com Répondre: JC PAROLA contact@sels-ingenierie.com Date: 11 février 2014 at 21:52:53 À: frsag@frsag.org frsag@frsag.org Sujet: Re: [FRsAG] Tuning réseau et mauvais performance
Le 11/02/2014 18:24, Raphael Mazelier a écrit :
commence par le basique :
ifconfig et ethtool coté serveur ! regarde si tu est bien en auto/full/1G et s'il y a des erreurs. même chose coté switch.
bref avant de tunner quoi que ce soit, assure toi que ta liaison n'ait pas de problème physique/l2.
non j'ai vérifié je suis bien en 1000 Mb/s Full duplex. J'essaye de trouver s'il n'a a pas de drop de packet
ethtool eth0 Settings for eth0:
…
Tu peux nous en donner plus ?
ethtool -S eth0 ethtool -i eth0 … ?
avec ethtool, si c’est du BCM, le premier truc, c’est virer tous les systèmes d’offload… Je n’ai plus la myriade de switchs possible (j’y ai eu affaire avec un vaillant T300 à la maison, et une dedibox, avec la virtu par exemple, dès qu’il voit une MAC qui ne lui correspond pas, il commence par l’ignorer)
-- Julien (JaXX) Banchet
Le 11/02/2014 22:12, Julien (JaXX) Banchet a écrit :
ethtool -S eth0
pas très digeste mais voici l'info
ethtool -S eth0 NIC statistics: rx_packets: 2706423 tx_packets: 3851115 rx_bytes: 421543678 tx_bytes: 4624570581 rx_broadcast: 25421 tx_broadcast: 43 rx_multicast: 0 tx_multicast: 6 multicast: 0 collisions: 0 rx_crc_errors: 0 rx_no_buffer_count: 0 rx_missed_errors: 0 tx_aborted_errors: 0 tx_carrier_errors: 0 tx_window_errors: 0 tx_abort_late_coll: 0 tx_deferred_ok: 0 tx_single_coll_ok: 0 tx_multi_coll_ok: 0 tx_timeout_count: 0 rx_long_length_errors: 0 rx_short_length_errors: 0 rx_align_errors: 0 tx_tcp_seg_good: 773474 tx_tcp_seg_failed: 0 rx_flow_control_xon: 0 rx_flow_control_xoff: 0 tx_flow_control_xon: 0 tx_flow_control_xoff: 0 rx_long_byte_count: 421543678 tx_dma_out_of_sync: 0 tx_smbus: 0 rx_smbus: 0 dropped_smbus: 0 os2bmc_rx_by_bmc: 0 os2bmc_tx_by_bmc: 0 os2bmc_tx_by_host: 0 os2bmc_rx_by_host: 0 rx_errors: 0 tx_errors: 0 tx_dropped: 0 rx_length_errors: 0 rx_over_errors: 0 rx_frame_errors: 0 rx_fifo_errors: 0 tx_fifo_errors: 0 tx_heartbeat_errors: 0 tx_queue_0_packets: 444857 tx_queue_0_bytes: 556928068 tx_queue_0_restart: 0 tx_queue_1_packets: 423675 tx_queue_1_bytes: 526769235 tx_queue_1_restart: 0 tx_queue_2_packets: 604850 tx_queue_2_bytes: 608984342 tx_queue_2_restart: 0 tx_queue_3_packets: 481924 tx_queue_3_bytes: 613367370 tx_queue_3_restart: 0 tx_queue_4_packets: 464706 tx_queue_4_bytes: 593469693 tx_queue_4_restart: 0 tx_queue_5_packets: 498159 tx_queue_5_bytes: 516592048 tx_queue_5_restart: 0 tx_queue_6_packets: 525624 tx_queue_6_bytes: 683604614 tx_queue_6_restart: 0 tx_queue_7_packets: 407320 tx_queue_7_bytes: 507938714 tx_queue_7_restart: 0 rx_queue_0_packets: 329811 rx_queue_0_bytes: 49772184 rx_queue_0_drops: 0 rx_queue_0_csum_err: 0 rx_queue_0_alloc_failed: 0 rx_queue_1_packets: 302208 rx_queue_1_bytes: 43698621 rx_queue_1_drops: 0 rx_queue_1_csum_err: 0 rx_queue_1_alloc_failed: 0 rx_queue_2_packets: 313950 rx_queue_2_bytes: 47181511 rx_queue_2_drops: 0 rx_queue_2_csum_err: 0 rx_queue_2_alloc_failed: 0 rx_queue_3_packets: 309546 rx_queue_3_bytes: 50874787 rx_queue_3_drops: 0 rx_queue_3_csum_err: 0 rx_queue_3_alloc_failed: 0 rx_queue_4_packets: 366357 rx_queue_4_bytes: 61037109 rx_queue_4_drops: 0 rx_queue_4_csum_err: 0 rx_queue_4_alloc_failed: 0 rx_queue_5_packets: 439551 rx_queue_5_bytes: 57594433 rx_queue_5_drops: 0 rx_queue_5_csum_err: 0 rx_queue_5_alloc_failed: 0 rx_queue_6_packets: 342210 rx_queue_6_bytes: 47229125 rx_queue_6_drops: 0 rx_queue_6_csum_err: 0 rx_queue_6_alloc_failed: 0 rx_queue_7_packets: 302790 rx_queue_7_bytes: 53330216 rx_queue_7_drops: 0 rx_queue_7_csum_err: 0 rx_queue_7_alloc_failed: 0
Le 11/02/2014 22:12, Julien (JaXX) Banchet a écrit :
avec ethtool, si c’est du BCM, le premier truc, c’est virer tous les systèmes d’offload… Je n’ai plus la myriade de switchs possible (j’y ai eu affaire avec un vaillant T300 à la maison, et une dedibox, avec la virtu par exemple, dès qu’il voit une MAC qui ne lui correspond pas, il commence par l’ignorer)
voici les logs de demarrage du serveur (dmesg) concernant cette carte:
[ 5.753572] igb 0000:05:00.0: Intel(R) Gigabit Ethernet Network Connection [ 5.753576] igb 0000:05:00.0: eth0: (PCIe:2.5Gb/s:Width x4) e4:11:5b:de:bb:a6 [ 5.753652] igb 0000:05:00.0: eth0: PBA No: FFFFFF-0FF [ 5.753655] igb 0000:05:00.0: Using MSI-X interrupts. 8 rx queue(s), 8 tx queue(s) [ 5.753675] igb 0000:05:00.1: PCI INT B -> GSI 42 (level, low) -> IRQ 42 [ 5.753696] igb 0000:05:00.1: setting latency timer to 64 [ 5.753935] igb 0000:05:00.1: irq 69 for MSI/MSI-X [ 5.753937] igb 0000:05:00.1: irq 70 for MSI/MSI-X [ 5.753940] igb 0000:05:00.1: irq 71 for MSI/MSI-X [ 5.753942] igb 0000:05:00.1: irq 72 for MSI/MSI-X [ 5.753945] igb 0000:05:00.1: irq 73 for MSI/MSI-X [ 5.753948] igb 0000:05:00.1: irq 74 for MSI/MSI-X [ 5.753950] igb 0000:05:00.1: irq 75 for MSI/MSI-X [ 5.753953] igb 0000:05:00.1: irq 76 for MSI/MSI-X [ 5.753956] igb 0000:05:00.1: irq 77 for MSI/MSI-X [ 5.753975] igb 0000:05:00.1: 0 vfs allocated [ 5.945166] igb 0000:05:00.1: Intel(R) Gigabit Ethernet Network Connection [ 5.945169] igb 0000:05:00.1: eth1: (PCIe:2.5Gb/s:Width x4) e4:11:5b:de:bb:a7 [ 5.945246] igb 0000:05:00.1: eth1: PBA No: FFFFFF-0FF [ 5.945248] igb 0000:05:00.1: Using MSI-X interrupts. 8 rx queue(s), 8 tx queue(s)
Le 11/02/2014 22:20, JC PAROLA a écrit :
avec ethtool, si c’est du BCM, le premier truc, c’est virer tous les systèmes d’offload… Je n’ai plus la myriade de switchs possible (j’y ai eu affaire avec un vaillant T300 à la maison, et une dedibox, avec la virtu par exemple, dès qu’il voit une MAC qui ne lui correspond pas, il commence par l’ignorer)
je viens de trouver un post (http://serverfault.com/questions/357799/improving-tcp-performance-over-a-gig...) indiquant qu'il faut forcer la négociation et que la perte de performance est plus due aux interruptions qu'autres choses.
ethtool -s eth0 autoneg off && ethtool -s eth0 speed 100
qu'en pensez-vous ? Avez vous déjà plus valider des améliorations de perf sur le forçage de la négo ?
Le 11/02/2014 22:20, JC PAROLA a écrit :
je viens de trouver un post (http://serverfault.com/questions/357799/improving-tcp-performance-over-a-gig...) indiquant qu'il faut forcer la négociation et que la perte de performance est plus due aux interruptions qu'autres choses.
ethtool -s eth0 autoneg off && ethtool -s eth0 speed 100
Oui, faudra certainement faire un ifdown avant, et ifup après dans l’idéal…
Aussi, à lire: http://downloadmirror.intel.com/13663/eng/README.txt
Le coup des queues/interrupts, contre-carré par les faux-cores de l’hyperthreading, gérer les affinités, autant de particularités d’Intel dont j’ai pas l’habitude mais la doc est sympa.
-- Julien (JaXX) Banchet
voici les logs de demarrage du serveur (dmesg) concernant cette carte:
[ 5.753572] igb 0000:05:00.0: Intel(R) Gigabit Ethernet Network Connection…
ah! une idée:
dmesg -n 8
histoire d’avoir l’historique « bas niveau » du lien.
après, au modprobe: jongler avec l’autoneg comme suggéré, dans des cas limites, c’est pas génial, et désactiver l’EEE (le truc pour sauver les forets et éviter les usines à charbon, faut de tout manière désactiver l’autoneg)
-- Julien (JaXX) Banchet
-
Christophe Dezé -
David B. -
Francois Romieu -
Greg -
JC PAROLA -
Julien (JaXX) Banchet -
Julien Lollivier -
Méhdi Denou -
Pierre `Sn4kY` DOLIDON -
Raphael Mazelier -
Sébastien 65 -
Thierry Thomas -
Thomas Duval -
Vincent Bernat -
Xavier Beaudouin -
Yann Autissier