Velocidades de red gigabit lentas e inexplicables

18

Actualizar

Ok, he probado las respuestas a continuación y nada ha cambiado. Identifiqué el chipset de la computadora portátil como NVIDIA nForce 520. Descargué los últimos controladores Vista x64 para nForce 520 (NVIDIA todavía no tiene controladores para ese chipset para Win 7). Intenté instalar el software de firewall incluido (pensando que tal vez está interfiriendo, no lo está). Desinstalé completamente mi software antivirus (¡estoy usando Avast!) Pensando que su controlador de filtro de red puede estar causando un problema, que tampoco ha ayudado.

Llevé mi computadora portátil a la casa de mis hermanos y pude copiar archivos a 10-12 MB / s en su red de 100Mbit, así que no creo que sea el hardware.

He ejecutado iperf con algunos resultados sorprendentes:
iperf desde la computadora portátil que envía al servidor (carga)

> 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 desde el servidor que envía a la computadora portátil (descarga)

> 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

A modo de comparación, aquí están los números iperf entre el HTPC y el 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

El uso de wireshark para ver una transferencia desde el servidor a la computadora portátil genera muchas de las siguientes 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

En este punto, estoy totalmente perdido en cuanto a qué probar a continuación.

Pregunta original

Antecedentes

Actualmente estoy experimentando un problema en mi laptop con Windows 7 recién instalada. El problema ocurrió originalmente después de instalar Windows 7 RC. Cuando Windows Vista y Windows 7 Beta 1 se instalaron en esta computadora portátil, pude transferir a velocidades de gigabit con marcos Jumbo activados en el rango de 9 KB / 9014. Los dos interruptores entre la computadora portátil también admiten marcos Jumbo.

Al copiar archivos de mi servidor a mi computadora portátil, se ejecutan a un ritmo reducido (generalmente menos de 1 MB / seg), mientras que otros dispositivos que pasan por los mismos interruptores pueden transferir a velocidades más altas (45 - 55 MB / seg). Parece que copiar de la computadora portátil al servidor genera una velocidad más rápida, pero nada de eso debería ser.

Máquinas involucradas

  • Miyuki: Laptop con el problema. Windows 7 x64 RTM. HP Pavilion dv9700 CTO. Utiliza un adaptador Ethernet NVIDIA nForce 10/100/1000 Mbps. (El video es GeForce 8400M GS)
  • Naru: Servidor con archivos. Windows Server 2008 R2 x64 SP2 personalizado. Utiliza un adaptador D-Link DGE-560T PCI Express Gigabit.
  • CC: HTPC en el mismo conmutador sin problema. Windows Vista x86 SP2. Utiliza un adaptador Realtek RTL8168B / 8111B PCI-E GBE integrado.

Cuando se tomaron estas imágenes, todos los cuadros gigantes se desactivaron.

Las imagenes

Copia iniciada desde la computadora portátil

Servidor -> Computadora portátil (fuente: gibixonline.com ) Computadora portátil -> Servidor



Copia iniciada desde el servidor

Servidor -> Computadora portátil (fuente: gibixonline.com ) Hacer que el servidor copie inesperadamente un archivo de la computadora portátil a sí mismo da como resultado velocidades que yo esperaría. (Laptop -> Server) (fuente: gibixonline.com )




Dije anteriormente que la otra máquina en el mismo interruptor no tiene este problema. Alto DPI está activado ya que esto se muestra en un HDTV.
Servidor -> HTPC (fuente: gibixonline.com )

Naturalmente, como prueba, decidí ver cuáles eran las velocidades entre mi computadora portátil y el HTPC. Lamentablemente fueron exactamente lo que esperaba.
HTPC -> Laptop (fuente: gibixonline.com )

Notas finales

He intentado todo lo que puedo pensar. Incluso los cuadros gigantes están desactivados en este punto y nada parece afectarlo. Intenté desactivar mi protección antivirus para cambiar los cables que uso. Actualmente todos los cables en uso son CAT-5e que he construido. Traté de tomar el cable del HTPC y lo enchufé a mi computadora portátil para ver si el cableado era un problema. Los dos interruptores en cuestión son un D-Link DGS-1216T y un interruptor "tonto" que admite tramas gigantes, el D-Link DGS-2208.

