Transferências de rede extremamente lentas em uma direção

5

As transferências de arquivos do meu servidor doméstico (executando o Ubuntu 12.04 Server) para qualquer outro PC na LAN (todas executando o Windows 7) são extremamente lentas, mas as transferências de arquivos na outra direção (upload para o servidor) são rápidas.

Eu observei isso com transferências Samba e SFTP, então decidi verificar isso com iperf e obtive os mesmos resultados. A saída no servidor ficou assim:

iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.1.95 port 5001 connected with 192.168.1.82 port 1309
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec   416 MBytes   349 Mbits/sec
------------------------------------------------------------
Client connecting to 192.168.1.82, TCP port 5001
TCP window size: 46.1 KByte (default)
------------------------------------------------------------
[  4] local 192.168.1.95 port 59704 connected with 192.168.1.82 port 5001
[  4]  0.0-12.2 sec  1.50 MBytes  1.03 Mbits/sec

O cliente (My Win 7 PC) produziu esta saída para a mesma execução:

iperf.exe -c 192.168.1.95 -r
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 192.168.1.95, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[  4] local 192.168.1.82 port 1309 connected with 192.168.1.95 port 5001
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec   416 MBytes   349 Mbits/sec
[  4] local 192.168.1.82 port 5001 connected with 192.168.1.95 port 59704
[  4]  0.0-12.2 sec  1.50 MBytes  1.03 Mbits/sec

Resultados semelhantes são observados de outros clientes. Os computadores estão todos conectados ao mesmo comutador com fio Gigabit. Trocar as portas e cabos entre eles dá o mesmo resultado.

A execução das transferências de e para um ramdisk configurado no servidor também não altera a velocidade de transferência; Não acredito que o disco rígido esteja causando o problema.

Eu fiz o meu melhor para procurar problemas similares no Google, mas ainda não encontrei nenhuma solução relevante. Alguém tem alguma ideia?

A seguir estão alguns dumps de comandos de depuração relevantes, no caso de serem de alguma utilidade para pessoas mais experientes que eu.

saída ethtool para a placa ethernet no servidor:

ethtool eth0
Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Half 1000baseT/Full
        Link partner advertised pause frame use: Symmetric Receive-only
        Link partner advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00000033 (51)
                               drv probe ifdown ifup
        Link detected: yes

Saída da ferramenta Mii:

sudo mii-tool
eth0: negotiated 1000baseT-HD flow-control, link ok

Lista de hardware retornada pelo lspci:

sudo lspci
00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
00:00.1 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
00:00.2 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge
00:00.4 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
00:00.7 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237/VX700 PCI Bridge
00:08.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03)
00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)
00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80)
00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:10.0 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.1 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.2 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.3 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.4 USB controller: VIA Technologies, Inc. USB 2.0 (rev 86)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South]
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
01:00.0 VGA compatible controller: VIA Technologies, Inc. CN700/P4M800 Pro/P4M800 CE/VN800 Graphics [S3 UniChrome Pro] (rev 01)

Lista de drivers carregados retornados por lsmod:

sudo lsmod
Module                  Size  Used by
usb_storage            39646  0
vesafb                 13516  1
ppdev                  12849  0
arc4                   12473  2
snd_via82xx            24718  0
gameport               15060  1 snd_via82xx
snd_ac97_codec        110213  1 snd_via82xx
b43                   342801  0
ac97_bus               12642  1 snd_ac97_codec
snd_pcm                80916  2 snd_via82xx,snd_ac97_codec
snd_timer              28931  1 snd_pcm
snd_page_alloc         14108  2 snd_via82xx,snd_pcm
snd_mpu401_uart        13865  1 snd_via82xx
snd_rawmidi            25424  1 snd_mpu401_uart
snd_seq_device         14172  1 snd_rawmidi
snd                    62218  7 snd_via82xx,snd_ac97_codec,snd_pcm,snd_timer,snd_mpu401_uart,snd_rawmidi,snd_seq_device
mac80211              436493  1 b43
soundcore              14635  1 snd
serio_raw              13027  0
i2c_viapro             12969  0
cfg80211              178877  2 b43,mac80211
bcma                   25651  1 b43
parport_pc             32114  1
shpchp                 32265  0
mac_hid                13077  0
via_cputemp            13031  0
hwmon_vid              12723  1 via_cputemp
lp                     17455  0
parport                40930  3 ppdev,parport_pc,lp
pata_via               13428  0
ssb                    50691  1 b43
r8169                  56396  0
sata_via               13495  2

Informação do driver para o cartão Gigabit:

