Reprise du message précédent :
on l'as repeté plusieurs fois: le gigabit pour un poste simple n'as pas réellement d'interet. Comme tu le souligne il faut beaucoup de charge pour augmenter le debit et cela depend grandement du PC qui tourne derriere.
C'est utile pour un gros serveur (et donc capable de traiter enormement de données a la seconde) et surtout pour les liaisons entre les switchs, où là les debits sont bien plus elevés.

Oui c'est sur, a vrai dire le 100 Mbit/s me suffit largement pour les 2 ou 3 gigas maxi que j'ai a transferer de temps a autres; mais c'est par curiosité, ce serait interessant de trouver un moyen de faire marcher mieux que ça le Gigabit entre 2 PC, car les cartes reseau en sont bel et bien physiquement capables
Faudrais voir avec les MTUs, beaucoup d'abonnées ADSL a gros débit (~16 Mégas) trainent a 6 ou 7 mégas tant qu'ils ne changent pas les MTUs, et après avoir changé les MTUs, ils retrouvent leur 15-16 Mégas
A essayer avec le gigabit ethernet ! (sauf que je n'ai pas 2 pc en gigabit en ce moment chez moi, ça devra attendre donc^^)
 
Edit : je viens d'essayer avec d'autres MTU mais ça fait pareil
Il faut lancer 15 fois IPerf pour avoir le debit maximal (par contre le débit maximal est bien là après !)

(1 intervalle/seconde)

Voila ce que donne les quelques iperf que j'ai lancé sur 2 machines basiques reliées directement entre elles en gigabit (avec un vieux cable de 20m bricolé pour l'occasion en un croisé).
Soit 340-350Mbs ; avec le simple copier/coller de windows j'obtient la même fourchette pour de gros transferts (rar,zip de quelques gigas).
 

 
J'ai juste une petite demande à faire aux personnes poursuivant ce topic : lisez bien le premier post de Gnaag qui insiste sur les conditions traditionelles d'utilisation d'un réseau gbit domestique... A mon humble avis, la majorité des internautes est davantage interessée par ces valeurs que par des bench plus spécifiques "PME-style".  

 
Depuis j'ai activé les jumbo frames et reréglé tous les paramètres.
Sous iperf, en spécifiant la taille de la fenêtre à 50Ko (le 8Ko par défaut avec une MTU de 9000 ça ne le faisait pas) j'obtiens 990Mbps dans un sens (le max théorique !!) et à peu près 930Mbps dans l'autre sens.
commandes :
iperf -s -w50K -i1
iperf -c @IP -w50K -i1
 
Ci joint le détail de la conf :
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"GlobalMaxTcpWindowSize"=dword:00100000
"MaxTcpWindowSize"=dword:00100000
"Tcp1323Opts"=dword:00000001
"SackOpts"=dword:00000001
"TcpWindowSize"=dword:00009000
+ la MTU passée à 9000 dans la sous section correspondant à l'interface réseau
+ jumbo frames à 9000
 
Pour les transferts de fichiers je monte maintenant à 55Mo/s dans un sens (Athlon -> C2D). A priori c'est bon, limité par le disque dur. par contre ça plafonne toujours dans l'autre sens à 25Mo/s (le sens dont je me sert...)
Le CPU n'indique rien d'anormal (<10%) et les deux disques durs sont identiques (SATA).
 
Je me demande il n'y aurait pas un souci avec le Nforce 4 de l'athlon qui aurait du mal à gérer le Lan intégrer et le contrôleur SATA en même temps.
Est-ce que quelqu'un a vu des améliorations en remplaçant le lan intégré par une carte Gigabit PCIe ?
 
 
Pour les incrédules , le log iperf pour le transfert sur 1 connexion au max thérorique :
C:\Documents and Settings\tom>iperf -c 192.168.0.1 -w100K -i1
------------------------------------------------------------
Client connecting to 192.168.0.1, TCP port 5001
TCP window size:  100 KByte
------------------------------------------------------------
[1920] local 192.168.0.2 port 1771 connected with 192.168.0.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[1920]  0.0- 1.0 sec   118 MBytes   987 Mbits/sec
[1920]  1.0- 2.0 sec   117 MBytes   984 Mbits/sec
[1920]  2.0- 3.0 sec   118 MBytes   990 Mbits/sec
[1920]  3.0- 4.0 sec   118 MBytes   990 Mbits/sec
[1920]  4.0- 5.0 sec   118 MBytes   986 Mbits/sec
[1920]  5.0- 6.0 sec   116 MBytes   974 Mbits/sec
[1920]  6.0- 7.0 sec   118 MBytes   987 Mbits/sec
[1920]  7.0- 8.0 sec   117 MBytes   985 Mbits/sec
[1920]  8.0- 9.0 sec   118 MBytes   990 Mbits/sec
[1920]  9.0-10.0 sec   118 MBytes   987 Mbits/sec
[1920]  0.0-10.0 sec  1.15 GBytes   985 Mbits/sec

