Por que o cartão de 1GBit tem saída limitada a 80 MiB?

Question

Estou tentando utilizar a largura de banda máxima fornecida pela placa de rede 1GiB, mas ela está sempre limitada a 80MiB (megabytes reais). Qual pode ser a razão? Descrição do cartão (saída lshw):

   description: Ethernet interface
    product: DGE-530T Gigabit Ethernet Adapter (rev 11)
    vendor: D-Link System Inc
    physical id: 0
    bus info: pci@0000:03:00.0
    logical name: eth1
    version: 11
    serial: 00:22:b0:68:70:41
    size: 1GB/s
    capacity: 1GB/s
    width: 32 bits
    clock: 66MHz
    capabilities: pm vpd bus_master cap_list rom ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation

A placa é colocada no seguinte slot PCI:

*-pci:2
     description: PCI bridge
     product: 82801 PCI Bridge
     vendor: Intel Corporation
     physical id: 1e
     bus info: pci@0000:00:1e.0
     version: 92
     width: 32 bits
     clock: 33MHz
     capabilities: pci subtractive_decode bus_master cap_list

O PCI não é nenhum PCI Express, certo? É um slot PCI legado? Então talvez seja esse o motivo?

OS é um linux.

    

Answer 1

80 MB / segundo é realmente muito bom! Isso é cerca de 640mbps, o que é muito próximo da capacidade de gigabit da NIC. Se você levar em consideração a sobrecarga TCPIP e a velocidade do disco, provavelmente estará em sua velocidade máxima.

    

Answer 2

Tente colocar isso no seu /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

Cada conexão que fazemos requer uma porta efêmera e, portanto, um descritor de arquivo. Por padrão, isso é limitado a 1024. Para evitar o problema de muitos arquivos abertos, é necessário modificar o ulimit do seu shell. Isso pode ser alterado em /etc/security/limits.conf , mas requer um logout / login. Por enquanto, você pode simplesmente sujar e modificar o shell atual (retorne ao seu usuário não excluído depois de chamar ulimit se você não quiser ser executado como root):

ulimit -n 999999

Outra coisa que você pode tentar que pode ajudar a aumentar o throughput do TCP é aumentar o tamanho da fila da interface. Para fazer isso, faça o seguinte:

ifconfig eth0 txqueuelen 1000

Você pode jogar com controle de congestionamento:

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

Existe também algum ajuste de baixo nível, por ex. parâmetros do módulo do kernel

# /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 

E até afinações de hardware de nível inferior acessíveis via ethtool(1) .

PS. Leia o kernel sobre os documentos, especialmente Documentação / rede / scaling.txt

PPS. Ao ajustar o desempenho do TCP, você pode consultar o RFC6349

PPPS. A D-Link não é o melhor hardware de rede. Experimente o hardware Intel com pci-x ou pci-64

    

Answer 3

O seu barramento PCI de 33 bits e 33Mhz pode transportar no máximo 1.067 megabits por segundo (Mbps) ou 133.33 megabytes por segundo (MBps).

O Gigabit Ethernet pode transmitir 116 megabytes por segundo (MBps).

Portanto, embora o cartão deva ser capaz de saturar completamente a linha, você só obterá cerca de 90% de utilização devido a várias despesas gerais.

De qualquer forma, se você está recebendo 80 megabytes por segundo (MBps), então não está muito longe e ficaria razoavelmente feliz com isso por enquanto.

    

Answer 4

Gigabit ethernet é pouco mais de 1 bilhão bits por segundo. Com codificação de 8/10, isso fornece um máximo de cerca de 100 MB por segundo. Um barramento PCI de 32 bits deve ser capaz de colocar 133MB / seg e você deve ser capaz de saturá-lo (eu posso demonstrar a saturação de um barramento PCI com uma placa de canal de fibra e chegar perto da largura de banda teórica do barramento), então é improvável que seja a causa do gargalo a menos que haja outro tráfego de ônibus.

O gargalo provavelmente está em outro lugar, a menos que você tenha outro cartão usando a largura de banda no barramento.

    

Answer 5

Os gargalos nas velocidades GigE podem vir de vários lugares.

• Subsistema de disco: são necessários pelo menos 3 a 4 discos rígidos em uma matriz RAID de algum tipo para atingir velocidades de GigE. Isso é verdade no envio e no recebimento final.
• CPU: O GigE pode usar muito mais CPU do que você imagina. Dado que está em um slot PCI de 33mhz, eu vou sair em um membro aqui e dizer que este sistema é bastante antigo e pode ter uma CPU mais lenta.
Sobrecarga de TCP / IP: Alguns bits enviados pelo cabo não são a carga de dados, mas outros bits de sobrecarga. Dito isto, tive um sistema que consistentemente atingiu e sustentou 115MB / s com um único link GigE.
• Barramento PCI: A NIC é a única coisa no barramento PCI ou está sendo compartilhada com outro dispositivo.
• Outros fatores: Há muitos outros fatores para mencioná-los, mas alguns dos maiores seriam o que acontece com outras atividades de E / S de disco. É uma mistura de leitura / gravação, muitas pequenas solicitações de E / S, etc.

Answer 6

Qual a sua certeza de que é o cartão que é o gargalo? Pode ser que seja a melhor velocidade possível para negociar com o dispositivo na outra ponta, de modo que fique preso esperando. O outro dispositivo pode estar preso rodando a uma velocidade de 10/100, então 80 ficaria bem com um pouco de sobrecarga.

    

Answer 7

Após minha longa pesquisa, eu postei minhas conclusões:

1. A afinidade do processo e a afinidade iric do NIC devem ser fixas e iguais. O processo do irqbalance (Linux) deve ser interrompido.
2. O cartão deve estar em execução no modo PCIe, por exemplo x4. Se um slot PCIe não suportar esse modo, a placa será executada no modo x1, resultando em afunilamento.

Answer 8

Na minha experiência, 80 MiB / s é muito bom. Eu não vi velocidades muito maiores, não importa qual combinação de NICs e switches estejam sendo usados. Eu me lembro de 100 Mbps mostrando muito o mesmo comportamento. 70-80% de utilização foi praticamente tudo que você poderia pedir, embora eu veja equipamentos de gigabit funcionando acima de 90% no modo de 100 Mbps nos dias de hoje.

Por comparação, minha primeira configuração de gigabit em casa, baseada em comutadores SMC e placas de rede integradas broadcom, mal conseguia administrar 400 Mbps. Agora, anos mais tarde, e usando switches de gerenciamento Netgear, juntamente com as placas de rede Intel e Marlin, geralmente estou na faixa de transferência sustentada de 70-80 MiB / s.

Se você precisar de mais, considere unir várias interfaces.

    

Answer 9

você está obtendo uma velocidade muito boa se puder verificar o final do seu switch

link