windows-server-2008 windows-7 slow-connection gigabit Joshua
fuente
1
¿probaste una herramienta como iperf (google for iperf win32) para medir el ancho de banda disponible? si iperf ofrece velocidades razonables, tal vez su nueva invención drm: /. Lo dudo, pero vale la pena verificarlo; de lo contrario, verifique dos veces si no hay una falta de coincidencia dúplex.
pQd
¿Has probado algo como pscp en un servidor cercano para ver qué velocidad obtienes con eso?
chris
1
¿Has intentado cruzar el servidor y la computadora portátil para que no haya ningún cambio entre ellos?
Joseph
Amén a lo que dijo José. Intenta eliminar el cambio de la ecuación.
Jeremy Visser

Respuestas:

5

Intente deshabilitar la función de autoajuste de Windows.

En una ventana CMD:

netsh interface tcp set global autotuning=disabled

Vuelva a ejecutar su prueba y vea si nota una mejora en el rendimiento. Tuve que hacer esto en un par de computadoras portátiles con Windows 7 en mi casa, y me ayudó.

Si las cosas empeoran o no nota ninguna mejora, puede volver a habilitar el autoajuste de la siguiente manera:

netsh interface tcp set global autotuning=normal
Tim Kennedy
fuente
3

Esto parece ser un gran problema con Windows 7. Varios jugadores se han quejado de este problema.

  1. Desde un símbolo del sistema (generalmente en Todos los programas -> Accesorios -> Símbolo del sistema) ejecute "regedit"
  2. Vaya a HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services \ Tcpip \ Parameters \ Interfaces
  3. Examine los elementos en las interfaces hasta que encuentre uno que tenga una entrada de IPAddress que coincida con la interfaz de red que desea afectar (generalmente las direcciones IP de LAN comienzan con 192.168 o 10.0); tenga en cuenta que si un servidor DHCP asigna automáticamente su dirección IP, es posible que deba buscar una DhcpIPAddress coincidente en lugar de una dirección IP
  4. Haga clic derecho en la interfaz y seleccione Nuevo> Valor DWORD (32 bits), asígnele el nombre "TcpAckFrequency"
  5. Haga clic con el botón derecho en el nuevo valor TcpAckFrequency y seleccione Modificar, ingrese “1 ″ (se debe seleccionar el botón de radio hexadecimal)
  6. Haga clic con el botón derecho en la interfaz y seleccione Nuevo> Valor DWORD (32 bits), asígnele el nombre "TCPNoDelay" (tenga en cuenta que TCP esta en mayúscula esta vez, eso es intencional)
  7. Haga clic con el botón derecho en el nuevo valor TCPNoDelay y seleccione Modificar, ingrese "1" (se debe seleccionar el botón de radio hexadecimal)
  8. Verifique que tanto TcpAckFrequency y TCPNoDelay ahora aparezcan en la lista de propiedades del adaptador con los tipos REG_DWORD y valores 0 × 00000001
  9. Salga de regedit y reinicie (¡es necesario reiniciar para que los cambios surtan efecto!)
    1. Juega un juego y disfruta de tu nuevo ping bajo

Esto disminuyó mi ping en la mayoría de los juegos de 200-300ms a 50-60ms, lo que coincide con la latencia que vería a través de un tracert al servidor del juego.

Tomado de reducir la latencia de red del juego en Windows 7 o Vista

JJ01
fuente
1
Tracert utiliza ICMP, no TCP. Estas claves son para TCP, por lo que no cambian nada para ICMP. No sé por qué viste un mejor tiempo de respuesta a través de tracert
Mathieu Chateau
Bueno, seguí adelante y probé esto y todavía parece ser lo mismo. Estoy actualizando la pregunta original con más información y cosas que he probado.
Joshua el
2
Matthieu, no dijo que vio mejor tiempo de un concierto. Dijo que la latencia en el juego se convierte en equivalente a un tracert, lo que significa que la latencia observada en el tráfico TCP es similar a la del tráfico ICMP, que funcionaba normalmente.
MDMarra
3

