52 votos

Windows TCP Window Scaling Llega a la meseta demasiado pronto

Escenario: Tenemos un número de clientes de Windows que regularmente suben archivos grandes (FTP/SVN/HTTP PUT/SCP) a servidores Linux que están a ~100-160ms de distancia. Tenemos un ancho de banda síncrono de 1 Gbit/s en la oficina y los servidores son instancias de AWS o están alojados físicamente en centros de distribución estadounidenses.

El informe inicial fue que las subidas a una nueva instancia del servidor eran mucho más lentas de lo que podrían ser. Esto se comprobó en las pruebas y desde múltiples ubicaciones; los clientes veían una velocidad estable de 2-5Mbit/s hacia el host desde sus sistemas Windows.

Me he escapado iperf -s en una instancia de AWS y luego desde un Windows cliente en la oficina:

iperf -c 1.2.3.4

[  5] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 55185
[  5]  0.0-10.0 sec  6.55 MBytes  5.48 Mbits/sec

iperf -w1M -c 1.2.3.4

[  4] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 55239
[  4]  0.0-18.3 sec   196 MBytes  89.6 Mbits/sec

Esta última cifra puede variar significativamente en las pruebas posteriores, (Vagabundos de AWS) pero suele estar entre 70 y 130Mbit/s lo que es más que suficiente para nuestras necesidades. Wiresharking la sesión, puedo ver:

  • iperf -c Windows SYN - Window 64kb, Scale 1 - Linux SYN, ACK: Window 14kb, Scale: 9 (*512) iperf window scaling with default 64kb Window
  • iperf -c -w1M Windows SYN - Windows 64kb, Escala 1 - Linux SYN, ACK: Window 14kb, Escala: 9 iperf window scaling with default 1MB Window

Está claro que el enlace puede sostener este alto rendimiento, pero tengo que establecer explícitamente el tamaño de la ventana para hacer algún uso de ella, lo que la mayoría de las aplicaciones del mundo real no me permiten hacer. Los handshakes TCP utilizan los mismos puntos de partida en cada caso, pero el forzado escala

Por el contrario, desde un cliente Linux en la misma red una recta, iperf -c (utilizando los 85kb por defecto del sistema) me da:

[  5] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 33263
[  5]  0.0-10.8 sec   142 MBytes   110 Mbits/sec

Sin ningún tipo de forzamiento, escala como se esperaba. Esto no puede ser algo en los saltos intermedios o nuestros switches/routers locales y parece afectar a los clientes de Windows 7 y 8 por igual. He leído un montón de guías sobre el ajuste automático, pero estos son por lo general acerca de la desactivación de la escala por completo para trabajar en torno a mal kit de red doméstica terrible.

¿Alguien puede decirme qué está pasando aquí y darme una forma de solucionarlo? (Preferiblemente algo que pueda meter en el registro a través de GPO).

Notas

La instancia de AWS Linux en cuestión tiene la siguiente configuración del kernel aplicada en sysctl.conf :

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 1048576
net.core.wmem_default = 1048576
net.ipv4.tcp_rmem = 4096 1048576 16777216
net.ipv4.tcp_wmem = 4096 1048576 16777216

He utilizado dd if=/dev/zero | nc redirigiendo a /dev/null en el extremo del servidor para descartar iperf y eliminar cualquier otro posible cuello de botella, pero los resultados son prácticamente los mismos. Las pruebas con ncftp (Cygwin, Native Windows, Linux) escalan de forma muy similar a las pruebas iperf anteriores en sus respectivas plataformas.

Editar

He visto otra cosa consistente aquí que podría ser relevante: enter image description here

Este es el primer segundo de la captura de 1MB, ampliado. Se puede ver Inicio lento en acción a medida que la ventana se amplía y el buffer se hace más grande. Hay entonces esta pequeña meseta de ~0.2s exactamente en el punto en el que la prueba iperf de la ventana por defecto se aplana para siempre. Este, por supuesto, escala a alturas mucho más vertiginosas, pero es curioso que haya esta pausa en el escalado (los valores son 1022bytes * 512 = 523264) antes de hacerlo.

Actualización - 30 de junio.