Interessant !
Personne n'est passé en 10G ?

Tres intéréssant ce sujet...
 
Pour ma part j'ai aussi tester a puseirus reprise le gigabit
 
Plusieurs Cartes réseaux ( intel , realtek , Broadcom )testé via connexion directe sans switch ( cable cat 5e et 6 )  
 
J'ai utilisé iperf pour tester les debits ,  
 
Toujours a peut pret les meme resultat , 300 - 400 Mb/s , pas ters bon je trouve ..... ( commande classique iperf -c ... iperf -s )
 
En copie via supercopier , les debits ne saturent pas les HDD ( j'atteind , max 30- 35 Mo/s )
 
Dans mon iut , je ne suis aussi  ammuser a test avec cette config :  
 
PC asus ( e2160 ) , carte reseau giga 100/1000 MT , Switch Cisco 24 Ports Giga , avec 2 Upling FO  
 
DU bon matos quoi , ...
 
Via iperf , on atteint en debit max 300Mb/s, via le switch , ou en connection directe
 
Je n'ai pas test plein d'iperf en Parralle ...
 
Mais ma question , pourquoi est t-on obligé d'avoir ces multiples connexions ............ Iperf n'utilise pas les HDD .....
 
TCP / IP  , bride vraiment les debits a ce niveau la ?
 
+

Tu peux essayer en udp ?

Après faut peut être regarder à activer les jumbo frame et/ou augmenter la fenêtre (enfin le coef)
Tu peux aussi analyser avec wireshark voir à quel moment ça coince.

http://www.ezlan.net/giga.html
http://www.ezlan.net/giga_net.html

Ni les jumbo frames (qui proposent surtout une baisse de l'utilisation CPU, et encore c'est moins vrai aujorud'hui avec les cartes réseau TCP/O) ni les modifs de paramètres TCP (utiles uniquement dans des situations bien précises telles que sur des LFP, Large Fat Pipes c'est à dire connexions réseau haut débit mais grande latence) ne permettent de s'affranchir de ces limitations.
 
Pour reprendre mes termes initiaux de ce post, à ma connaissance il n'existe aucun moyen pour exploiter la bande passante du gigabit Eth via les applications cp , supercopier, ou explorer, qui n'utilisent qu'une seule connexion TCP/IP.
Une méthode consiste à utilsier le iScsi, au taf j'obtiens une bande d'environ 100Mo/s pour une seule copie. Le client iScsi utilsie plusieurs connexions TCP/IP...
J'ai en revanche du mal à comprendre EXACTEMENT pourquoi on ne peut obtenir les perfs giga qu'en utlisant plusieurs connexions TCP/IP. Probablement que la version actuelle de TCP develloppée pour obtenir un compromis d'efficacité pour des réseau physiques tels que L'internet et l'Eth 10/100, via ses mécanismes de controle de flux limite le débit pour une seule connexion...

Je viens de réaliser plusieurs test  
 
Et je tombe sur les memes resultats que vous ( sous iperf ) :  
 
Lorsque je modifie la valeur de TCP Windows Size ( 50K par ex ) mes debits s'envolent ( 700 - 800 Mbits )  
 
De meme , lorsque j'utilise une daizaine de connections TCP en parallele
 
Ajouter les 2 a la fois : iperf -c ..... -w 50k -P10 , ne fait pas augmeenter significativement les debits
 
--------------
 
La valeur de TCP Windows Size ( -w ) peut  elle etre assimilé au MTU ou  a la valeur de Jumbo Frame ?
 
Car est il possible de modifier cette valeur ( TCP Windows Size ) lors d'une copie classique ( cp , supercopier , windows .. ) car iperf , c'est bien mais , on fait pas grand chose de Pratique avec
 

 
A mon avis cela vient du fait que lors de l'apparition du gigabit, il fallait que ces nouveaux equipements réseaux puissent garantir une totale compatilité avec le 10 et le 100Mb. bref "on" a augmenté la bande passante MAIS "on" devait rester 100% compatible avec les equipements existants.
 
 

 
En gros la fenêtre de congestion correspond à la taille des données que TCP va envoyer en avance. Si il n'y a pas de ACK qui arrive à ce moment là TCP s'arrête d'envoyer.
Il y a une fenêtre par connexion TCP
 
Iperf sous windows utilise sa propre taille de fenêtre par défaut, 8Ko je crois.
En 10Mbps, 8Ko -> 64Kbps. 64kbps/10Mbps => 6,4ms. Il faut que TCP recoive un ACK 6.4ms après avoir envoyé un paquet pour avoir le débit maximum.
OK, c'est supérieur à un ping donc ça fonctionne.
 
En 1Gb, 64K/1G -> 64ns
La c'est plutôt inférieur au ping donc ça coince. TCP va attendre de recevoir le ACK avant d'envoyer la suite des données.
 
Par contre ca ne limite que pour la connexion associée. Le débit reste dispo pour les autres.

Non, MTU / Jumbo Frame c'est au niveau ethernet. Ca permet de diminuer le nombre de paquets et donc le nombre d'entêtes (léger gain en débit) et la charge CPU.
 
TCP windows size est un paramètre du protocole TCP utilisé pour adapter le débit d'envoi.  

 
Et on fait comment pour modifier le TCP windows size ? Merci
 

TCPoptimizer

Je viens de re-realiser des tests entre 2PC  
 
Gigabyte p35c-ds3r sur realtek & Nvidia mcp73 avec du nvidia  
 
Les debits de copies entre les 2 PC étaient a seulement 30 Mo/s  
 
( Aucune optimisation de rien du tout ! )
 
Une idée ?

30MO/s c'est bien avec du matos grand public. le problème vient aussi souvent des disques qui peuvent pas encaisser tout à la fois. ça tombe bien j'ai lu un test tout à l'heure : http://www.adnpc.net/dossiers/133/lire.php?pg=3 . on voit bien qu'en benchant un dur écrit à 75MO/s avec le vent dans le dos. les conditions du bench ne représentent pas les conditions réelles, donc il ne faut pas non plus t'attendre à aller beaucoup plus vite.
les antivirus et firewall peuvent aussi limiter le débit.

 
J'ai copié sans autre (avec l'explorer classique) des fichiers entre un server win2k8 et un vista SP1 à 115 meg/sec (utilisation du réseau: ~99%)
 