Para verificar si la computadora portátil no tiene la culpa, ejecute un ubuntu live cd, instale iperf en el disco RAM y ejecute una prueba.

Esto debería al menos probar el lado de la red.

Mate
fuente
1

Verifique si hay paquetes descartados. No estoy seguro de cómo hacer esto en Windows, pero si tiene una máquina Linux, puede verificar allí.

Tuve una experiencia similar con un conmutador gigabit en el que el modo gigabit estaba roto y dejaba caer paquetes. Solo vi problemas cuando tenía 2 máquinas conectadas en este modo. En el modo 100K, todo estaba bien. Fue un problema desagradable que me llevó unos días descubrir. Podría haber sido un D-Link. Busca en Google tu modelo de interruptor. Lo hice y descubrí que otros tenían el mismo problema que yo.


fuente
1

Me he encontrado con esto antes con otros productos AV. Mi problema era con SMB y el producto AV interfería incluso cuando estaba "deshabilitado". Mostró resultados similares en wireshark que tienes. Este es uno de los muchos sitios que verifiqué para llegar a la causa raíz: problema de Symantec SMB y otro: SMB2 falla con NTP

Además, puede intentar deshabilitar / cambiar todas o algunas de las configuraciones dentro de SMB. Incluso consideraría deshabilitar v2 en el sistema operativo. Consulte este artículo que describe un problema de SMB en Win Vista y este enlace a Microsoft describe algunos datos técnicos sobre la configuración de registro de SMB .

Sé que mencionaste a Avast, pero es una coincidencia que vi resultados similares de wirehark. Tenga en cuenta que todo, excepto la transferencia de archivos, pareció funcionar bien en mi caso.

Ben Campbell
fuente
1

He tenido problemas con los clientes que se comunican con los servidores de Windows al usar la firma de paquetes. No experimenté lentitud, sino interrupciones de conexión bastante comunes.

Lea aquí para la solución que solucionó mi problema.

Tampoco veo ninguna sugerencia aquí para desactivar las funciones de TCP Chimney una por una para ver si una de ellas ha salido mal.

Dom
fuente
También me ha quemado esto ...
Ben Campbell
1

Parece que el sistema operativo está comprobando los paquetes antes de escribir en el disco. Observé que todas las transferencias lentas son las que intentan escribir en la computadora portátil ... Sugiero

  • comprobar el tamaño de los bloques de las particiones en los discos duros de las computadoras portátiles (los tamaños de bloques pequeños pueden causar un mal tiempo de búsqueda de espacio libre al intentar transferir un solo archivo grande (más o menos))
  • verificar cualquier política de firewall que verifique la escritura en disco de los paquetes entrantes
  • verificar cualquier monitor de actividad de archivos (esto debería ser motivo de preocupación debido a que desinstala el antivirus) (ya que sabe avast hacer verificaciones de archivos en vivo y eso ralentiza un poco la transferencia de red ...)
  • Desfragmentar la partición de destino (nuevamente sobre la búsqueda de espacio libre)

Otros se sugieren y no parecen estar ayudando:

  • autoajuste
  • nivel dúplex
  • cables ...

Una última sugerencia es: ¿puede verificar la detección del enlace del modo batería en las propiedades avanzadas de nic? Es una computadora portátil y podría haber algunos problemas con las propiedades de ahorro de energía ... Pruebe "Sin ahorro de energía" en la detección de enlace del modo batería y "Completo" en la configuración de velocidad de la batería.

Estoy usando win7 en una PC de escritorio y esas opciones no están incluidas en las propiedades avanzadas de mi nic. Siempre y cuando nunca haya superado este problema, también puede verificar los valores de "Control de flujo" a "TX y RX habilitado" como opciones de mi nic. Jumbo está desactivado, Speed ​​y Duplex también es automático en mi configuración ...

No puedo pensar en ninguna otra solución ... Espero que esto ayude ...

El alien
fuente
1

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.

Gi Cakov
fuente
0

Por todo, supongo que ha configurado las tarjetas de red en dúplex completo, 100 MB y no en automático.

