Vous ne recevez pas de sonner sur un lien gigabit?

Je viens de passer mon LAN à gigabit. C'est ce que netperf a à dire sur les choses.

Avant:

marcus@lt:~$ netperf -H 192.168.1.1 TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.1.1 (192.168.1.1) port 0 AF_INET : demo Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 87380 16384 16384 10.02 94.13 

Après:

 marcus@lt:~$ netperf -H 192.168.1.1 TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.1.1 (192.168.1.1) port 0 AF_INET : demo Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 87380 16384 16384 10.01 339.15 

Seulement 340 Mbps? Qu'en est-il de ça?

Informations d'arrière-plan: Je me connecte par un commutateur gigabit à un sheevaplug. J'ai un câblage Cat5e dans les murs et la course est peut-être de 30 pieds. Si vous ne connaissez pas netperf, il a tendance à donner des résultats très stables et ne jamais mentir.

Découvrez ce sujet . L'un des contributeurs (Frennzy) le décrit très bien. Je vais citer:

La vitesse "réelle" de Gigabit Ethernet est …

1Gbps.

C'est-à-dire, il transférera des bits au taux de 1 milliard par seconde.

La quantité de données que vous obtenez est liée à divers facteurs:

Connexion NIC au système (PCI vs PCIe vs Northbridge, etc.).

Débit du disque dur.

Appel de bus.

Protocole de couche 3/4 et frais généraux associés.

Efficacité des applications (FTP vs. SMB / CIFS, etc.)

Taille du cadre.

Distribution des tailles de paquets (en fonction de l'efficacité du débit total)

Compression (matériel et logiciel).

Conflit de tampons, fenêtres, etc.

Capacité et architecture de l'infrastructure réseau (nombre de ports, capacité du fond de panier, contestation, etc.)

Bref, vous ne saurez pas vraiment, jusqu'à ce que vous l'éprouviez. NetCPS est un bon outil pour cela, comme beaucoup d'autres.

Et ceci, plus tard dans le fil (ma mise en surbrillance):

Arrêtez de penser comme ça. Arrêter maintenant. Vous tous.

Autant que vous souhaitez trouver un transfert kilo ou méga BYTE par seconde, le fait est variable, même si la vitesse du réseau reste constante. La "vitesse" du réseau (bits par seconde) est absolue. Le débit réseau (données de la charge utile réelle par seconde) n'est pas.

Pour l'OP: voulez-vous, en général, voir des transferts de données plus rapides lorsqu'ils passent de 100Mbps à 1000Mbps? Presque définitivement. Sera-t-il près du maximum théorique? N'est-ce pas valable? C'est à vous de décider.

Si vous voulez parler de la vitesse du réseau, parler de la vitesse du réseau. Si vous souhaitez parler de débit, parlez du débit de données. Les deux ne sont pas liés de manière 1-1.

Le terme «maximum théorique» est lancé, mais il possède une application pratique avec des technologies Ethernet. Sur un système CSMA / CD comme Ethernet, vous ne pouvez envoyer que la moitié de la bande passante du trafic lorsque le fil est maintenu, souvent un peu moins. La raison en est qu'une fois que vous essayez d'aller au-delà de ce «maximum», les émetteurs-récepteurs commenceront à détecter les collisions plus qu'ils ne transmettent de paquets. Ensuite, le retour exponentiel entre en jeu et la transmission de paquets se dégrade encore plus loin. Token Ring a contourné ce problème, mais il a eu beaucoup de ses propres problèmes et n'est plus vraiment utilisé, je crois. Ethernet / IP est devenu la norme de facto.

Les technologies Uplink, comme T3, utilisent des paires asynchrones qui permettent le débit total sur chaque fil, mais ce n'est pas non plus un protocole Ethernet.

Pendant que vous utilisez des périphériques Ethernet standard de base, il y aura toujours le «maximum théorique».

Parler de CSMA / CD dans le contexte de GbE est tout à fait faux. Gigabit Ethernet, ou tout Ethernet "full-duplex", n'utilise pas CSMA / CD. Et tandis que GbE a toujours maintenu la possibilité théorique d'un fonctionnement à demi-duplex, je ne suis pas du tout sûr de l'existence d'un kit GbE de production réel qui a fait demi-duplex.

Quant à la raison pour laquelle l'OP n'a réalisé que 300 bits par Mbit / s sur un lien de 1000 Gbit / s, je suggérerais de rassembler les statistiques netstat pour TCP d'avant et après chaque course netperf et d'inclure les options de ligne de commande -c et -C Pour voir quelle est l'utilisation de l'UC à chaque extrémité. Peut-être que quelque chose sort des paquets, ou peut-être que la CPU d'un côté ou de l'autre est saturée. Si les systèmes de chaque extrémité sont multicouches, vérifiez définitivement les utilisations par cœur avec un outil externe ou en parcourant la sortie de débogage netperf.

D'autres questions netperf sont probablement mieux laissées à la liste de diffusion netperf-talk à netperf.org.