Pour ce qui est du HW, tout est noté dans ma config

copier du raid 0 sur du raid 5 hardware c'est pas vraiment ce que Mr Tout-le-monde fait ^^

Du raid5 vers du raid0; le contraire étant plus lent (calcul de la redondance) =)

c'est pas une carte 100% hardware ? (pas envie de chercher exactement les carac de la RR ^^)

 
J'en profite pour poser mes question :
Est-ce que Vista a été optimisé par rapport à XP pour le support du gigabit ethernet ?
J'imagine que oui. En 2001 à la sortie de XP le gigabit existait pas encore pour le grand public.
Du coup y a peut-être moyen de modifier le paramétrage de XP avec ces options/nouvelles valeurs ?

Tu veux optimiser quoi ?
 
Vista incorpopre toutes les dernières RFC dans sa pile TCP/IP(v6) sorties mais c'est tout.

Je sais pas, la gestion de la fenêtre tcp, l'algorithme d'adaptation du débit... tout ces trucs conçus au départ pour du 10Mbps ou moins.

en 2001 on avait déjà du 100M faut pas exagérer !

Tout ce qui est MTU, fenetre tcp et compagnie sont standarisés. Si des logiciels comme TCPoptimizer fonctionnent cela ne veux pas dire pour autant que c'est parfaitement stable et fiable.
Les normes sont la pour garantie un fonctionnement fiable avec tous les equipements, essaye de bidouiller les parametres avec un switch noname et tu auras des problemes.

C'est standardisé par rapport à quoi ?  
Les technologies évoluent et les paramètres doivent être adaptés en conséquences.
C'est la section SOHO ici. ce qui m'intéresse c'est connecter mes deux PC via un switch (de marque), pas faire tourner un réseau d'entreprise en gigabit.

TCP/IP et ethernet ont été développés dans les années 70

