Eu tenho dois computadores desktop conversando diretamente. Ambos possuem adaptadores de rede compatíveis com Gigabit Ethernet. Isso é 1 Gbps ou 1000 Mbps. Eu os conecto com um novo cabo reto Cat6 UTP de 10 metros de comprimento e chego bem perto desse máximo teórico. O Gerenciador de tarefas do Windows (guia Rede) mostra 844 - 946 Mbps em uma direção. Mas na outra direção, ele mostra apenas cerca de 326 - 365 Mbps.
Local: 192.168.100.152
Remote: 192.168.100.151
O computador local executa o Windows 8.1 Pro e eu o conecto remotamente ao outro computador que executa o Windows Vista Ultimate.
Resultados Iperf
Eu usei o Iperf para fazer alguns testes. Fiz o teste por 60 segundos cada vez. Fiz o teste 10 vezes para cada direção da comunicação. Em seguida, reuni esta tabela com os resultados dos testes para obter uma média.
192.168.100.152 -> 192.168.100.151 106 MB/s
192.168.100.152 -> 192.168.100.151 107 MB/s
192.168.100.152 -> 192.168.100.151 108 MB/s
192.168.100.152 -> 192.168.100.151 107 MB/s
192.168.100.152 -> 192.168.100.151 107 MB/s
192.168.100.152 -> 192.168.100.151 104 MB/s
192.168.100.152 -> 192.168.100.151 101 MB/s
192.168.100.152 -> 192.168.100.151 108 MB/s
192.168.100.152 -> 192.168.100.151 108 MB/s
192.168.100.152 -> 192.168.100.151 108 MB/s
----------------------------------------------------
Min: 101 MB/s Max: 108 MB/s Avg: 106.4 MB/s (851.2 Mbps)
192.168.100.152 <- 192.168.100.151 41.1 MB/s
192.168.100.152 <- 192.168.100.151 41.1 MB/s
192.168.100.152 <- 192.168.100.151 41.1 MB/s
192.168.100.152 <- 192.168.100.151 41.0 MB/s
192.168.100.152 <- 192.168.100.151 41.0 MB/s
192.168.100.152 <- 192.168.100.151 41.1 MB/s
192.168.100.152 <- 192.168.100.151 41.0 MB/s
192.168.100.152 <- 192.168.100.151 41.1 MB/s
192.168.100.152 <- 192.168.100.151 41.1 MB/s
192.168.100.152 <- 192.168.100.151 41.1 MB/s
-----------------------------------------------------
Min: 41.0 MB/s Max: 41.1 MB/s Avg: 41.07 MB/s (328.56 Mbps)
Minha pergunta é: por que é tão mais lento na outra direção?
gestor de tarefas do Windows
Este é o diagrama de rede, como visto ao executar os testes no Iperf.
Preste atenção ao diagrama nas duas capturas de tela a seguir!
Você notou como ele mudou de "1 Gbps" para "500 Mbps" no canto superior direito, quando eu mudei de envio para recebimento de dados. Por que fez isso? De alguma forma, ele está sentindo a outra porta de rede como metade de 1 Gbps ao percorrer um caminho, mas ainda cheia ao percorrer o caminho inverso?
Teste de transferência de arquivos
Fiz mais alguns testes com um arquivo de dados para obter leituras mais realistas de disco para disco. Criei um arquivo de 1 GB para esse fim. Eu usei apenas os recursos padrão de compartilhamento de arquivos do Windows. No computador local, conectei-me ao compartilhamento C $ no computador remoto e arrastei e soltei o arquivo para frente e para trás (pular corda) entre eles, alterando o nome do arquivo a cada vez. Cronometrei tudo da melhor maneira possível e foi isso que consegui.
192.168.100.152 -> 192.168.0.151 1073741824 Byte 25 s 40,96 MB/s
192.168.100.152 -> 192.168.0.151 1073741824 Byte 20 s 51.2 MB/s
192.168.100.152 -> 192.168.0.151 1073741824 Byte 16 s 64 MB/s
192.168.100.152 -> 192.168.0.151 1073741824 Byte 16 s 64 MB/s
192.168.100.152 <- 192.168.0.151 1073741824 Byte 11 s 93.091 MB/s
192.168.100.152 <- 192.168.0.151 1073741824 Byte 34 s 30.118 MB/s
192.168.100.152 <- 192.168.0.151 1073741824 Byte 11 s 93.091 MB/s
192.168.100.152 <- 192.168.0.151 1073741824 Byte 11 s 93.091 MB/s
A taxa de transferência indicada pelo diagrama de cópia de arquivo do Windows está contando uma história diferente. Aqui estou baixando dois arquivos, um após o outro, em dois locais diferentes no mesmo disco. A primeira cópia indicava 107 MB / s sustentados até 41%, e a segunda indicava 98,9 MB / s sustentados até 87%.
Portanto, isso está alinhado com os resultados que obtive com a ferramenta Iperf. Agora, aqui está o que parece quando carrego no computador remoto.
Ele suporta 103 MB / s até 73% e, em seguida, cai para fedorentos 27,3 MB / s em 82% e depois sobe um nível para atingir 49,1 MB / s em 93%.
Aqui estão mais dois diagramas de "montanha russa" de aparência engraçada.
Atualização 1 - Velocidade do link
Tentei desativar o adaptador Wifi no computador remoto. (O adaptador Wifi já estava desativado no computador local.) Acho que é isso que a Timtech quis dizer com esse comentário. Eu tinha o mesmo pensamento - ter adaptadores com e sem fio ativados ao mesmo tempo limitava a taxa de transferência no adaptador com fio ao nível do adaptador Wifi (adaptação ao adaptador mais lento para compatibilidade). Como o adaptador Wifi (neste caso, o DWA-160 Wireless N) é geralmente detectado como um link "52 Mbps" - "104 Mbps" pelo computador Vista.
Na captura de tela a seguir, o computador remoto é configurado como um servidor e o computador local como um cliente (192.168.100.152 <- 192.168.100.151).
Mas desconectar o adaptador Wifi no computador remoto não ajudou na minha baixa taxa de transferência na minha conexão com fio.
Não apenas isso! No Gerenciador de tarefas do Windows no computador remoto, a velocidade do link para o adaptador com fio (LAN 1) aparece como "1 Gbps". Se você consultar as capturas de tela acima, poderá ver que ele foi detectado como um link "500 Gbps" no computador local. Portanto, para a mesma conexão com fio, o Windows Vista diz que é um link de 1 Gbps e, ao mesmo tempo, o Windows 8.1 Pro diz que é um link de 500 Gbps ... qual é o certo então?
Aqui está o que parece no computador remoto quando o configuro como cliente e o computador local como servidor (192.168.100.152 -> 192.168.100.151).
Como você pode ver aqui, cerca de 95% do link de 1 Gbps está sendo utilizado. Isso significa 950 Mbps. É exatamente o que recebi no teste acima. Mas o contrário é uma história totalmente diferente.
Atualização 2 - Duplex e MDI-X
Como sugerido por alguns de vocês, dei uma olhada nas configurações de duplex. Os computadores local e remoto foram configurados para o modo de negociação automática, como você pode ver nas capturas de tela abaixo.
Tentei mudar para "1,0 Gbps Full duplex" nos dois computadores. Fiz então o mesmo tipo de teste que fiz antes, usando o Iperf. Com o computador local como servidor e o computador remoto como cliente, chego a 950 Mbps no máximo. Com o computador local como cliente e o computador remoto como servidor, chego a 360 Mbps.
Aqui, dê uma olhada nessas capturas de tela.
O que você vê aqui é o diagrama para quando carrego e faço o download entre os dois computadores. O gráfico mais alto (95 - 98% de utilização) é local para remoto (upstream 192.168.100.152 -> 192.168.100.151). O gráfico mais baixo (~ 33% de utilização) é remoto para local (192.168.100.152 a jusante <- 192.168.100.151).
Para tentar descartar qualquer problema no Auto MDI-X, eu tinha um desses adaptadores cruzados conectados a uma extremidade do cabo (o computador local).
Isso certamente tornaria o cabo um cabo cruzado. Inferno, eu até testei com um testador de rede! De fato, agora está cruzado (pinos 1/3, 2/6)!
Portanto, agora eu tenho uma conexão de cabo crossover verdadeira entre os dois computadores e configurei manualmente "1,0 Gbps Full duplex". Ainda tenho o mesmo problema. Mais alguma ideia? Além de atualizar o computador com Vista (ou reinstalar o computador 8.1)?
Atualização 3 - Limitação de software ou hardware?
Meu melhor palpite é que eu tenho dois sistemas operacionais que não são compatíveis entre si. Ambos são sistemas Windows, mas nem todos os sistemas Windows são iguais. Vou ter que tentar usar o Vista em ambos, ou 8.1 Pro em ambos e ver que tipo de taxa de transferência eu recebo. Isso significa comprar uma atualização. Maldito seja, Microsoft.
Ambos os computadores são construídos de maneira personalizada. Aqui estão algumas especificações.
Local
-----
Gigabyte GA-EP45-UD3R
Intel Core 2 Quad Q9650
Intel P45
Corsair XMS2 DHX TwinX DDR2 PC6400/800MHz 4 GB
Realtek 8111C chips (10/100/1000 Mbit)
WD Caviar Black WD1002FAEX
Windows 8.1 Pro 64-bit
Remote
------
Gigabyte GA-X38-DQ6
Intel Core 2 Duo E4500
Intel X38
Corsair XMS2 DHX TwinX DDR2 PC6400/800MHz 4 GB
Dual Realtek 8111B chip (10/100/1000 Mbit)
WD Caviar Black WD1002FAEX
Windows Vista Ultimate 64-bit
Tonny sugeriu que a máquina Vista estivesse usando um chip Realtek ruim. Então eu descobri essas especificações. Vejo agora que a máquina Vista usa uma revisão B de 8111, enquanto a máquina local usa uma revisão C do mesmo chip. Isso significa alguma coisa? Ambos são claramente especificados para 1000 Mbit (veja acima) pelo fabricante. Será que o 8111B tem um desempenho tão baixo (360 Mbps)?
Essas unidades específicas atingem a taxa de burst de 107 MB / s. Esse é exatamente o número que eu vi no teste no computador local. Mas mesmo a leitura / gravação sequencial ou aleatória sustentada de talvez 55 MB / s NÃO se traduz em 360 Mbps. Isso deve me dar algo em torno de 440 Mbps, e não os 360 Mbps que estou recebendo. Portanto, não suspeito que esse seja o gargalo, principalmente porque os dois usam o mesmo modelo de unidade. Além disso, a operação de cópia de arquivo é uma coisa, mas o Iperf não está usando discos, apenas usa memória RAM para os testes.
Atualização 4 - Transferência de soma de verificação TCP
Conforme sugerido por Tonny, tentei desativar o descarregamento da soma de verificação TCP (para IPv4 e IPv6).
Também mudei "Speed & Duplex" de volta para automático nos dois computadores. Mas isso não ajudou. Ainda tenho a baixa taxa de transferência em uma direção e a alta na outra direção.
Atualização 5 - Nova versão do driver
Tentei atualizar a versão do driver local e remoto para a versão mais recente baixada do site da Gigabyte e do site da Realtek.
Update path...
On local (RTL8111C):
8.1.510.2013 (2013-05-10, Microsoft)
8.20.815.2013 (2013-08-15, Realtek)
On remote (RTL8111B):
6.241.623.2010 (2010-06-23, Realtek)
6.250.908.2011 (2011-09-08, Realtek)
6.252.1109.2012 (2012-11-09, Realtek)
Eu ainda tenho a mesma taxa de transferência ruim em uma direção.
Atualização 6 - Utilização da CPU
Eu verifiquei a utilização da CPU. Isso não deve ser um problema. Aqui estão minhas descobertas.
On local...
Download: 4 - 10 %
Upload: 4 - 10 %
Idle: 0 - 4 %
On remote...
Download: 24 - 38 %
Upload: 10 - 25 %
Idle: 1 - 6 %
Local (download, upload, ocioso) ...
Remoto (download, upload, ocioso) ...
O controle remoto usa muito mais energia da CPU, mas esse também é o com o Core 2 Duo mais lento. Mas nunca excedeu o ponto de 38% durante meus testes. O que é particularmente interessante aqui é que ele usa muito mais energia da CPU ao fazer o download (local -> remoto) do que ao fazer o upload (local <- remoto).
Portanto, com uma taxa de transferência de 950 Mbps, ele usa 38% e a 360 Mbps, 25%. Além disso, a utilização do núcleo não é equilibrada, ele usa um núcleo a mais que o outro. Não tenho certeza de que conclusão tirar disso. O computador local não exibe a utilização principal, portanto não posso compará-lo. Mas a utilização da CPU é uniforme no computador local (10% no download / upload).
Atualização 7 - Novo adaptador de rede Intel Gigabit
Agora instalei um novo adaptador de rede PCI-Express Gigabit da Intel como um substituto do Realtek RTL8111B interno no computador remoto, que é supostamente lento demais no upload. O número do produto do adaptador Intel é EXPI9301CT. Este adaptador deve ser muito bom, de acordo com os comentários que li. Eu só quero descartar isso como um possível gargalo.
Fiz alguns testes agora com o Iperf para Windows e aqui estão os resultados.
Local (download, upload) ...
Remoto (download, upload) ...
Em média, esse adaptador é realmente um pouco mais lento que o adaptador Realtek. Eu acho que tem uma sobrecarga menor que a Realtek e, como resultado disso, uma taxa de transferência contínua mais estável. Mas ainda tenho apenas cerca de 360 Mbps em uma direção e 950 Mbps na outra, mesmo com este adaptador Intel.
local: 192.168.100.152 (win 8, realtek 8111c)
remote: 192.168.100.154 (vista, intel desktop ct)
192.168.100.152 -> 192.168.100.154 113 MB/s
192.168.100.152 -> 192.168.100.154 104 MB/s
192.168.100.152 -> 192.168.100.154 103 MB/s
192.168.100.152 -> 192.168.100.154 104 MB/s
192.168.100.152 -> 192.168.100.154 102 MB/s
192.168.100.152 -> 192.168.100.154 104 MB/s
192.168.100.152 -> 192.168.100.154 101 MB/s
192.168.100.152 -> 192.168.100.154 102 MB/s
192.168.100.152 -> 192.168.100.154 101 MB/s
192.168.100.152 -> 192.168.100.154 104 MB/s
----------------------------------------------
Max: 113 MB/s Min: 101 MB/s Avg: 103.8 MB/s
192.168.100.152 <- 192.168.100.154 42.2 MB/s
192.168.100.152 <- 192.168.100.154 41.2 MB/s
192.168.100.152 <- 192.168.100.154 41.1 MB/s
192.168.100.152 <- 192.168.100.154 43.0 MB/s
192.168.100.152 <- 192.168.100.154 42.3 MB/s
192.168.100.152 <- 192.168.100.154 42.3 MB/s
192.168.100.152 <- 192.168.100.154 40.2 MB/s
192.168.100.152 <- 192.168.100.154 40.9 MB/s
192.168.100.152 <- 192.168.100.154 41.3 MB/s
192.168.100.152 <- 192.168.100.154 42.0 MB/s
-----------------------------------------------
Max: 43.0 MB/s Min: 40.2 MB/s Avg: 41.65 MB/s
Não tenho idéia do porquê de ter atingido 113 MB / s na primeira execução de teste, local para remoto. Manteve essa velocidade durante todo o teste, o gráfico ficou quase estável em 113 MB / s. Como antes, usei um intervalo de 60 segundos para cada execução. Na próxima execução, no entanto, caiu para 104 MB / s.
Como você pode ver por esses valores, ainda tenho a mesma taxa de transferência com este adaptador Intel e com o adaptador Realtek interno. Portanto, acho seguro dizer que não tem nada a ver com o próprio adaptador. Portanto, podemos parar de culpar o RTL8111B por ser um chip inferior / inferior ao RTL8111C encontrado na outra placa-mãe. Parece cada vez mais um problema de software / sistema operacional / configuração ou as três coisas ao mesmo tempo.
Atualização 8 - Ótimos resultados com o Ubuntu LINUX
Depois de esgotar todas as outras opções, finalmente decidi executar alguns testes com o Linux e obtive ótimos resultados. Usei o sistema Ubuntu Linux 13.10 Live e o Iperf para Linux (versão 2.0.5-3) nas máquinas local e remota. Aqui estão os resultados.
=======================================================
REALTEK 8111C <-> REALTEK 8111B | IPERF ON UBUNTU LINUX
=======================================================
local: 192.168.100.152
remote: 192.168.100.151
192.168.100.152 -> 192.168.100.151 112 MB/s
192.168.100.152 -> 192.168.100.151 112 MB/s
192.168.100.152 -> 192.168.100.151 112 MB/s
192.168.100.152 -> 192.168.100.151 112 MB/s
192.168.100.152 -> 192.168.100.151 112 MB/s
192.168.100.152 -> 192.168.100.151 112 MB/s
192.168.100.152 -> 192.168.100.151 112 MB/s
192.168.100.152 -> 192.168.100.151 112 MB/s
192.168.100.152 -> 192.168.100.151 112 MB/s
192.168.100.152 -> 192.168.100.151 112 MB/s
----------------------------------------------
Max: 112 MB/s Min: 112 MB/s Avg: 112 MB/s
192.168.100.152 <- 192.168.100.151 110 MB/s
192.168.100.152 <- 192.168.100.151 111 MB/s
192.168.100.152 <- 192.168.100.151 111 MB/s
192.168.100.152 <- 192.168.100.151 111 MB/s
192.168.100.152 <- 192.168.100.151 111 MB/s
192.168.100.152 <- 192.168.100.151 110 MB/s
192.168.100.152 <- 192.168.100.151 111 MB/s
192.168.100.152 <- 192.168.100.151 111 MB/s
192.168.100.152 <- 192.168.100.151 111 MB/s
192.168.100.152 <- 192.168.100.151 111 MB/s
----------------------------------------------
Max: 111 MB/s Min: 110 MB/s Avg: 110.8 MB/s
Local (download, upload, ocioso) ...
Como você pode ver, recebo o mesmo rendimento nas duas direções ao usar o Ubuntu. É porque eu uso o mesmo sistema operacional em ambas as máquinas ou isso é outra coisa? Eu obteria a mesma taxa de transferência se tivesse as mesmas versões do Windows configuradas nas duas máquinas? Eu não entendo por que isso importaria se eu usasse uma versão do Windows um pouco desatualizada, ou seja, o Vista, em uma máquina e a versão mais recente na outra? . O Windows XP é uma história diferente.
Mas eu sei que eles estão fazendo tudo o que podem para matar o Vista. Por exemplo, o Office 2013 mais recente não é intencionalmente suportado no Windows Vista. Tenho certeza que a Microsoft deseja que o Vista nunca aconteça. Assim como eles desejam que o Windows 8.0 nunca tenha acontecido. Mas geralmente sou tão persistente quanto eles e não atualizo minhas instalações do Windows até que seja absolutamente necessário.
Portanto, a questão é como obter o mesmo rendimento nas duas direções com duas versões diferentes do Windows. O Windows Vista deve ser capaz de velocidade Gigabit - não é um sistema operacional de 20 anos ou algo assim, não é do Windows 95 que estamos falando. Vista é um sistema operacional moderno. Ainda não testei a execução da mesma versão do Windows nas duas máquinas. Pode haver uma diferença na implementação do TCP ou algo entre as duas versões do sistema operacional. Nesse caso, provavelmente serei forçado a atualizar a máquina Vista. Ou isso ou mude para o Linux. Não estou preparado para pagar mais por menos. Por que eu precisaria atualizar o Windows apenas para obter a taxa de transferência Gigabit nas duas direções? ...
Atualização 9 ...
Cabo
Eu tentei reverter o cabo. Obtive os mesmos resultados de antes. Eu também adquiri um novo cabo de conexão Cat 6 e tentei aquele. Os resultados do teste de produtividade foram os mesmos. Portanto, o cabo não é o problema aqui. Usei apenas cabos de conexão pré-terminados / moldados. Portanto, a fiação deve estar correta. Mas pretendo terminar meus próprios cabos de instalação mais tarde.
FW e AV
Quanto ao firewall (FW) e antivírus (AV), não uso nenhum software de FW ou AV de terceiros. Eu só tenho o Firewall do Windows e o Security Essentials. Eu desativei os dois nas duas máquinas. Os resultados do teste de produtividade foram os mesmos de antes.
Teste de velocidade da LAN
Instalei o LAN Speed Test Lite 1.3 na máquina local. Acredito que o teste seja realizado entre a memória local e a unidade de disco na máquina remota. Não tenho certeza. Mas ele pede um caminho de compartilhamento na máquina remota. Eu usei o $ share no controle remoto.
Upload: 427 Mbps
Download: 420 Mbps
Não confio muito nesses resultados. Se você olhar o gráfico, poderá ver que ele varia muito ao longo do teste. O teste foi um teste "sucessivo", ou seja: teste de gravação (upload) primeiro e teste de leitura (download). Obviamente, se você fizer um teste simultâneo de upload / download, a taxa de transferência geral será menor. Mas não estou interessado em tais testes. Até agora, só tenho feito testes "sucessivos" com os testes de transferência de arquivos no Windows (compartilhamento de arquivos / smb) e no Iperf.
Não realizei nenhum teste de memória para memória com o LAN Speed Test porque requer o uso de um programa chamado LST Server no controle remoto, e esse programa requer registro para ser usado.
Atualização 10 ...
Testes de unidade de disco
Eu usei o Crystal Disk Mark 3.0.3 para testar as unidades de disco. Aqui estão os resultados.
Local disk: 118 MB/s read, 113 MB/s write
Remote disk: 70 MB/s read, 69 MB/s write
Essas são velocidades sequenciais de leitura e gravação com base em 5 execuções e uma carga de 1000 MB.
Este é o disco local (marca do disco, leitura, gravação) ...
E este é o disco remoto ...
Mas eu não entendo isso ... esses resultados parecem contraditórios.
Okey, o disco local pode ler a 118 MB / s, o que permitiria o upload relatado de cerca de 100 MB / s. Mas o disco remoto não poderá recebê-lo se for capaz de gravar apenas 69 MB / s. Mas, por alguma reviravolta mágica, ainda recebo pouco mais de 100 MB / s de upload em média.
Indo ao contrário, faz mais sentido. Se o disco remoto puder ler a 70 MB / se o disco local puder gravar a 113 MB / s, o download não deverá ser mais rápido que 70 MB / s. Recebo cerca de 40 MB / s de download em média. Isso pareceria razoável.
Portanto, não posso concluir nada com esses resultados. Quero dizer, a unidade de disco no computador local mal é usada. É também o disco que mantém o sistema operacional e é a única partição nesse sistema. Enquanto o disco remoto está quase cheio, também é particionado com várias partições. No entanto, não é usado para o sistema operacional. Eu escolhi a letra da unidade O:para o teste aqui, porque esta é a partição com mais espaço livre.
(Observe que usei a letra da unidade C:nos testes anteriores, que está em uma unidade de disco da Seagate completamente separada que mantém o sistema operacional na máquina remota. Portanto, essas leituras não são comparáveis.)
Cache de gravação
Com o cache de gravação em disco ativado, obtive esses resultados.
Local to remote: 106 MB/s
Remote to local: 42.2 MB/s
Desativei o cache de gravação em todas as unidades no controle remoto e na unidade local.
Não reinicializei porque nenhuma reinicialização foi solicitada para que as alterações entrassem em vigor. Eu então tenho os seguintes resultados.
Local to remote: 106 MB/s
Remote to local: 42.1 MB/s
Praticamente não houve mudança alguma. Nenhuma reinicialização e nenhuma reinicialização foi solicitada.
Pacote QOS
Em seguida, desabilitei o QOS Packet Scheduler para o adaptador apropriado na máquina remota e depois na máquina local.
Local to remote: 107 MB/s
Remote to local: 41.9 MB/s
Nenhuma mudança significativa aqui. Novamente, nenhuma reinicialização e nenhuma reinicialização foram solicitadas.
Pacotes enormes
Em seguida, habilitei pacotes jumbo que usei a configuração de 4 GB, porque 4 KB é o maior tamanho de MTU suportado nas duas máquinas.
Local to remote: 105 MB/s
Remote to local: 33.3 MB/s
Agora, aqui, o upload (local para remoto) não foi afetado, mas a taxa de transferência do download foi reduzida significativamente. Nenhuma reinicialização foi solicitada, mas decidi reiniciar as duas máquinas de qualquer maneira, apenas por uma boa medida. Em seguida, realizei os mesmos testes novamente e obtive esses resultados.
Local to remote: 117 MB/s
Remote to local: 33.2 MB/s
Portanto, o upload agora é ainda mais rápido, mas o download ainda é mais lento do que era antes de eu fazer essas alterações, mesmo após a reinicialização. Eu esperava que os dois subissem um pouco. O que isto significa?
Respostas:
Com base na sua resposta:
O tamanho da janela TCP representa a quantidade máxima de dados que a pilha TCP esguicha na blindagem dos fios antes de parar e aguardar para receber reconhecimentos da máquina remota - em outras palavras, a quantidade máxima de tráfego não reconhecido na conexão. O fato de a janela TCP na máquina Vista ser muito menor do que na máquina Windows Se7en suporta a teoria de que você não está enchendo o cano o suficiente antes de parar e aguardar os ACKs.
Portanto, a primeira coisa que eu tentaria é aumentar o tamanho da janela TCP na máquina Vista usando o
-wargumento 0,01 MB é uma unidade um tanto inútil; Eu acho que é 16KiB. Então comece com 16KiB e execute um teste:Dobre o tamanho da janela e repita o teste:
Espero que você observe um aumento de velocidade. Continue dobrando o tamanho da janela até não ver mais aumentos significativos de velocidade.
fonte
Como mencionado anteriormente, você precisará modificar o tamanho da janela TCP no iperf para obter maior taxa de transferência através de links de alta velocidade e baixa latência. Versões diferentes do Windows (ou iPerf) podem ter tamanhos de janela padrão diferentes. Tente "256k -w" para começar em ambos o cliente eo servidor.
Você pode confirmar a direção da seta dos seus gráficos? Em iperf, os dados são enviados a partir do cliente para o servidor (oposto do que eu normalmente acho).
Você pode descartar os discos rígidos como a causa, pois o iPerf não toca nos discos rígidos.
Acho que você já verificou que está executando os drivers mais recentes da NIC. Não deve ser necessário mexer na configuração manual da velocidade / duplex. O mesmo acontece com os quadros jumbo - eles não valem a pena com o hardware moderno.
Verifique se o LSO (Large Send Offload) e o LRO (Large Receive Offload) estão habilitados nas duas NICs. Alguns drivers de NIC usam nomes diferentes (ou várias opções que controlam esse comportamento); portanto, você pode precisar procurar. Geralmente, o padrão é ter todos eles habilitados.
fonte
Eu acho que você precisa ler um pouco mais sobre como o iperf funciona. Se você não definir o tamanho correto da janela do tcp, seus resultados variarão bastante. Eu acredito que é o interruptor -w. Este site ajudará no cálculo do tamanho ideal da janela TCP. Você precisa conhecer o RTT e a largura de banda para calculá-lo. http://www.kehlet.cx/docs/tcpwin.php
Tente também outras ferramentas, como o "Teste de velocidade da LAN", que apenas transfere para cima e para baixo entre compartilhamentos em cada extremidade. Seus resultados são bastante próximos nos cinco testes feitos com ele. Certifique-se também de verificar quais são as velocidades máximas de r / w de seus discos rígidos.
fonte
Alguns pontos que podem ajudá-lo .. A pilha de IPs TCP agora é implementada de maneira diferente nas versões posteriores ao Windows 7. Gostaria de olhar atentamente para as minhas otimizações de TCP, pode não haver muito entre suas duas caixas, mas ainda vale a pena ajustar algumas configurações em seu Vista Box.
O uso de netsh int tcp set global congestionprovider = ctcp foi depreciado. Para definir ou alterar o provedor de congestionamento, o seguinte comando deve ser usado:
leia o artigo aqui: http://forums.speedguide.net/showthread.php?280646-When-will-TCP-Optimizer-support-Windows-8-amp-Windows-Server-2012
netsh int tcp definir personalizado complementar 300 10 ctcp desativado 50 Em seguida, digite: netsh int tcp definir personalizado complementar
Para mais detalhes sobre o comando acima, basta digitar: netsh int set complemental
Para verificar qual provedor de congestionamento você está usando no momento, use o seguinte: netsh int tcp show suplementar
Mas apenas o Win Server 2012 pode criar modelos personalizados, CTCP, talvez um problema.
O Auto-Scaling também pode ser um fator.
Talvez valha a pena dar uma olhada nos drivers, talvez precisando de atualização / downgrade. veja quais funcionam melhor.
Outro pensamento é o tamanho dos pacotes gravados no HDD. Qual é o tamanho dos setores do seu HDD formatados para 512b ~ 64K? Pode haver um gargalo em cache. Vale a pena considerar ao usar velocidades GBit - ou teste com o disco SSD!
Você já viu ativar pacotes enormes (se isso se aplica às suas placas de rede)
fonte
Isso parece bastante familiar ... você obtém um
iperfdesempenho inexplicavelmente ruim no Windows, mas o mesmo hardware funciona bem com o Linux.Depois de travar essa batalha várias vezes, cheguei à conclusão de que o
iperfWindows é escamoso . Eu não sei por que ... honestamente, parei de me importar porque sei que sempre posso obter resultados sãos no linux.Portanto, se você quiser saber por que está obtendo um desempenho tão ruim, não procure mais do que o aplicativo.
fonte
Algo a tentar é parar o serviço MMCSS. Sim, você perderá seu áudio temporariamente, mas pode ser que algo esteja ativando-o, fazendo com que a atividade da rede seja acelerada para que a atividade da rede não afogue outras atividades.
Veja aqui algumas informações sobre o MMCSS e a otimização da rede: http://blogs.technet.com/b/markrussinovich/archive/2007/08/27/1833290.aspx
Pode ser ajustado conforme estas instruções: http://support.microsoft.com/kb/948066
Duvido que seja a causa nesse caso, pois a taxa de transferência provavelmente seria menor, mas depois de bater minha cabeça contra a parede por um longo tempo com meus próprios problemas de taxa de transferência no Vista, descobri que essa era a causa. Defino o NetworkThrottlingIndex como 70 e finalmente obtive o rendimento esperado.
fonte
Uma coisa que você ainda não experimentou é remover a compactação diferencial remota no Vista.
Meu pensamento é motivado pelo amplo uso da CPU no Vista. Pode ser que o driver de rede do Vista não saiba como descarregar isso na placa de rede, enquanto o Windows 8 o faz com muito mais eficiência.
Para obter detalhes completos, consulte o artigo:
Evite a cópia lenta de arquivos na rede no Vista, desativando a Compactação Diferencial Remota .
Em poucas palavras, basta desmarcar
Remote Differential Compressionno Painel de Controle -> Programas e Recursos -> Ativar e desativar os recursos do Windows e reiniciar.fonte
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 em atualizar 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.
Desculpe pelas fotos de baixa qualidade.
fonte
O Linus da Linus Tech Tips no Youtube teve o mesmo problema e peço desculpas, mas esqueci qual era a solução. É um vídeo recente (a partir de 20/04/2016), e posso estar errado, mas acho que acabou sendo um caso em que um único encadeamento em um processador é o fator limitante; portanto, se você tiver hardware mais antigo e tiver tentando atingir 1 Gbps, é realmente a CPU que é o problema, se descarregar a maior parte do trabalho para a CPU, o que a maioria das placas de rede integradas faz atualmente. Eu poderia estar enganado, é um vídeo recente dele, eu recomendo que você verifique o fluxo dele. Pelo que vale a pena, estou enfrentando o mesmo problema na minha conexão de internet gigabit.
fonte