Atualizar

Ok, tentei as respostas abaixo e nada mudou. Identifiquei o chipset no laptop como o NVIDIA nForce 520. Fiz o download dos drivers Vista x64 mais recentes para o nForce 520 (a NVIDIA ainda não possui drivers para esse chipset para o Windows 7). Eu tentei instalar o software de firewall incluído (pensando que talvez esteja interferindo - não é). Eu desinstalei completamente o meu software antivírus (estou usando o Avast!) Pensando que o driver do filtro de rede pode estar causando um problema, o que também não ajudou.

Levei meu laptop para a casa dos meus irmãos e consegui copiar arquivos de 10 a 12 MB / s em sua rede de 100Mbit, então não acho que seja o hardware.

Eu executei o iperf com alguns resultados surpreendentes:
iperf do laptop enviando para o servidor (upload)

> iperf -c naru
------------------------------------------------------------
Client connecting to naru, TCP port 5001
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[328] local 192.168.7.100 port 8549 connected with 192.168.7.6 port 5001
[ ID] Interval       Transfer     Bandwidth
[328]  0.0-10.0 sec   162 MBytes   136 Mbits/sec

> iperf -c naru -w 64k
------------------------------------------------------------
Client connecting to naru, TCP port 5001
TCP window size: 64.0 KByte
------------------------------------------------------------
[328] local 192.168.7.100 port 8550 connected with 192.168.7.6 port 5001
[ ID] Interval       Transfer     Bandwidth
[328]  0.0-10.0 sec  1.06 GBytes   909 Mbits/sec

iperf do servidor enviando para o laptop (download)

> iperf -c miyuki
------------------------------------------------------------
Client connecting to miyuki, TCP port 5001
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[256] local 192.168.7.6 port 51871 connected with 192.168.7.100 port 5001
[ ID] Interval       Transfer     Bandwidth
[256]  0.0-10.1 sec  25.2 MBytes  20.8 Mbits/sec

> iperf -c miyuki -w 64k
------------------------------------------------------------
Client connecting to miyuki, TCP port 5001
TCP window size: 64.0 KByte
------------------------------------------------------------
[256] local 192.168.7.6 port 51872 connected with 192.168.7.100 port 5001
[ ID] Interval       Transfer     Bandwidth
[256]  0.0-10.0 sec  21.1 MBytes  17.6 Mbits/sec

Para comparação, aqui estão os números iperf entre o HTPC e o servidor

Server: Naru, Host: CC (CC sends to Naru)
iperf -c naru:        0.0-10.0 sec   363 MBytes   305 Mbits/sec
iperf -c naru -w 64k: 0.0-10.0 sec  1.06 GBytes   912 Mbits/sec

Server: CC, Host: Naru (Naru sends to CC)
iperf -c cc:        0.0-10.0 sec   322 MBytes   270 Mbits/sec
iperf -c cc -w 64k: 0.0-10.0 sec  1020 MBytes   855 Mbits/sec

O uso do wireshark para assistir a uma transferência do servidor para o laptop gera muitas das seguintes entradas:

(:51aa is the server, :37a1 is the laptop)
No.   Time      Source                    Destination               Proto Info
37785 27.286240 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa  TCP  [TCP Dup ACK 37753#13] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40517974
37786 27.286258 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa  TCP  [TCP Dup ACK 37753#14] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40519414
37787 27.286277 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa  TCP  [TCP Dup ACK 37753#15] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40520854
37788 27.286295 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa  TCP  [TCP Dup ACK 37753#16] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40522294
37789 27.286313 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa  TCP  [TCP Dup ACK 37753#17] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40523734
37790 27.286332 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa  TCP  [TCP Dup ACK 37753#18] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40525174
37791 27.286351 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa  TCP  [TCP Dup ACK 37753#19] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40526614
37792 27.286370 fe80::1569:8500:b24a:51aa fe80::3820:2199:1623:37a1  TCP  [TCP Previous segment lost] [TCP segment of a reassembled PDU]
37793 27.286372 fe80::1569:8500:b24a:51aa fe80::3820:2199:1623:37a1  TCP  [TCP segment of a reassembled PDU]
37794 27.286375 fe80::1569:8500:b24a:51aa fe80::3820:2199:1623:37a1  TCP  [TCP Fast Retransmission] [TCP segment of a reassembled PDU]
37795 27.286377 fe80::1569:8500:b24a:51aa fe80::3820:2199:1623:37a1  TCP  [TCP Out-Of-Order] [TCP segment of a reassembled PDU]
37796 27.286379 fe80::1569:8500:b24a:51aa fe80::3820:2199:1623:37a1  TCP  [TCP Out-Of-Order] [TCP segment of a reassembled PDU]
37797 27.286382 fe80::1569:8500:b24a:51aa fe80::3820:2199:1623:37a1  TCP  [TCP Out-Of-Order] [TCP segment of a reassembled PDU]
37798 27.286413 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa  TCP  [TCP Dup ACK 37753#20] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40528054 SRE=40529494 SLE=40499254 SRE=40526614
37799 27.286432 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa  TCP  [TCP Dup ACK 37753#21] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40528054 SRE=40530934 SLE=40499254 SRE=40526614

Neste ponto, estou completamente perdido quanto ao que tentar em seguida.

Pergunta original

fundo

No momento, estou com um problema no meu laptop Windows 7 recém-instalado. O problema ocorreu originalmente após a instalação do Windows 7 RC. Quando o Windows Vista e o Windows 7 Beta 1 foram instalados neste laptop, eu pude transferir em velocidades de gigabit com os quadros Jumbo ativados na faixa de 9KB / 9014. Os dois switches entre o laptop também suportam quadros Jumbo.

Ao copiar arquivos do meu servidor para o laptop, eles são executados em um ritmo comum (geralmente menos de 1 MB / s), enquanto outros dispositivos que passam pelos mesmos comutadores podem transferir em velocidades mais altas (45 - 55 MB / s). Parece que copiar do laptop para o servidor gera uma velocidade mais rápida, mas nada como deveria ser.

Máquinas envolvidas

• Miyuki: Laptop com o problema. Windows 7 x64 RTM. CTO do HP Pavilion dv9700. Usa um adaptador Ethernet NVIDIA nForce 10/100/1000 Mbps. (O vídeo é GeForce 8400M GS)
• Naru: Servidor com arquivos. Windows Server 2008 R2 x64 SP2 personalizado. Usa um adaptador D-Link DGE-560T PCI Express Gigabit.
• CC: HTPC no mesmo comutador sem problema. Windows Vista x86 SP2. Utiliza um adaptador Realtek RTL8168B / 8111B PCI-E GBE integrado.

Quando essas imagens foram tiradas, os quadros jumbo foram todos desligados.

As imagens

Cópia iniciada no laptop

Servidor -> Laptop _{(fonte: gibixonline.com )} Laptop -> Servidor

Cópia iniciada no servidor

Servidor -> Laptop _{(fonte: gibixonline.com )} Inesperadamente, o servidor copia um arquivo do laptop para si mesmo, resultando em velocidades que eu esperaria. (Laptop -> Servidor) _{(fonte: gibixonline.com )}

Eu afirmei anteriormente que a outra máquina no mesmo comutador não tem esse problema. O DPI alto está ativado, pois é exibido em uma HDTV.
Servidor -> HTPC _{(fonte: gibixonline.com )}

Naturalmente, como teste, decidi ver quais eram as velocidades entre o meu laptop e o HTPC. Infelizmente eles eram exatamente o que eu esperava.
HTPC -> Laptop _{(fonte: gibixonline.com )}

Notas finais

Eu tentei de tudo em que consigo pensar. Até os jumbo-frames estão desativados neste momento e nada parece afetá-lo. Tentei desativar minha proteção antivírus para alterar os cabos que uso. Atualmente, todos os cabos em uso são CAT-5e que eu construí. Tentei pegar o cabo do HTPC e conectá-lo ao meu laptop para ver se o cabeamento era um problema. Os dois comutadores em questão são um D-Link DGS-1216T e um comutador "burro" que suporta frames grandes, o D-Link DGS-2208.

Tente desativar o recurso de autoajuste do Windows.

Em uma janela CMD:

netsh interface tcp set global autotuning=disabled 

Execute novamente seu teste e veja se você notou uma melhora no desempenho. Eu tive que fazer isso em alguns laptops executando o Windows 7 em minha casa, e isso ajudou.

Se as coisas piorarem ou você não notar nenhuma melhoria, poderá reativar o ajuste automático:

netsh interface tcp set global autotuning=normal

Este parece ser um grande problema no Windows 7. Vários jogadores se queixaram desse problema.

1. Em um prompt de comando (geralmente em Todos os Programas -> Acessórios -> Prompt de Comando), execute "regedit"
2. Navegue até HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services \ Tcpip \ Parameters \ Interfaces
3. Procure os itens nas interfaces até encontrar um que possua uma entrada IPAddress correspondente à interface de rede que você deseja afetar (geralmente os endereços IP da LAN começam com 192.168 ou 10.0); observe que, se o seu endereço IP for atribuído automaticamente por um servidor DHCP, talvez seja necessário procurar um DhcpIPAddress correspondente em vez de IPAddress
4. Clique com o botão direito do mouse na interface e selecione Novo> Valor DWORD (32 bits), com o nome "TcpAckFrequency"
5. Clique com o botão direito do mouse no novo valor TcpAckFrequency e selecione Modify, digite "1" (o botão de opção Hexadecimal deve ser selecionado)
6. Clique com o botão direito do mouse na interface e selecione Novo> Valor DWORD (32 bits) e chame-o de “TCPNoDelay” (observe que o TCP está em maiúsculas dessa vez - isso é intencional)
7. Clique com o botão direito do mouse no novo valor TCPNoDelay e selecione Modify, digite "1" (o botão de opção Hexadecimal deve ser selecionado)
8. Verifique se TcpAckFrequency e TCPNoDelay agora são exibidos na lista de propriedades do adaptador com os tipos REG_DWORD e os valores 0 × 00000001
9. Saia do regedit e reinicie (a reinicialização é necessária para que as alterações tenham efeito!)
   10. Jogue um jogo e aproveite seu novo ping baixo

Isso diminuiu meu ping na maioria dos jogos de 200-300ms para 50-60ms, o que corresponde à latência que eu veria por meio de um tracert no servidor do jogo.

Retirado de reduzir a latência da rede de jogos no Windows 7 ou Vista

Para verificar se o laptop não apresenta falhas, execute um live cd do ubuntu, instale o iperf no ramdisk e faça um teste.

Isso deve pelo menos testar o lado da rede.

Verifique se há pacotes descartados. Não sei como fazer isso no Windows, mas se você tiver uma máquina Linux, poderá verificar lá.

Eu tive uma experiência semelhante com um switch de gigabit, onde o modo gigabit estava quebrado e soltando pacotes. Só vi problemas quando tinha duas máquinas conectadas nesse modo. No modo 100K, estava tudo bem. Foi um problema desagradável que me levou alguns dias para descobrir. Eu poderia ter sido um D-Link. Pesquise no seu modelo de switch. Eu fiz e descobri que outros tinham o mesmo problema que eu.

Já deparei com isso antes com outros produtos AV. Meu problema foi no SMB e o produto AV interferiu mesmo quando "desativado". Ele mostrou resultados semelhantes ao wireshark que você possui. Aqui está um dos muitos sites que verifiquei para chegar à causa raiz: Problema com o Symantec SMB e outro: SMB2 falha com o NTP

Além disso, você pode tentar desativar / alterar todas ou algumas das configurações no SMB. Eu consideraria até desativar a v2 no sistema operacional. Verifique este artigo que descreve um problema SMB no Win Vista e este link para a Microsoft descreve alguns dados técnicos sobre as configurações de registro SMB .

Sei que você mencionou o Avast, mas é quase coincidência que eu vi resultados semelhantes do wireshark. Observe que tudo, exceto a transferência de arquivos, parecia funcionar bem no meu caso.

Eu tive problemas com os clientes se comunicando com os servidores Windows ao usar a assinatura de pacotes. Não tive lentidão, mas desistências de conexão muito comuns.

Leia aqui a solução que resolveu meu problema.

Também não vejo sugestões aqui para desativar as funções do TCP Chimney, uma por uma, para verificar se uma delas deu errado.

Parece que o sistema operacional está verificando os pacotes antes de gravar no disco. Eu observei que todas as transferências lentas são as que tentam escrever no laptop ... eu sugiro

• verificação do tamanho dos blocos das partições no disco rígido do laptop (tamanhos pequenos de blocos podem causar um mau tempo de busca de espaço livre ao tentar transferir um único arquivo grande (mais ou menos))
• verificação de qualquer política de firewall que verifique a gravação de disco dos pacotes recebidos
• verificação de qualquer monitor de atividade de arquivo (isso deve ser motivo de preocupação devido à desinstalação do antivírus) (como você sabe, o avast faz verificações de arquivos ao vivo e isso atrasa um pouco a transferência da rede ..)
• desfragmentando a partição de destino (novamente sobre a busca de espaço livre)

Outros são sugeridos e não pareciam estar ajudando:

• auto-tuning
• nível duplex
• cabos ...

Uma última sugestão é: você pode verificar a detecção de link no modo de bateria nas propriedades avançadas do nic? É um laptop e pode haver alguns problemas com as propriedades de economia de energia ... Tente "Sem economia de energia" na detecção de link no modo de bateria e "Cheio" nas configurações de velocidade da bateria.

Estou usando o win7 em um PC de mesa e essas opções não estão incluídas nas propriedades avançadas do meu nic. Desde que eu nunca tenha passado por esse problema, você pode verificar os valores de "Controle de fluxo" para "TX e RX ativado" como opções do meu nic também. O Jumbo está desativado, o Speed ​​and Duplex também é automático na minha config ...

Não consigo pensar em outra solução ... Espero que ajude ...

Anteriormente, eu persigo meu rabo com exatamente o mesmo problema por um tempo! Baixas velocidades de transferência em uma direção, no meu caso de saída (ligação ascendente).

Windows 7 Pro, Celeron J1800 com placa de rede interna Realtek Gigabit 8111C. QNAP 453a e MacBook Pro na outra extremidade.

Quando medido via Iperf3, eu estava obtendo 112 mbps com o meu Windows 7 definido como cliente (uso da CPU de 25 a 30%). E apenas 39-41 Mbps quando definido como servidor, com uso intenso da CPU entre 50-100%. Tão ruim que o PC congelaria em momentos de teste de largura de banda.

Transferência regular de arquivos limitada a 45mbps no máximo, independentemente de eu estar carregando ou baixando arquivos no meu NAS ou no meu MAC.

Eu estava recebendo nada mais que 35-45 megabytes por segundo. Muito frustrante!

Acabou sendo um mau driver da placa de rede. Eu estava obcecado com a atualização de drivers e sempre atualizava meus drivers quando novos eram disponibilizados. Adivinha o quê, depois de várias atualizações, minha placa de rede diminuiu a velocidade.

Alguns de vocês podem dizer, basta excluir o driver antigo e instalar o novo. Simples, ah? Eu tentei e tentei, não funcionou para mim.

Aqui está a minha solução:

Janelas instaladas do zero com drivers OEM no site do fabricante. Também fiz o seguinte:

Em Gerenciador de dispositivos / Cartão de rede / Configurações avançadas / Desativar tudo, exceto CONTROLE DE FLUXO.

Em Recursos do Windows, desative Compactação diferencial remota.

Agora a velocidade média está entre 80 e 100 Mbps.

Por tudo, suponho que você configurou as placas de rede para full-duplex, 100 MBit e não automático?

Você provavelmente vai odiar esta resposta, mas eu tenho que dizer!

Você já tentou atualizar os drivers?

Eu recebo um problema semelhante no meu laptop (NIC baseado em Realtek), que é transferido em torno de 3 MB / s, mas, no momento em que atualizo os drivers para os mais recentes no site, ele sobe para cerca de 40-50MB / s

Só porque os drivers do Windows funcionam, isso não significa que eles são melhores.

Eu suspeitaria que é algo no caminho do servidor para o laptop, por exemplo:

• Porta do switch corrigida para laptop
• Cabeamento Ethernet ou conexões entre switch e laptop

Pela excelente sugestão de @ SaucemanSpiff, você tentou cabear o laptop diretamente no servidor usando um bom cabo CAT5E ou CAT6? Não há necessidade de um cabo cruzado especial, desde que pelo menos uma das interfaces envolvidas suporte Gigabit Ethernet (o que implica Auto MDI-X).

1. Você venceu o PC até a morte com atualizações e o testou fora do local sem falhas. Você já tentou fazer atualizações e tal no SERVER "naru"?

2. A maioria das soluções neste segmento sugeridas por outras pessoas pode se aplicar ao servidor, você já tentou lá?

3. O que acontece quando você testa usando Robocopy (com e sem jumbo)? Se for rápido em ambas as direções, eu usaria o netshark para examinar os cabeçalhos das sessões SMB no início das cópias em cada direção e ver se algo parece diferente na configuração naru- miyuki.

Você já tentou usar a teracopia? Estou usando isso como um substituto padrão para o Windows Copy há mais de um ano, e ele mostrou melhorias nas velocidades de transferência :)

Uma espécie de tiro no escuro, mas poderia ajudar.

• Desative "Compactação diferencial remota" no Painel de controle - Programas e recursos - Ative ou desative os recursos do Windows.
• Remova o IPv6 das propriedades da rede. Você usa o IPv6 na sua LAN? Caso contrário, desative-o.
• Limpe o cache DNS com ipconfig /flushdnsna CLI.

se é devido à alteração do sistema operacional, certamente o problema está no sistema operacional. você deve tentar instalar o Windows 7 service pack mais recente e manter o Windows atualizado com as atualizações mais recentes. e espero o melhor