Seguimiento de las distintas respuestas:

  • Activar CTCP - Esto no supone ninguna diferencia; el escalado de la ventana es idéntico. (Si lo he entendido bien, este ajuste aumenta la velocidad a la que se amplía la ventana de congestión en lugar del tamaño máximo que puede alcanzar)
  • Habilitar las marcas de tiempo TCP. - Aquí tampoco hay cambios.
  • Algoritmo de Nagle - Eso tiene sentido y, al menos, significa que probablemente puedo ignorar ese parpadeo particular en el gráfico como cualquier indicación del problema.
  • archivos pcap: Archivo zip disponible aquí: https://www.dropbox.com/s/104qdysmk01lnf6/iperf-pcaps-10s-Win%2BLinux-2014-06-30.zip (Anonimizado con bittwiste, extrae hasta ~150MB ya que hay uno de cada cliente del SO para comparar)

Actualización 2 - 30 de junio

O, así que siguiendo la sugerencia de Kyle, he habilitado el ctcp y desactivado la descarga de la chimenea: Parámetros globales TCP

----------------------------------------------
Receive-Side Scaling State          : enabled
Chimney Offload State               : disabled
NetDMA State                        : enabled
Direct Cache Acess (DCA)            : disabled
Receive Window Auto-Tuning Level    : normal
Add-On Congestion Control Provider  : ctcp
ECN Capability                      : disabled
RFC 1323 Timestamps                 : enabled
Initial RTO                         : 3000
Non Sack Rtt Resiliency             : disabled

Pero, lamentablemente, no hay cambios en el rendimiento.

Sin embargo, tengo una pregunta de causa/efecto: Los gráficos son del valor RWIN establecido en los ACKs del servidor al cliente. Con los clientes de Windows, ¿estoy en lo cierto al pensar que Linux no está escalando este valor más allá de ese punto bajo porque el CWIN limitado del cliente impide que se llene incluso ese buffer? ¿Podría haber alguna otra razón por la que Linux está limitando artificialmente el RWIN?

Nota: He probado a activar el ECN por si acaso; pero ningún cambio, ahí.

Actualización 3 - 31 de junio.

No hay cambios tras desactivar la heurística y el autoajuste RWIN. He actualizado los controladores de red de Intel a la última (12.10.28.0) con el software que expone los ajustes de funcionalidad en las pestañas del administrador de dispositivos. La tarjeta es un 82579V Chipset on-board NIC - (Voy a hacer más pruebas de los clientes con realtek u otros proveedores)

Centrándome en la NIC por un momento, he probado lo siguiente (sobre todo descartando culpables poco probables):

  • Aumentar los búferes de recepción de 256 a 2k y los de transmisión de 512 a 2k (ambos al máximo) - Sin cambios
  • Desactivó toda la descarga de sumas de comprobación IP/TCP/UDP. - No hay cambios.
  • Desactivación de la descarga de envíos grandes - Nada.
  • Desactivado IPv6, programación QoS - Nada.

Actualización 3 - 3 de julio

Tratando de eliminar el lado del servidor Linux, inicié una instancia de Server 2012R2 y repetí las pruebas usando iperf (binario cygwin) y NTttcp .

Con iperf Tuve que especificar explícitamente -w1m en ambos lados antes de que la conexión escalara más allá de ~5Mbit/s. (Por cierto, he podido comprobarlo y el BDP de ~5Mbits a 91ms de latencia es casi precisamente 64kb. Es el límite...)

Los binarios ntttcp mostraban ahora dicha limitación. Usando ntttcpr -m 1,0,1.2.3.5 en el servidor y ntttcp -s -m 1,0,1.2.3.5 -t 10 en el cliente, puedo ver un rendimiento mucho mejor:

Copyright Version 5.28
Network activity progressing...

Thread  Time(s) Throughput(KB/s) Avg B / Compl
======  ======= ================ =============
     0    9.990         8155.355     65536.000

#####  Totals:  #####

   Bytes(MEG)    realtime(s) Avg Frame Size Throughput(MB/s)
================ =========== ============== ================
       79.562500      10.001       1442.556            7.955

Throughput(Buffers/s) Cycles/Byte       Buffers
===================== =========== =============
              127.287     308.256      1273.000

DPCs(count/s) Pkts(num/DPC)   Intr(count/s) Pkts(num/intr)
============= ============= =============== ==============
     1868.713         0.785        9336.366          0.157

Packets Sent Packets Received Retransmits Errors Avg. CPU %
============ ================ =========== ====== ==========
       57833            14664           0      0      9.476