Chris
fuente
1
+1 para "no automático" :)
dimitri.p
Sí, he probado todas las variantes que admite mi tarjeta ... 10 medias, 10 completas, 100 medias, 100 completas y 1000 completas. Ninguno de ellos lo afectó de ninguna manera y, según los interruptores, negocian a 1000 lleno.
Joshua
10
Nunca haga eso si el interruptor no es manejable. Si se ve forzado a dúplex completo en un lado pero automático en el otro lado, el otro lado se convierte en semidúplex. Entonces empiezas a perder paquetes (mucho ...). El interruptor que no puede administrar es automático. Mantenga automático en su servidor y verifique que la interfaz negoció full duplex. Compruebe si hay errores de interfaz también.
Mathieu Chateau
44
-1 para "no automático". Necesita la misma configuración en ambos extremos (conmutador y NIC), incluida la negociación automática.
dunxd el
55
Tengo curiosidad, ¿ha intentado quitar el interruptor de la ecuación y conectar un cable cruzado desde el "servidor" directamente a la "computadora portátil"?
SpacemanSpiff
0

Probablemente odiarás esta respuesta, ¡pero tengo que decirlo!

¿Has intentado actualizar los controladores?

Tengo un problema similar en mi computadora portátil (NIC basada en Realtek), se transfiere a aproximadamente 3 MB / s, pero en el momento en que actualizo los controladores a los últimos de su sitio, aumenta a aproximadamente 40-50 MB / s

El hecho de que los controladores con Windows funcionen no significa que sean los mejores.

William Hilsum
fuente
Jaja, sí, eso fue lo primero que intenté. En este momento estoy de vuelta en los controladores de Windows 7 en la caja, pero también he probado los últimos nvidia. Los únicos controladores que no he probado son los de Windows 7 beta o Vista.
Joshua el
Pruebe los de Vista y vea cómo funciona. Tuve varios problemas menores que se han solucionado en las actualizaciones para Win7 ahora; Lo arreglé manualmente instalando controladores de Vista para hardware.
David Rickman el
0

Sospecharía que es algo en el camino desde el servidor a la computadora portátil, por ejemplo:

  • Cambie el puerto parcheado a la computadora portátil
  • Cableado de Ethernet o conexiones entre conmutador y computadora portátil

Según la excelente sugerencia de @ SaucemanSpiff, ¿ha intentado cablear la computadora portátil directamente al servidor utilizando un buen cable CAT5E o CAT6? No hay necesidad de un cable cruzado especial siempre que al menos una de las interfaces involucradas sea compatible con Gigabit Ethernet (lo que implica Auto MDI-X).

Skyhawk
fuente
0

  1. Has vencido a la PC hasta la muerte con actualizaciones y probado fuera del sitio sin fallas. ¿Has intentado hacer actualizaciones y tal en el servidor "naru"?

  2. La mayoría de las soluciones en este hilo sugeridas por otros podrían aplicarse al servidor, ¿las ha probado allí?

  3. ¿Qué sucede cuando pruebas usando Robocopy (con y sin jumbo)? Si es rápido en ambas direcciones, usaría netshark para ver los encabezados de sesión de SMB al comienzo de las copias en cada dirección y ver si algo se ve diferente en la configuración de naru-> miyuki.

marca
fuente
0

¿Has probado con la teracopia? He estado usando esto como un reemplazo estándar para Windows Copy durante más de un año, y ha mostrado mejoras en las velocidades de transferencia :)

Bahrain Admin
fuente
-1

Una especie de disparo en la oscuridad, pero podría ayudar.

  • Deshabilite la "Compresión diferencial remota" en el Panel de control - Programas y características - Active o desactive las características de Windows.
  • Eliminar IPv6 de las propiedades de red. ¿Utiliza IPv6 en su LAN? Si no, deshabilítelo.
  • Borrar DNS Cache con ipconfig /flushdnsen la CLI.
duenni
fuente
-1

si se debe a cambiar el sistema operativo, entonces seguramente el problema radica en el sistema operativo. debe intentar instalar el último paquete de servicio de Windows 7 y mantener Windows actualizado con las últimas actualizaciones. Y espera lo mejor

Farhan
fuente