sudo modinfo r8169
filename:       /lib/modules/3.2.0-51-generic-pae/kernel/drivers/net/ethernet/realtek/r8169.ko
version:        6.017.00-NAPI
license:        GPL
description:    RealTek RTL-8169 Gigabit Ethernet driver
author:         Realtek and the Linux r8169 crew <[email protected]>
srcversion:     231149B837AF2B63F7C0271
alias:          pci:v00001186d00004300sv00001186sd00004C00bc*sc*i*
alias:          pci:v000010ECd00008169sv*sd*bc*sc*i*
alias:          pci:v000010ECd00008167sv*sd*bc*sc*i*
depends:
vermagic:       3.2.0-51-generic-pae SMP mod_unload modversions 686
parm:           speed:force phy operation. Deprecated by ethtool (8). (array of int)
parm:           duplex:force phy operation. Deprecated by ethtool (8). (array of int)
parm:           autoneg:force phy operation. Deprecated by ethtool (8). (array of int)
parm:           rx_copybreak:Copy breakpoint for copy-only-tiny-frames (int)
parm:           use_dac:Enable PCI DAC. Unsafe on 32 bit PCI slot. (int)
parm:           debug:Debug verbosity level (0=none, ..., 16=all) (int)

... e uname -a para uma boa medida:

uname -a
Linux hotblack 3.2.0-51-generic-pae #77-Ubuntu SMP Wed Jul 24 20:40:32 UTC 2013 i686 i686 i386 GNU/Linux

Se alguém achar que qualquer outro resultado de depuração seria útil, não hesite em perguntar.

Atualizar

Por falta de uma maneira melhor de testar um driver diferente, eu também tentei voltar para um kernel antigo na inicialização, que retornou r8169 para v2.3LK-NAPI, mas o problema permaneceu o mesmo.

No entanto, fiz uma descoberta interessante. Se eu usar o ethtool para forçar o cartão de volta para 100Mb ...

sudo ethtool -s eth0 speed 100 autoneg on duplex full
sudo ethtool eth0
Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: Unknown
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00000033 (51)
                               drv probe ifdown ifup
        Link detected: yes

... então iperf mostra a conexão funcionando bem em ambas as direções:

------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.1.95 port 5001 connected with 192.168.1.82 port 2437
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec   105 MBytes  87.7 Mbits/sec
------------------------------------------------------------
Client connecting to 192.168.1.82, TCP port 5001
TCP window size: 83.9 KByte (default)
------------------------------------------------------------
[  4] local 192.168.1.95 port 40844 connected with 192.168.1.82 port 5001
[  4]  0.0-10.0 sec   113 MBytes  94.4 Mbits/sec

Não sei exatamente o que concluir disso, mas é pelo menos mais uma evidência de que a velocidade de upload não está sendo restringida pelo hardware ...

    
por 4026 04.08.2013 / 23:07

2 respostas

2

Eu já vi isso antes, causado por uma incompatibilidade de duplex. A especificação para Gigabit ethernet requer que ambos os lados usem o autonegotiate, portanto, certifique-se de que as NICs no servidor e nos clientes estejam configuradas para negociação automática e o mesmo para as portas do switch. Configurá-lo para 1000 / Full explicitamente não o fará.

Eu vejo de uma das suas saídas:

  

negociou o controle de fluxo 1000baseT-HD, link ok

Parece meio-duplex. O que acontece quando ambos os lados não estão configurados para automático é que a fase de negociação automática entre as duas conexões detecta corretamente a velocidade de 1000mbps, mas não consegue descobrir o modo duplex para usar o padrão half duplex. Então você tem 2 dispositivos tentando se comunicar, um em full duplex e outro em half duplex. O resultado líquido é que o tráfego de um lado causa muitos erros de pacote forçando os pacotes a serem reenviados e matando a taxa de transferência nessa direção.

Eu consertei um problema entre um servidor e uma caixa NAS dessa forma, um cartão foi definido como automático e o outro explicitamente como 1000 / Full.

    
por Gary 08.08.2013 / 14:38
0

Eu tive um problema semelhante na minha máquina. O download para a máquina foi de 2MB / s, enquanto o upload da máquina foi de apenas 55kB / s. Eu tentei todos os truques acima, comutadores verificados, cabos etc etc, mas nada funcionou. No final, o que resolveu meu problema foi retirar a placa ethernet do Network Manager (set managed = false em /etc/NetworkManager/NetworkManager.conf) e configurar o dispositivo manualmente em / etc / network / interfaces

auto eth0
iface eth0 inet dhcp

Agora estou recebendo 1MB / s em ambas as direções.

    
por Evan Larsson 05.05.2017 / 05:25