8MB/s lo pone a los niveles que estaba obteniendo con Windows explícitamente grande en iperf . Extrañamente, sin embargo, 80MB en 1273 buffers = un buffer de 64kB de nuevo. Un wireshark adicional muestra un buen RWIN variable que regresa del servidor (factor de escala 256) que el cliente parece cumplir; así que tal vez ntttcp está reportando mal la ventana de envío.

Actualización 4 - 3 de julio

A petición de @karyhead, he hecho más pruebas y he generado algunas capturas más, aquí: https://www.dropbox.com/s/dtlvy1vi46x75it/iperf%2Bntttcp%2Bftp-pcaps-2014-07-03.zip

  • Dos más iperf s, ambos desde Windows al mismo servidor Linux que antes (1.2.3.4): Uno con un tamaño de Socket de 128k y ventana de 64k por defecto (restringe a ~5Mbit/s de nuevo) y otro con una ventana de envío de 1MB y tamaño de socket de 8kb por defecto. (escala más alto)
  • Una ntttcp traza desde el mismo cliente de Windows a una instancia EC2 de Server 2012R2 (1.2.3.5). aquí, el rendimiento escala bien. Nota: NTttcp hace algo extraño en el puerto 6001 antes de abrir la conexión de prueba. No estoy seguro de lo que está sucediendo allí.
  • Un rastreo de datos FTP, cargando 20MB de /dev/urandom a un host linux casi idéntico (1.2.3.6) usando Cygwin ncftp . De nuevo el límite está ahí. El patrón es muy parecido usando Windows Filezilla.

Cambiar la iperf La longitud del búfer marca la diferencia esperada en el gráfico de la secuencia temporal (muchas más secciones verticales), pero el rendimiento real no cambia.

11 votos

Un raro caso de un problema bien investigado que no está obviamente en la documentación. Bonito - esperemos que alguien encuentre una solución (porque de alguna manera creo que también me puede servir).

2 votos

Intente activar las marcas de tiempo RFC 1323, ya que están desactivadas por defecto en Windows, mientras que Linux las tiene activadas por defecto). netsh int tcp set global timestamps=enabled

3 votos

El retraso de 200 ms es probablemente el algoritmo de Nagle en acción. A medida que los datos son recibidos por TCP en una conexión particular, envía un acuse de recibo de vuelta sólo si una de las siguientes condiciones es verdadera: No se envió ningún acuse de recibo para el segmento anterior recibido; Se recibe un segmento, pero no llega ningún otro segmento dentro de los 200 milisegundos para esa conexión.

15voto

Pat Puntos 1087

¿Has probado a habilitar TCP compuesto (CTCP) en sus clientes de Windows 7/8.

Por favor, lea:

Aumentar el rendimiento del lado del emisor para la transmisión de alto BDP

http://technet.microsoft.com/en-us/magazine/2007.01.cableguy.aspx

...

Estos algoritmos funcionan bien para pequeñas BDPs y ventanas de recepción más pequeñas tamaños de ventana de recepción. Sin embargo, cuando se tiene una conexión TCP con un tamaño de ventana de recepción grande y un tamaño de ventana de gran BDP como la replicación de datos entre dos servidores ubicados en una red de alta velocidad Enlace WAN con un tiempo de ida y vuelta de 100ms tiempo de ida y vuelta Estos algoritmos no aumentan la ventana de envío lo suficientemente rápido como para utilizar completamente el ancho de banda de la conexión .

Para aprovechar mejor el ancho de banda de las conexiones TCP en estas situaciones, la pila TCP/IP de próxima generación incluye TCP compuesto (CTCP). CTCP aumenta de forma más agresiva la ventana de envío para conexiones con grandes tamaños de ventana de recepción y BDPs . CTCP intenta maximizar el rendimiento en este tipo de conexiones mediante el control de las variaciones de retardo y las pérdidas. Además, CTCP se asegura de que su comportamiento no afecte negativamente a otras conexiones TCP.

...

CTCP está activado por defecto en los ordenadores que ejecutan Windows Server 2008 y desactivado por por defecto en los equipos que ejecutan Windows Vista. Puede habilitar CTCP con el botón netsh interface tcp set global congestionprovider=ctcp de la empresa. Puede desactivar CTCP con el comando netsh interface tcp set global congestionprovider=none comando.

Editar 30/06/2014

para ver si el CTCP está realmente "encendido"

> netsh int tcp show global

