Tengo dos computadoras de escritorio hablando entre ellas directamente. Ambos tienen adaptadores de red con capacidad Gigabit Ethernet. Eso es 1 Gbps o 1000 Mbps. Los tengo conectados con un nuevo cable recto Cat6 UTP de 10 metros de largo y me acerco bastante a ese máximo teórico. El Administrador de tareas de Windows (pestaña Red) muestra 844 - 946 Mbps en una dirección. Pero en la otra dirección, solo muestra entre 326 y 365 Mbps.
Local: 192.168.100.152
Remote: 192.168.100.151
La computadora local ejecuta Windows 8.1 Pro, y la tengo conectada remotamente a la otra computadora que ejecuta Windows Vista Ultimate.
Resultados de Iperf
Usé Iperf para hacer algunas pruebas. Ejecuté la prueba durante 60 segundos cada vez. Ejecuté la prueba 10 veces para cada dirección de comunicación. Luego reuní esta tabla con los resultados de las pruebas para obtener un promedio.
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)
Mi pregunta es, ¿por qué es mucho más lento en la otra dirección?
Administrador de tareas de Windows
Este es el diagrama de red como se ve al realizar las pruebas en Iperf.
¡Presta atención al diagrama en las siguientes dos capturas de pantalla!
¿Notó cómo cambió de "1 Gbps" a "500 Mbps" en la esquina superior derecha cuando cambié de enviar datos a recibir datos. ¿Porque hizo eso? ¿De alguna manera percibe el otro puerto de red como la mitad de 1 Gbps cuando va en una dirección, pero está lleno cuando va en la otra dirección?
Prueba de transferencia de archivos
Hice algunas pruebas más con un archivo de datos, para obtener lecturas más realistas de disco a disco. Creé un archivo de 1 GB para este propósito. Solo utilicé recursos predeterminados para compartir archivos de Windows. Desde la computadora local, me conecté al recurso compartido C $ en la computadora remota y arrastré y solté el archivo de un lado a otro (saltar la cuerda) entre ellos, cambiando el nombre del archivo cada vez. Calculé todo lo mejor que pude y esto es lo que obtuve.
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
El rendimiento indicado por el diagrama de copia de archivos de Windows cuenta una historia diferente. Aquí estoy descargando dos archivos, uno tras otro a dos ubicaciones diferentes en el mismo disco. La primera copia indicó 107 MB / s sostenida hasta el 41%, y la segunda indicó 98.9 MB / s sostenida hasta el 87%.
Entonces esto está en línea con los resultados que obtuve con la herramienta Iperf. Ahora, así es como se ve cuando subo a la computadora remota.
Mantiene 103 MB / s hasta el 73%, y luego se reduce a maloliente 27.3 MB / s al 82% y luego sube un nivel para alcanzar 49.1 MB / s al 93%.
Aquí hay dos diagramas más divertidos de "montaña rusa".
Actualización 1 - Velocidad de enlace
Intenté deshabilitar el adaptador Wifi en la computadora remota. (El adaptador Wifi ya estaba desactivado en la computadora local). Creo que esto es lo que Timtech quiso decir con ese comentario. Pensé lo mismo: tener los adaptadores inalámbricos y cableados habilitados al mismo tiempo limitaba el rendimiento del adaptador con cable al nivel del adaptador Wifi (adaptándose al adaptador más lento por compatibilidad). Debido a que el adaptador Wifi (DWA-160 Wireless N en este caso) generalmente es detectado como un enlace "52 Mbps" - "104 Mbps" por la computadora Vista.
En la siguiente captura de pantalla, la computadora remota se configura como un servidor y la computadora local se configura como un cliente (192.168.100.152 <- 192.168.100.151).
Pero desconectar el adaptador Wifi en la computadora remota no ayudó a mi bajo rendimiento en mi conexión por cable.
¡No solo eso! En el Administrador de tareas de Windows en la computadora remota, la velocidad de enlace para el adaptador con cable (LAN 1) aparece como "1 Gbps". Si hace referencia a las capturas de pantalla anteriores, puede ver que se detecta como un enlace de "500 Gbps" en la computadora local. Entonces, para la misma conexión por cable, Windows Vista dice que es un enlace de 1 Gbps, mientras que al mismo tiempo, Windows 8.1 Pro dice que es un enlace de 500 Gbps ... ¿cuál es el correcto?
Así es como se ve en la computadora remota cuando lo configuro como cliente y la computadora local como servidor (192.168.100.152 -> 192.168.100.151).
Como puede ver aquí, se está utilizando aproximadamente el 95% del enlace de 1 Gbps. Eso se traduce a 950 Mbps. Es exactamente lo que obtuve en la prueba anterior. Pero ir al revés es una historia completamente diferente.
Actualización 2 - Duplexing y MDI-X
Según lo sugerido por algunos de ustedes, eché un vistazo a la configuración dúplex. Tanto la computadora local como la remota se configuraron en modo de negociación automática, como puede ver en las capturas de pantalla a continuación.
Traté de cambiar a "1.0 Gbps Full duplex" en ambas computadoras. Luego hice el mismo tipo de pruebas que antes, usando Iperf. Con la computadora local como servidor y la computadora remota como cliente, obtengo alrededor de 950 Mbps máx. Con la computadora local como cliente y la computadora remota como servidor obtengo alrededor de 360 Mbps.
Aquí, eche un vistazo a estas capturas de pantalla.
Lo que ves aquí es el diagrama para cuando subo y descargo entre las dos computadoras. El gráfico más alto (95 - 98% de utilización) es local a remoto (ascendente 192.168.100.152 -> 192.168.100.151). El gráfico inferior (~ 33% de utilización) es remoto a local (aguas abajo 192.168.100.152 <- 192.168.100.151).
Para tratar de descartar cualquier problema de Auto MDI-X, tenía uno de esos adaptadores cruzados conectados a un extremo del cable (la computadora local).
Eso ciertamente haría del cable un cable cruzado. Demonios, ¡incluso lo probé con un probador de red! ¡De hecho está cruzado ahora (pines 1/3, 2/6)!
Así que ahora tengo una verdadera conexión de cable cruzado entre las dos computadoras y configuré manualmente "dúplex completo de 1.0 Gbps". Sin embargo, todavía tengo el mismo problema. ¿Alguna idea más? ¿Además de actualizar la computadora Vista (o reinstalar la computadora 8.1)?
Actualización 3: ¿limitación de software o hardware?
Mi mejor conjetura es que tengo dos sistemas operativos que no son compatibles entre sí. Ambos son sistemas Windows, pero no todos los sistemas Windows son iguales. Tendré que intentar usar Vista en ambos, o 8.1 Pro en ambos y ver qué tipo de rendimiento obtengo. Eso significa comprar una actualización. Maldita sea Microsoft.
Ambas computadoras están hechas a medida por cierto. Aquí hay algunas especificaciones.
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 sugirió que la máquina Vista podría estar usando un chip Realtek defectuoso. Así que desenterré estas especificaciones. Ahora veo que la máquina Vista usa una revisión B de 8111 mientras que la máquina local usa una revisión C del mismo chip. ¿Esto significa algo? Ambos están claramente especificados por 1000 Mbit (ver arriba) por el fabricante. ¿Podría ser que el 8111B tenga un rendimiento inferior (360 Mbps)?
Estas unidades particulares alcanzan una velocidad de ráfaga de 107 MB / s. Ese es exactamente el número que he visto en la prueba en la computadora local. Pero incluso la lectura / escritura sostenida o aleatoria de quizás 55 MB / s NO se traduce a 360 Mbps. Eso debería darme alrededor de 440 Mbps, y no los 360 Mbps que estoy obteniendo. Por lo tanto, no sospecho que sea el cuello de botella, especialmente porque ambos usan el mismo modelo de unidad. Y además, la operación de copia de archivos es una cosa, pero Iperf no usa discos en absoluto, solo usa memoria RAM para las pruebas.
Actualización 4 - Descarga de suma de verificación TCP
Según lo sugerido por Tonny, intenté desactivar la descarga de suma de comprobación TCP (para IPv4 e IPv6).
También cambié "Velocidad y dúplex" a automático para ambas computadoras. Pero esto no ayudó. Todavía tengo el bajo rendimiento en una dirección y el alto en la otra dirección.
Actualización 5 - Nueva versión del controlador
Intenté actualizar la versión del controlador tanto local como remota a la última versión descargada del sitio web de Gigabyte y 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)
Todavía obtuve el mismo rendimiento pésimo en una dirección.
Actualización 6 - Utilización de CPU
Verifiqué la utilización de la CPU. Esto no debería ser un problema. Aquí están mis hallazgos.
On local...
Download: 4 - 10 %
Upload: 4 - 10 %
Idle: 0 - 4 %
On remote...
Download: 24 - 38 %
Upload: 10 - 25 %
Idle: 1 - 6 %
Local (descargar, cargar, inactivo) ...
Remoto (descargar, cargar, inactivo) ...
El control remoto usa mucha más potencia de CPU, pero este también es el que tiene el Core 2 Duo más lento. Pero nunca superó el 38% durante mis pruebas. Lo que es particularmente interesante aquí es que usa mucha más potencia de CPU al descargar (local -> remoto) que al cargar (local <- remoto).
Entonces, con un rendimiento de 950 Mbps, usa el 38% y a 360 Mbps usa el 25%. Además, la utilización del núcleo no está equilibrada, utiliza un núcleo más que el otro. No estoy seguro de qué conclusión sacar de esto. La computadora local no muestra la utilización del núcleo, por lo que no puedo compararla. Pero la utilización de la CPU es incluso en la computadora local (10% en descarga / carga).
Actualización 7 - Nuevo adaptador de red Intel Gigabit
Ahora he instalado un nuevo adaptador de red PCI-Express Gigabit de Intel como reemplazo del Realtek RTL8111B incorporado en la computadora remota, que supuestamente es demasiado lenta en la carga. El número de producto del adaptador Intel es EXPI9301CT. Se supone que este adaptador es muy bueno según las críticas que he leído. Solo quiero descartar esto como un posible cuello de botella.
He realizado algunas pruebas ahora con Iperf para Windows y aquí están los resultados.
Local (descargar, cargar) ...
Remoto (descargar, cargar) ...
En promedio, este adaptador es en realidad un poco más lento que el adaptador Realtek. Creo que tiene una sobrecarga menor que el Realtek y, como resultado, un rendimiento continuo más estable. Pero todavía obtengo solo alrededor de 360 Mbps en una dirección y 950 Mbps en la otra, incluso con 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
No tengo idea de por qué alcanzó un máximo de 113 MB / s en la primera prueba, local a remota. Mantuvo esa velocidad durante la ejecución de la prueba, el gráfico fue casi plano a 113 MB / s. Como antes, usé un intervalo de 60 segundos para cada carrera. En la próxima ejecución, sin embargo, cayó a 104 MB / s.
Como puede ver por estos valores, todavía tengo el mismo rendimiento con este adaptador Intel que con el adaptador Realtek incorporado. Así que creo que es seguro decir que no tiene nada que ver con el adaptador en sí. Por lo tanto, podemos dejar de culpar al RTL8111B por ser un chip inferior / menor que el RTL8111C que se encuentra en la otra placa base. Esto se parece cada vez más a un problema de software / sistema operativo / configuración, o las tres cosas a la vez.
Actualización 8 - Grandes resultados con Ubuntu LINUX
Después de agotar todas las demás opciones, finalmente decidí ejecutar algunas pruebas con Linux, y obtuve excelentes resultados. Utilicé un sistema Ubuntu Linux 13.10 Live e Iperf para Linux (versión 2.0.5-3) en máquinas locales y remotas. Aquí están los 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 (descargar, cargar, inactivo) ...
Como puede ver, obtengo el mismo rendimiento en ambas direcciones cuando uso Ubuntu. ¿Es porque uso el mismo sistema operativo en ambas máquinas o es algo más? ¿Obtendría el mismo rendimiento si tuviera las mismas versiones de Windows configuradas en ambas máquinas? No entiendo por qué sería importante si uso una versión de Windows ligeramente desactualizada, a saber, Vista, en una máquina y la última versión en la otra. . Windows XP es una historia diferente.
Pero sé que están haciendo todo lo posible para matar a Vista. Por ejemplo, el último Office 2013 no es intencionalmente compatible con Windows Vista. Estoy seguro de que Microsoft desea que Vista nunca haya sucedido. Al igual que desearían que Windows 8.0 nunca hubiera sucedido. Pero generalmente soy tan persistente como ellos, y no actualizo mis instalaciones de Windows hasta que sea absolutamente necesario.
Entonces, la pregunta es cómo obtener el mismo rendimiento en ambas direcciones con dos versiones diferentes de Windows. Windows Vista debería ser capaz de tener velocidad Gigabit: no es un sistema operativo de 20 años o algo así, no estamos hablando de Windows 95. Vista es un sistema operativo moderno. Todavía no he probado ejecutar la misma versión de Windows en ambas máquinas. Puede haber una diferencia en la implementación de TCP o algo entre las dos versiones del sistema operativo. Si es así, entonces probablemente me veré obligado a actualizar la máquina Vista. O eso o cambiar a Linux. No estoy preparado para pagar más por menos. ¿Por qué tendría que actualizar Windows solo para obtener el rendimiento de Gigabit en ambas direcciones? ...
Actualización 9 ...
Cable
Traté de invertir el cable. Obtuve los mismos resultados que antes. También obtuve un nuevo cable de conexión Cat 6 y probé ese. Los resultados de la prueba de rendimiento fueron los mismos. Entonces el cable no es el problema aquí. Solo utilicé cables de conexión preterminados / moldeados. Entonces el cableado debe ser correcto. Pero planeo terminar mis propios cables de instalación más adelante.
FW y AV
En cuanto a firewall (FW) y antivirus (AV), no utilizo ningún software de FW o AV de terceros. Solo tengo Windows Firewall y Security Essentials. Los he desactivado en ambas máquinas. Los resultados de la prueba de rendimiento fueron los mismos que antes.
Prueba de velocidad LAN
He instalado LAN Speed Test Lite 1.3 en la máquina local. Creo que la prueba se realiza entre la memoria local y la unidad de disco en la máquina remota. No estoy seguro. Pero solicita una ruta compartida en la máquina remota. Usé o $ share en el control remoto.
Upload: 427 Mbps
Download: 420 Mbps
No confío demasiado en estos resultados. Si observa el gráfico, puede ver que varía mucho a lo largo de la prueba. La prueba fue una prueba "sucesiva", es decir: primero escriba (cargue) y luego lea (descargue) la prueba. Obviamente, si realiza una prueba de carga / descarga simultánea, el rendimiento general será menor. Pero no estoy interesado en tales pruebas. Hasta ahora solo he estado haciendo pruebas "sucesivas" con ambas pruebas de transferencia de archivos en Windows (compartir archivos / smb) y en Iperf.
No he realizado ninguna prueba de memoria a memoria con LAN Speed Test porque requiere el uso de un programa llamado Servidor LST en el control remoto, y este programa requiere registro para poder usarlo.
Actualización 10 ...
Pruebas de unidad de disco
Usé Crystal Disk Mark 3.0.3 para probar las unidades de disco. Aquí están los resultados.
Local disk: 118 MB/s read, 113 MB/s write
Remote disk: 70 MB/s read, 69 MB/s write
Estas son velocidades de lectura y escritura secuenciales basadas en 5 ejecuciones y una carga de 1000 MB.
Este es el disco local (marca de disco, lectura, escritura) ...
Y este es el disco remoto ...
Pero no entiendo esto ... estos resultados parecen contradictorios.
Okey, el disco local puede leer a 118 MB / s, por lo que permitiría la carga informada de aproximadamente 100 MB / s. Pero el disco remoto no podría recibirlo si solo es capaz de grabar 69 MB / s. Pero por algún giro mágico, sigo recibiendo poco más de 100 MB / s de carga en promedio.
Ir al revés tiene más sentido. Si el disco remoto puede leer a 70 MB / s, y el disco local puede escribir a 113 MB / s, entonces la descarga no debería ser más rápida que 70 MB / s. Obtengo aproximadamente 40 MB / s de descarga en promedio. Eso parecería razonable.
Entonces no puedo concluir nada de estos resultados. Me refiero a que la unidad de disco de la computadora local apenas se usa. También es el disco que contiene el sistema operativo, y es la única partición en ese sistema. Mientras que el disco remoto está casi lleno, y también está particionado con varias particiones. Sin embargo, no se utiliza para el sistema operativo. Elegí la letra de unidad O:para la prueba aquí, porque esta es la partición con más espacio libre.
(Tenga en cuenta que usé la letra de unidad C:en las pruebas anteriores que está en una unidad de disco Seagate completamente separada que contiene el sistema operativo en la máquina remota. Por lo tanto, esas lecturas no son comparables).
Escribir en caché
Con el almacenamiento en caché de escritura en disco habilitado obtuve estos resultados.
Local to remote: 106 MB/s
Remote to local: 42.2 MB/s
Luego deshabilité el almacenamiento en caché de escritura en todas las unidades en el control remoto y en la unidad local.
No reinicié porque no se solicitó reiniciar para que los cambios surtan efecto. Luego obtuve los siguientes resultados.
Local to remote: 106 MB/s
Remote to local: 42.1 MB/s
Prácticamente no hubo ningún cambio en absoluto. No reiniciar, y no se solicitó reinicio.
Paquete QOS
Luego pasé a desactivar QOS Packet Scheduler para el adaptador apropiado en la máquina remota, y luego en la máquina local.
Local to remote: 107 MB/s
Remote to local: 41.9 MB/s
No hay cambios significativos aquí. Nuevamente, no se solicitó reiniciar ni reiniciar.
Paquetes jumbo
Luego pasé a habilitar paquetes jumbo. Usé la configuración de 4 GB porque 4 KB es el tamaño de MTU más grande que es compatible con ambas máquinas.
Local to remote: 105 MB/s
Remote to local: 33.3 MB/s
Ahora aquí, la carga (local a remota) no se vio afectada, pero el rendimiento de descarga se redujo significativamente. No se solicitó reiniciar, pero decidí reiniciar ambas máquinas de todos modos, solo por si acaso. Luego realicé las mismas pruebas nuevamente y obtuve estos resultados.
Local to remote: 117 MB/s
Remote to local: 33.2 MB/s
Por lo tanto, la carga ahora es aún más rápida, pero la descarga aún es más lenta de lo que era antes de realizar estos cambios, incluso después del reinicio. Hubiera esperado que ambos subieran un poco. ¿Qué significa esto?
Respuestas:
Según su respuesta:
El tamaño de la ventana TCP representa la cantidad máxima de datos que la pila TCP arrojará por la persiana antes de detenerse y esperar recibir acuses de recibo de la máquina remota; en otras palabras, la cantidad máxima de tráfico no reconocido en el cable. El hecho de que la ventana TCP en la máquina Vista sea mucho más pequeña que en la máquina Se7en de Windows respalda la teoría de que no está llenando la tubería lo suficiente antes de detenerse y esperar ACK.
Por lo tanto, lo primero que intentaría es aumentar el tamaño de la ventana TCP en la máquina Vista usando el
-wargumento. 0.01MB es una unidad algo inútil; Supongo que son 16KiB. Entonces comience con 16KiB y ejecute una prueba:Duplique el tamaño de la ventana y repita la prueba:
Con suerte, deberías observar un aumento de velocidad. Continúe duplicando el tamaño de la ventana hasta que ya no vea aumentos significativos de velocidad.
fuente
Como se indicó anteriormente, deberá modificar el tamaño de la ventana TCP en iperf para obtener un mayor rendimiento en enlaces de baja latencia y alta velocidad. Las diferentes versiones de Windows (o iPerf) pueden tener diferentes tamaños de ventana predeterminados. Pruebe "-w 256k" para comenzar tanto en el cliente como en el servidor.
¿Puedes confirmar la dirección de la flecha de tus gráficos? En iperf, los datos se empuja desde el cliente al servidor (lo contrario de lo que por lo general).
Puede descartar los discos duros como la causa, ya que iPerf no toca los discos duros.
Creo que ya has verificado que estás ejecutando los últimos controladores NIC. No debería haber necesidad de perder el tiempo configurando manualmente la velocidad / dúplex. Lo mismo ocurre con los marcos jumbo: no valen la pena con el hardware moderno.
Verifique que la descarga de envío grande (LSO) y la descarga de recepción grande (LRO) estén habilitadas en ambas NIC. Algunos controladores NIC usan diferentes nombres (o múltiples opciones que controlan este comportamiento), por lo que es posible que tenga que buscar. Por lo general, el valor predeterminado es tenerlos todos habilitados.
fuente
Creo que necesitas leer un poco más sobre cómo funciona iperf. Si no configura el tamaño de ventana tcp correcto, sus resultados variarán mucho. Creo que es el interruptor -w. Este sitio web ayudará a calcular el tamaño óptimo de la ventana TCP. Necesita saber el RTT y el ancho de banda para calcularlo. http://www.kehlet.cx/docs/tcpwin.php
Pruebe también otras herramientas como "Prueba de velocidad de LAN" lite, que solo hará transferencias ascendentes y descendentes entre las acciones en cada extremo. Sus resultados son bastante cercanos en las pruebas que he realizado con él. También asegúrese de verificar cuáles son las velocidades máximas de r / w de sus discos duros.
fuente
Un par de puntos que pueden ayudarlo ... La pila TCP IP ahora se implementa de manera diferente en las versiones posteriores de Windows 7. Observaría detenidamente mis optimizaciones de TCP, puede que no haya mucho entre sus dos cuadros, pero aún así vale la pena ajustar algunas configuraciones en su Vista Box.
Se ha depreciado el uso de netsh int tcp set global congestionprovider = ctcp . Para establecer o cambiar el proveedor de congestión se debe utilizar el siguiente comando:
lea el artículo aquí: http://forums.speedguide.net/showthread.php?280646-When-will-TCP-Optimizer-support-Windows-8-amp-Windows-Server-2012
netsh int tcp set suplementario personalizado 300 10 ctcp desactivado 50 Luego escriba: netsh int tcp set suplementario personalizado
Para obtener más detalles sobre el comando anterior, simplemente escriba: netsh int set Supplemental
Para verificar qué proveedor de congestión está usando actualmente, use lo siguiente: netsh int tcp show suplemental
Pero solo Win Server 2012 puede crear plantillas personalizadas. CTCP puede ser un problema.
También Auto-Scaling podría ser un factor.
Tal vez valga la pena echar un vistazo a sus controladores tal vez necesiten una actualización / degradación. ver cuáles funcionan mejor.
Otra idea son los tamaños de paquetes que se escriben en HDD. ¿De qué tamaño son los sectores de su HDD formateados a 512b ~ 64K? Podría ser un cuello de botella en caché. Vale la pena considerarlo al usar velocidades de GBit, ¡o pruebe con un disco SSD!
¿Ha considerado habilitar Jumbo Packets (si esto se aplica a sus NIC)
fuente
Esto suena bastante familiar ... obtienes un
iperfrendimiento inexplicablemente malo en Windows, pero el mismo hardware funciona bien con Linux.Después de pelear esta batalla una y otra vez, he llegado a la conclusión de que
iperfen Windows es escamoso . No sé por qué ... sinceramente, dejé de preocuparme porque sé que siempre puedo obtener resultados sanos de Linux.Entonces, si desea saber por qué está obteniendo un rendimiento tan malo, no busque más allá de la aplicación.
fuente
Algo para intentar es detener el servicio MMCSS. Sí, perderá su audio temporalmente, pero podría ser que algo lo esté activando, causando que la actividad de la red se acelere para que la actividad de la red no ahogue otra actividad.
Consulte aquí para obtener información sobre MMCSS y la limitación de la red: http://blogs.technet.com/b/markrussinovich/archive/2007/08/27/1833290.aspx
Se puede modificar según estas instrucciones: http://support.microsoft.com/kb/948066
Dudo que sea la causa en este caso, ya que el rendimiento probablemente sería menor, pero después de golpearme la cabeza contra la pared durante mucho tiempo con mis propios problemas de rendimiento en Vista, descubrí que esta era la causa. Configuré NetworkThrottlingIndex en 70 y finalmente obtuve el rendimiento que esperaba.
fuente
Una cosa que no ha intentado es eliminar la compresión diferencial remota en Vista.
Mi pensamiento está motivado por el uso extensivo de la CPU en Vista. Es posible que el controlador de red de Vista no sepa cómo descargar esto a la tarjeta de red, mientras que Windows 8 lo hace de manera mucho más eficiente.
Para obtener detalles completos, consulte el artículo:
Evite la copia lenta de archivos a través de la red en Vista deshabilitando la Compresión diferencial remota .
En pocas palabras, simplemente desmarque
Remote Differential CompressionPanel de control -> Programas y características -> Active y desactive las características de Windows, luego reinicie.fuente
Anteriormente persigo mi cola con exactamente el mismo problema durante un tiempo! Velocidades de transferencia lentas en una dirección, en mi caso saliente (enlace ascendente).
Windows 7 Pro, Celeron J1800 con tarjeta LAN incorporada Realtek Gigabit 8111C. QNAP 453a y MacBook Pro en el otro extremo.
Cuando se midió a través de Iperf3, obtenía 112 mbps con mi Windows 7 configurado como cliente (uso de CPU en 25-30%). Y solo 39-41 Mbps cuando se configura como servidor, con un uso intensivo de la CPU entre 50-100%. Tan malo que la PC se congelaría en momentos de pruebas de ancho de banda.
La transferencia de archivos normal está limitada a 45 mbps como máximo, sin importar si estaba cargando o descargando archivos a mi NAS o MAC.
No recibía más de 35-45 megabytes por segundo. Bastante frustrante!
Terminó siendo un mal conductor de la tarjeta LAN. Estaba obsesionado con actualizar los controladores y siempre actualizaba mis controladores cuando hay uno nuevo disponible. Adivina qué, después de varias actualizaciones, mi tarjeta LAN se ralentizó.
Algunos de ustedes podrían decir, simplemente elimine el controlador anterior e instale el nuevo. Simple, ah? Lo intenté y lo intenté, no funcionó para mí.
Aquí está mi solución:
Windows instalado desde cero con controladores OEM desde el sitio web del fabricante. También hice lo siguiente:
En Administrador de dispositivos / Tarjeta LAN / Configuración avanzada / Desactivar todo excepto CONTROL DE FLUJO.
En Características de Windows, deshabilite la compresión diferencial remota.
Ahora la velocidad promedio está entre 80-100 Mbps.
Perdón por las fotos de mala calidad.
fuente
Linus de Linus Tech Tips en Youtube tuvo el mismo problema, y pido disculpas, pero he olvidado cuál era la solución. Es un video reciente (a partir del 20/04/2016), y puedo estar equivocado, pero creo que terminó siendo un caso en el que un solo subproceso en un procesador es el factor limitante, por lo que si tiene hardware antiguo y está tratando de alcanzar 1 Gbps, en realidad es la CPU el problema, si descarga la mayor parte del trabajo a la CPU, lo que hacen la mayoría de las NIC integradas en estos días. Podría estar equivocado, es un video reciente suyo, le recomiendo que revise su transmisión. Por lo que vale, me encuentro con el mismo problema en mi conexión de internet gigabit.
fuente