Et donc parce que ta petite personne veux quelque chose de specifique Microsoft devrait 'optimiser' des parametres au risque d'avoir des dizaines de milliers de retour negatifs parce que ca merdouille avec d'autres configurations ?
 
Que tu sois sous linux, windows ou macos il n'y a qu'une seule chose qui compte: tu branche et ca marche. Les OS sont concus dans ce seul but, fournir un systeme le plus universel et fiable possible.
Tout comme Intel fourni des processeurs les plus fiable possible, rien ne t'empeche de les overclocker a ton envie, et rien ne t'empeche de bidouiller les parametres de windows pour essayer de gagner qq Mo/s

 
Et j'ai bien dit que les dernières RFC avaient été implémentées.
Cependant le pb avec tcp est surtout les long fat connections (gros débit et grosses latences).

Evite de troller sur windows stp
 
tout n'est pas écris dans le marbre, les réseaux évoluent :
http://fr.wikipedia.org/wiki/Algorithme_TCP
http://fr.wikipedia.org/wiki/Trans [...] col#Autres
(et non je ne viens pas de réécrire les pages wikipedia à ma convenance )

je ne trolle pas, je t'explique pourquoi certains choix sont fait au detriment des performances. Tu dit que microsoft devrait modifier windows parce que toi tu ne peux pas faire ce que tu veux.
Et puisque que tu veux utiliser wikipedia:
 
"Il n'est pas aisé de parler de meilleure version TCP : il y a des versions adaptées aux réseaux très hauts débits, il y a des versions adaptées aux petits débits, il y a des versions adaptées aux réseaux qui font beaucoup d'erreurs."

http://www.windowsnetworking.com/a [...] Vista.html

Sinon ya les excellents articles de The Cabling Guy

Merci,
Je me sentais pas de chercher les RFC

pour te donner une idee j ai 2 switch linksys layer 2 avec 3 pc sous XP pro et un serveur dell sous SME (linux) tous mes cable sont cat 5e et biensur mes carte reseau egalement. Mes disques dur sont des seagates 400 Go et dans le serveur 250 Go en seagate et dans le gestionnaire de win j atteind env 35 % stable.
 
En revanche j avais au debut un mauvais cable sur un de mes pc ben j arrive a 10 meme pas le 100 passe apres avoir bien tout remis met cable en 5e tout a fonctionner nickel

 
Les disques limités en average a 30Mo/s , peut etre pas quand emem , il y a 4ans encore Ok , mais plus maintenant
 
Quand tu voit les debits des nouveaux Vélo ou HDD 1 Tera ( 100mo/s en average ) ca fait peur
 
Il faut savoir qu'avec un SSd que j'ai testé , j'arrivé a copie sur un de mes Samsung t166 a 80Mo/s ( bonne partie du plateau ), mais avec des HDD recent , il ne faut aps croire que l'on peu etre limité en dessous 50-55Mo/s , chose sure !

 
Un SSD, 80 Mo/s !!
Au prix que ça coûte, autant acheter des disques traditionnels, alors ? Parce que les arguments "consomme moins" (faux), "plus rapide" (faux aussi visiblement), et "fiable" (faux et risible, une cellule flash ne s'écrit pas ad vitam eternam, loin de là). Il reste le "silencieux". Enfin bon, il existe des disques tradi quasi parfaitement silencieux, et pour 20 fois moins cher...
Le seul vrai argument est que c'est bien plus résistant aux chocs et vibrations qui peuvent être présents en utilisation mobile.
Enfin, c'est l'impression que j'ai.

C'est exactement ca concernant les disques SSD.
D'ailleurs il y a eu un communiqué commun de tous les fabriquants de SSD lors du dernier sommet concernant cette technologie disant globalement:
"Attention le SSD c'est bien mais ce n'est pas miraculeux, et c'est loin de ce qui est annoncé par les journaliste en terme de debit, conso et fiabilité"
 
L'article en question: http://www.businessmobile.fr/actua [...] 736,00.htm

 
Oui enfin ''en gros'' c'est pas réellement ce qui m'intéresse... C'est plus EXACTEMENT. Parce qu'il doit y avoir une raison exacte.
Pour moi une appli envoie des données aux couches inférieures sans pouvoir modifier la taille de la fenêtre de congestion.

Oué d'accord. Si tu exiges du "EXACTEMENT", évite de baser ton argumentation sur "si j'étais pas très étonné", "Gros doute même" et "pour moi... "

corrigé