es decir

enter image description here

Dijo PO:

Si lo he entendido bien, este ajuste aumenta la velocidad a que la ventana de congestión se amplía en lugar del tamaño máximo puede alcanzar

CTCP aumenta agresivamente la ventana de envío

http://technet.microsoft.com/en-us/library/bb878127.aspx

TCP compuesto

Los algoritmos existentes que evitan que un peer TCP emisor de la red se conocen como "slow start" y "congestion avoidance". de congestión. Estos algoritmos aumentan la cantidad de segmentos que el que el remitente puede enviar, conocida como ventana de envío, cuando envía datos inicialmente en la conexión y cuando se recupera de una pérdida de datos. en la conexión y cuando se recupera de un segmento perdido. El inicio lento aumenta la ventana de envío en un segmento TCP completo por cada segmento de acuse de recibo recibido (para TCP en Windows XP y Windows Server 2003) o por cada segmento reconocido (para TCP en Windows Vista y Windows Server 2008). La evitación de la congestión aumenta la ventana de envío en un segmento TCP completo por cada ventana completa de datos que que se reconoce.

Estos algoritmos funcionan bien para velocidades de medios LAN y tamaños de ventana TCP más pequeños más pequeñas. Sin embargo, cuando se tiene una conexión TCP con un tamaño de ventana de recepción grande y un gran producto de ancho de banda-retardo (gran ancho de banda y alto retardo), como la replicación de datos entre dos servidores ubicados a través de un enlace WAN de alta velocidad con un tiempo de ida y vuelta de 100 ms, estos algoritmos no aumentan la ventana de envío lo suficientemente rápido como para utilizar el ancho de banda de la conexión. Por ejemplo, en una WAN de 1 Gigabit por segundo (Gbps) con un tiempo de ida y vuelta (RTT) de 100 ms, puede tardar hasta una hora para que la ventana de envío aumente inicialmente al gran tamaño de la ventana que anuncia el receptor y para recuperar cuando hay segmentos perdidos.

Para aprovechar mejor el ancho de banda de las conexiones TCP en estas situaciones, la pila TCP/IP de próxima generación incluye TCP compuesto (CTCP). CTCP aumenta de forma más agresiva la ventana de envío para conexiones con tamaños de ventana de recepción grandes y productos de retardo de ancho de banda. CTCP intenta maximizar el rendimiento en este tipo de conexiones mediante control de las variaciones de retardo y de las pérdidas . CTCP también asegura que su comportamiento no afecta negativamente a otras conexiones TCP otras conexiones TCP.

En las pruebas realizadas internamente en Microsoft, los tiempos de copia de seguridad de archivos grandes se redujeron casi a la mitad para una conexión de 1 Gbps con un RTT de 50 ms. Las conexiones con un producto de retardo de ancho de banda mayor pueden tener incluso un mejor rendimiento. CTCP y Receive Window Auto-Tuning trabajan juntos para para aumentar la utilización del enlace y puede dar lugar a un aumento sustancial del rendimiento de rendimiento para conexiones con un producto de retardo de ancho de banda mayor.

3 votos

Sólo como complemento a esta respuesta, el equivalente en Powershell en Server 2012/Win8.1 es Set-NetTCPSetting con el -CongestionProvider que acepta CCTP, DCTCP y Default. El cliente y los servidores de Windows utilizan diferentes proveedores de congestión por defecto. technet.microsoft.com/es-us/library/hh826132.aspx

0 votos

Veo lo que quieres decir, pero no parece que sea aplicable. Por si acaso, hice una prueba de 30 minutos iperf y la Ventana sigue sin escalar más allá de ~520kb. Algo más está limitando el CWND antes de que este agresivo algoritmo pueda mostrar algún beneficio.

0 votos

Hay un antiguo bug de Vista (ya corregido) que presentaba este tipo de problemas al transmitir protocolos no HTML. ¿Su problema se ve exactamente igual al transferir el mismo archivo por HTML o digamos por FTP?

12voto

Kyle Brandt Puntos 50907

Aclarar el problema:

TCP tiene dos ventanas:

  • La ventana de recepción: Cuántos bytes quedan en el buffer. Este es el control de flujo impuesto por el receptor. Puedes ver el tamaño de la ventana de recepción en el wireshark ya que se compone del tamaño de la ventana y del factor de escalado de la ventana dentro de la cabecera TCP. Ambos lados de la conexión TCP anunciarán su ventana de recepción, pero generalmente el que te interesa es el que recibe la mayor parte de los datos. En tu caso, es el "servidor" ya que el cliente está cargando al servidor
  • La ventana de congestión. Es el control de flujo impuesto por el emisor. Lo mantiene el sistema operativo y no aparece en la cabecera TCP. Controla la velocidad con la que se envían los datos.

En el archivo de captura que proporcionaste. Podemos ver que el buffer de recepción nunca se desborda:

enter image description here

Mi análisis es que el emisor no está enviando lo suficientemente rápido porque la ventana de envío (también conocida como la ventana de control de la congestión) no se está abriendo lo suficiente para satisfacer el RWIN del receptor. Así que en resumen el receptor dice "Dame más", y cuando Windows es el emisor no está enviando lo suficientemente rápido.

Esto se evidencia por el hecho de que en el gráfico anterior el RWIN se mantiene abierto, y con el tiempo de ida y vuelta de 0,09 segundos y un RWIN de ~ 500.000 bytes podemos esperar un rendimiento máximo de acuerdo con el producto de retardo de ancho de banda para ser (500000/0,09) * 8 = ~ 42 Mbit / s (y sólo está recibiendo alrededor de ~ 5 en su victoria a la captura de Linux).

¿Cómo solucionarlo?

No lo sé. interface tcp set global congestionprovider=ctcp me parece que es lo correcto porque aumentaría la ventana de envío (que es otro término para la ventana de congestión). Has dicho que no está funcionando. Así que sólo para asegurarse:

  1. ¿Has reiniciado después de activar esto?
  2. ¿Está activada la descarga de la chimenea? Si lo está, prueba a desactivarla como experimento. No sé qué es exactamente lo que se descarga cuando esto está activado, pero si el control de la ventana de envío es uno de ellos, tal vez congestionprovider no tiene efecto cuando esto está activado ... Solo estoy suponiendo...
  3. Además, creo que esto puede ser anterior a Windows 7, pero usted podría tratar de añadir y jugar con las dos claves del registro llamado DefaultSendWindow y DefaultReceiveWindow en HKEY_LOCAL_MACHINE-System-CurrentControlSet-Services-AFD-Parameters. Si esto funciona, es probable que tenga el ctcp desactivado.
  4. Otra suposición, intente comprobar netsh interface tcp show heuristics . Creo que podría ser RWIN, pero no lo dice, así que tal vez jugar con la desactivación / activación que en caso de que afecta a la ventana de envío.
  5. Además, asegúrate de que los controladores están actualizados en tu cliente de prueba. Puede que algo esté roto.

Yo probaría todos estos experimentos con todas las funciones de descarga desactivadas para empezar, para eliminar la posibilidad de que los controladores de red estén haciendo alguna reescritura/modificación de las cosas (vigila la CPU mientras la descarga está desactivada). El TCP_OFFLOAD_STATE_DELEGATED struct parece dar a entender que la descarga de CWnd es al menos posible.

2 votos

He reportado tu "respuesta" porque la tuya no es una respuesta; inmediatamente me han votado en contra; ahora veo como la "gente" está votando en contra de tu "no-respuesta"... muy gracioso

1 votos

@Pat: Puedes hacer clic en el número de votos para ver el desglose de los votos positivos y negativos. Actualmente no tiene downvotes en su respuesta. Mi respuesta no resuelve su problema (pero ninguna respuesta lo hace todavía), explica y localiza el problema (¡espero que correctamente!) que es un paso importante en la solución de problemas.

0 votos

@ Kyle Brandt si aceptas que la tuya no es una respuesta me pregunto por qué no es eliminada "automáticamente" sin más y te equivocas; me dieron un down-vote (unupvote) "tan pronto" como informé de tu "respuesta"; la que aún no ha sido eliminada. Parece que aquí se juega con reglas "especiales".

5voto

karyhead Puntos 156

Ha habido una gran información aquí por @Pat y @Kyle. Definitivamente prestar atención a @Kyle's explicación de las ventanas de recepción y envío TCP, creo que ha habido cierta confusión al respecto. Para confundir aún más las cosas, iperf utiliza el término "ventana TCP" con el -w que es un término algo ambiguo con respecto a la ventana de recepción, de envío o de deslizamiento en general. Lo que realmente hace es establecer el buffer de envío del socket para el -c (cliente) y el buffer de recepción del socket en el -s (servidor). En src/tcp_window_size.c :

