Pourquoi la carte 1GBit a une sortie limitée à 80 MiB ?

80 Mo / seconde, c'est en fait très bien ! C'est environ 640 Mbps, ce qui est assez proche de la capacité gigabit de la carte réseau. Si vous prenez en compte la surcharge TCPIP et la vitesse du disque, vous êtes probablement à votre vitesse maximale.

Essayez de mettre ceci dans votre /etc/sysctl.conf

# General 10gigabit/LFP tuning
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 65536 16777216
net.ipv4.tcp_syncookies=1
net.ipv4.tcp_max_orphans=1048576
net.ipv4.tcp_orphan_retries=2

# Removes some internal buffering
net.ipv4.tcp_low_latency=1

# Time-wait sockets
# Do not turn on unless you know what you are doing!
#net.ipv4.tcp_tw_recycle=1
#net.ipv4.tcp_tw_reuse=1

# If PMTUD ICMP blackhole appears use
# RFC 4821, Packetization Layer Path MTU Discovery
net.ipv4.tcp_mtu_probing=1

# Netfilter's conntrack
# NB! For high-performance concerns you probably don't want to use `--state` rules at all 
#net.ipv4.netfilter.ip_conntrack_max=1048576
#net.nf_conntrack_max=1048576

# SACKs are an optimization to TCP which in normal scenarios improves considerably performance. 
# In Gigabit networks with no traffic competition these have the opposite effect. 
# To improve performance they should be turned off with: 
#net.ipv4.tcp_sack=0 

# Decrease the time default value for tcp_fin_timeout connection
net.ipv4.tcp_fin_timeout=15
# Decrease the time default value for tcp_keepalive_time connection
net.ipv4.tcp_keepalive_time=1800

# Increased backlog (default: 100/1000 depending on kernel)
net.core.netdev_max_backlog=10000
net.core.somaxconn=10000

# Timestamps adds additional 12 bytes to header and uses CPU
# NB! It caused massive problems for me under benchmark load
# with a high count of concurrent connections.
# ( http://redmine.lighttpd.net/wiki/1/Docs:Performance )
#net.ipv4.tcp_timestamps=0

# Portrange for outgoing connections
# (increase the ephemeral port range)
# NB! After that tuning you probably do not want to listen on port >= 1024
net.ipv4.ip_local_port_range=1024 65535

# Fixing 'Too many open files', Second useful on nginx+aio workloads
fs.file-max=16777216
fs.aio-max-nr=65536

# If you are under DDoS you can
kernel.panic=10
# Lower following values
#net.ipv4.tcp_synack_retries=2
#net.ipv4.tcp_syn_retries=2
#net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait=15
#net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait=15
# If you under ping flood
#net.ipv4.icmp_echo_ignore_all=1