if ( !inSend ) {
    /* receive buffer -- set
     * note: results are verified after connect() or listen(),
     * since some OS's don't show the corrected value until then. */
    newTCPWin = inTCPWin;
    rc = setsockopt( inSock, SOL_SOCKET, SO_RCVBUF,
                     (char*) &newTCPWin, sizeof( newTCPWin ));
} else {
    /* send buffer -- set
     * note: results are verified after connect() or listen(),
     * since some OS's don't show the corrected value until then. */
    newTCPWin = inTCPWin;
    rc = setsockopt( inSock, SOL_SOCKET, SO_SNDBUF,
                     (char*) &newTCPWin, sizeof( newTCPWin ));
}

Como menciona Kyle, el problema no es con la ventana de recepción en la caja de Linux, sino que el remitente no está abriendo la ventana de envío lo suficiente. No es que no se abra lo suficientemente rápido, sino que se limita a 64k.

El tamaño del buffer del socket por defecto en Windows 7 es de 64k. Esto es lo que dice la documentación sobre el tamaño del buffer del socket en relación con el rendimiento en MSDN

Cuando se envían datos a través de una conexión TCP utilizando sockets de Windows, es importante mantener una cantidad suficiente de datos pendientes (enviados pero pero aún no reconocidos) en TCP para lograr el mayor rendimiento rendimiento. El valor ideal para la cantidad de datos pendientes para para lograr el mejor rendimiento de la conexión TCP se denomina tamaño ideal de ideal (ISB). El valor de ISB es una función del producto ancho de banda-retraso de la conexión TCP y la capacidad del receptor. ventana de recepción anunciada del receptor (y en parte de la cantidad de congestión en la red).

Ok, blah blah blah, Ahora aquí vamos:

Las aplicaciones que realizan una solicitud de envío bloqueante o no bloqueante a la vez de envío a la vez, normalmente confían en el buffering de envío interno de Winsock para conseguir un rendimiento decente. El límite del buffer de envío para una conexión dada es controlado por la opción de socket SO_SNDBUF. Para el método de envío bloqueante y método de envío no bloqueante, el límite del buffer de envío determina la cantidad de datos se mantienen pendientes en TCP . Si el valor ISB de la conexión es mayor que el límite del buffer de envío, entonces el rendimiento alcanzado en la conexión no será óptima.

El rendimiento medio de su prueba iperf más reciente utilizando la ventana de 64k es de 5,8Mbps. Eso es de Estadísticas > Resumen en Wireshark, que cuenta todos los bits. Probablemente, iperf está contando el rendimiento de los datos TCP, que es de 5,7Mbps. Vemos el mismo rendimiento con la prueba FTP también, ~5,6Mbps.

El rendimiento teórico con un buffer de envío de 64k y 91ms RTT es....5.5Mbps. Bastante cerca para mí.

Si observamos su prueba de iperf con una ventana de 1MB, el tput es de 88,2Mbps (86,2Mbps sólo para datos TCP). El tput teórico con una ventana de 1MB es de 87,9Mbps. De nuevo, lo suficientemente cerca para el trabajo gubernamental.

Lo que esto demuestra es que el buffer del socket de envío controla directamente la ventana de envío y eso, unido a la ventana de recepción del otro lado, controla el rendimiento. La ventana de recepción anunciada tiene espacio, así que no estamos limitados por el receptor.

Espera, ¿qué pasa con este asunto de la sintonización automática? ¿No maneja Windows 7 esas cosas automáticamente? Como se ha mencionado, Windows maneja el ajuste automático de la ventana de recepción, pero también puede manejar dinámicamente el buffer de envío. Volvamos a la página de MSDN:

Se ha añadido el búfer de envío dinámico para TCP en Windows 7 y Windows Server 2008 R2. Por defecto, el búfer de envío dinámico para TCP está activado a menos que una aplicación establezca la opción de socket SO_SNDBUF en el socket de flujo.

El iperf utiliza SO_SNDBUF cuando se utiliza el -w por lo que el búfer de envío dinámico estaría desactivado. Sin embargo, si no utiliza -w entonces no utiliza SO_SNDBUF . El buffering dinámico de envío debería estar activado por defecto, pero puedes comprobarlo:

netsh winsock show autotuning

La documentación dice que se puede desactivar con:

netsh winsock set autotuning off

Pero eso no funcionó para mí. Tuve que hacer un cambio en el registro y ponerlo a 0:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters\DynamicSendBufferDisable

No creo que desactivar esto ayude; es sólo una información.

¿Por qué el buffer de envío no escala por encima de los 64k por defecto cuando se envían datos a una caja Linux con mucho espacio en la ventana de recepción? Gran pregunta. Los kernels de Linux también tienen una pila TCP autoajustable. Como T-Pain y Kanye haciendo un dúo de autotune juntos, puede que no suene bien. Tal vez haya algún problema con esas dos pilas TCP de autoajuste que se comunican entre sí.

Otra persona Tuve un problema como el tuyo y pude arreglarlo con una edición del registro para aumentar el tamaño del buffer de envío por defecto. Desafortunadamente, eso ya no parece funcionar, al menos no lo hizo para mí cuando lo intenté.

En este punto, creo que está claro que el factor limitante es el tamaño del buffer de envío en el host de Windows. Dado que no parece estar creciendo dinámicamente de forma adecuada, ¿qué puede hacer una chica?

Puedes hacerlo:

  • Utilice las aplicaciones que le permiten configurar el buffer de envío, es decir, la opción de la ventana
  • Utilizar un proxy local de Linux
  • ¿Utilizar un proxy remoto de Windows?
  • Abrir un caso con Microsofhahahahaha
  • Cerveza

Descargo de responsabilidad: He pasado muchas muchas horas investigando esto y es correcto a lo mejor de mi conocimiento y google-fu. Pero no lo juraría sobre la tumba de mi madre (todavía está viva).

0 votos

Fantástica aportación; gracias. Estoy usando iperf 2.0.4, voy a experimentar con la configuración y actualizar mi OP con algunas nuevas tapas, también.

0 votos

Vale, he actualizado mi "respuesta" basándome en más investigaciones y en tus recientes pruebas

0 votos

Gracias. Al menos en parte es bueno saber que no me estoy volviendo loco. He leído algunos blogs/hilos de los días de XP/2003 que recomiendan esas configuraciones del registro, pero fueron escritos antes de Vista/2008 y estoy bastante seguro de que son ignorados en Vista en adelante. Creo que voy a elevar un ticket a MS sobre esto (deseadme suerte)

4voto

Leslie Murphy Puntos 11

Una vez que tengas la pila TCP afinada, es posible que sigas teniendo un cuello de botella en la capa Winsock. He encontrado que la configuración de Winsock (Ancillary Function Driver en el registro) hace una gran diferencia para las velocidades de carga (empujando los datos al servidor) en Windows 7. Microsoft ha reconocido un error en el autotuning TCP para los sockets no bloqueantes - justo el tipo de socket que usan los navegadores ;-)

Añade la clave DWORD para DefaultSendWindow y establécela en el BDP o superior. Yo estoy usando 256000.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\AFD\Parameters\DefaultSendWindow

Cambiar la configuración de Winsock para las descargas podría ayudar - añadir una clave para DefaultReceiveWindow.

Puede experimentar con varios ajustes del nivel de la toma de corriente utilizando el Fiddler Proxy y comandos para ajustar el tamaño del búfer del socket del cliente y del servidor:

prefs set fiddler.network.sockets.Server_SO_SNDBUF 65536 

fiddler.network.sockets.Client_SO_SNDBUF
fiddler.network.sockets.Client_SO_RCVBUF
fiddler.network.sockets.Server_SO_SNDBUF
fiddler.network.sockets.Server_SO_RCVBUF

0 votos

Gran información adicional. Por casualidad, ¿tiene un enlace de referencia para el error de MS?

0voto

Bueno, yo también me he encontrado con una situación similar (mi pregunta aquí ), y al final tuve que desactivar la heurística de escalado TCP, configurar manualmente el perfil de autoajuste y activar CTCP:

# disable heuristics
C:\Windows\system32>netsh interface tcp set heuristics wsh=disabled
Ok.

# enable receive-side scaling
C:\Windows\system32>netsh int tcp set global rss=enabled
Ok.

# manually set autotuning profile
C:\Windows\system32>netsh interface tcp set global autotuning=experimental
Ok. 

# set congestion provider
C:\Windows\system32>netsh interface tcp set global congestionprovider=ctcp
Ok.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X