Chaque connexion que nous établissons nécessite un port éphémère, et donc un descripteur de fichier, et par défaut, celui-ci est limité à 1024. Pour éviter le problème des trop nombreux fichiers ouverts, vous devrez modifier l'ulimit de votre Shell. Ceci peut être modifié dans /etc/security/limits.conf mais nécessite un logout/login. Pour l'instant, vous pouvez juste sudo et modifier le Shell actuel (sudo en tant qu'utilisateur non-privé après avoir appelé ulimit si vous ne voulez pas vous exécuter en tant que root) :

ulimit -n 999999

Une autre chose que vous pouvez essayer et qui peut aider à augmenter le débit TCP est d'augmenter la taille de la file d'attente de l'interface. Pour ce faire, procédez comme suit :

ifconfig eth0 txqueuelen 1000

Vous pouvez jouer avec le contrôle de la congestion :

sysctl net.ipv4.tcp_available_congestion_control
sysctl net.ipv4.tcp_congestion_control=htcp

Il existe également des réglages de bas niveau, par exemple les paramètres des modules du noyau.

# /sbin/modinfo e1000
..snip...
parm:           TxDescriptors:Number of transmit descriptors (array of int)
parm:           TxDescPower:Binary exponential size (2^X) of each transmit descriptor (array of int)
parm:           RxDescriptors:Number of receive descriptors (array of int)
parm:           Speed:Speed setting (array of int)
parm:           Duplex:Duplex setting (array of int)
parm:           AutoNeg:Advertised auto-negotiation setting (array of int)
parm:           FlowControl:Flow Control setting (array of int)
parm:           XsumRX:Disable or enable Receive Checksum offload (array of int)
parm:           TxIntDelay:Transmit Interrupt Delay (array of int)
parm:           TxAbsIntDelay:Transmit Absolute Interrupt Delay (array of int)
parm:           RxIntDelay:Receive Interrupt Delay (array of int)
parm:           RxAbsIntDelay:Receive Absolute Interrupt Delay (array of int)
parm:           InterruptThrottleRate:Interrupt Throttling Rate (array of int)
parm:           SmartPowerDownEnable:Enable PHY smart power down (array of int)
parm:           KumeranLockLoss:Enable Kumeran lock loss workaround (array of int)
parm:           copybreak:Maximum size of packet that is copied to a new buffer on receive 

Et même des accords matériels de niveau inférieur accessibles via ethtool(1) .

PS. Lisez les documents du noyau, en particulier Documentation/networking/scaling.txt

PPS. Pour régler les performances de TCP, vous pouvez consulter RFC6349

PPPS. D-Link n'est pas le meilleur matériel réseau. Essayez le matériel Intel avec pci-x ou pci-64.

Votre bus PCI 32 bits, 33Mhz peut transiter un maximum de 1 067 mégabits par seconde (Mbps) ou 133,33 mégaoctets par seconde (MBps).

Gigabit Ethernet peut faire transiter 116 mégaoctets par seconde (MBps).

Donc, bien que votre carte debe être en mesure de saturer complètement la ligne, vous n'obtiendrez en fait qu'une utilisation d'environ 90 % en raison de divers frais généraux.

Quoi qu'il en soit, si vous obtenez 80 mégaoctets par seconde (MBps), vous n'êtes pas loin du compte et je m'en contenterais raisonnablement pour l'instant.

Gigabit ethernet, c'est un peu plus d'un milliard bits par seconde. Avec un encodage 8/10, cela vous donne un maximum d'environ 100 Mo par seconde. Un bus PCI 32 bits devrait être capable de faire passer 133MB/sec et vous devriez pouvoir le saturer (je peux démontrer la saturation d'un bus PCI avec une carte à fibre optique et obtenir un chiffre proche de la bande passante théorique du bus), il est donc peu probable qu'il soit la cause du goulot d'étranglement à moins qu'il y ait un autre trafic sur le bus.

Le goulot d'étranglement est probablement ailleurs, à moins qu'une autre carte n'utilise la bande passante du bus.

Les goulots d'étranglement aux vitesses GigE peuvent provenir de plusieurs endroits.

• Sous-système de disques : Il faut au moins 3 ou 4 disques durs dans une matrice RAID pour pouvoir atteindre les vitesses GigE. Ceci est vrai pour l'envoi et la réception.
• CPU : GigE peut utiliser beaucoup plus de CPU que vous ne le pensez. Étant donné qu'il se trouve dans un emplacement PCI de 33mhz, je vais prendre le risque de dire que ce système est assez vieux et qu'il a peut-être un processeur plus lent.
• La surcharge TCP/IP : Certains bits qui sont envoyés sur le fil ne sont pas les données utiles mais d'autres bits de surcharge. Ceci dit, j'ai eu un système qui a constamment atteint et maintenu 115MB/s avec un seul lien GigE.
• Bus PCI : La NIC est-elle la seule chose sur ce bus PCI ou est-elle partagée avec un autre périphérique.
• Autres facteurs : Il y a trop d'autres facteurs pour tous les mentionner, mais les plus importants sont les autres activités d'E/S du disque. S'agit-il d'un mélange de lecture/écriture, de nombreuses petites requêtes d'E/S, etc.