Windows Escala de Ventana de TCP Golpear meseta demasiado temprano

Has intentado habilitar TCP Compuesto (CTCP) en su Windows 7/8 clientes.

Por favor lea:

El aumento de Remitente Rendimiento de Alta Transmisión de BDP

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

...

Estos algoritmos funcionan bien para las pequeñas Bdp y los más pequeños de la ventana de recepción los tamaños. Sin embargo, cuando usted tiene una conexión TCP con un gran reciben el tamaño de la ventana y un gran BDP, tales como la replicación de datos entre dos los servidores que se encuentra a través de una alta velocidad de enlace WAN con un 100ms de ida el tiempo, estos algoritmos no aumente la ventana de envío bastante rápido para utilizar completamente el ancho de banda de la conexión.

Para aprovechar mejor el ancho de banda de las conexiones TCP en estos situaciones, la Próxima Generación de la pila TCP/IP incluye TCP Compuesto (CTCP). CTCP de forma más agresiva aumenta la ventana de envío de conexiones con grandes tamaños de ventana de recepción y Bdp. CTCP intenta maximizar el rendimiento de estos tipos de conexiones mediante el monitoreo de retraso las variaciones y pérdidas. Además, el CTCP se asegura de que su comportamiento no afecta negativamente a otras conexiones TCP.

...

CTCP está habilitado de forma predeterminada en los equipos que ejecutan Windows Server 2008 y movilidad por por defecto en los equipos que ejecutan Windows Vista. Puede habilitar el CTCP con la netsh interface tcp set global congestionprovider=ctcp comando. Puede deshabilitar CTCP con el netsh interface tcp set global congestionprovider=none comando.

Editar 6/30/2014

a ver si CTCP está realmente "en"

> netsh int tcp show global

es decir,

PO dijo:

Si lo entiendo correctamente, esta configuración aumenta la velocidad a la que la ventana de congestión se agranda más que el tamaño máximo se puede llegar a

CTCP agresiva aumenta la ventana de envío

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

TCP compuesto

Los algoritmos existentes que impiden que un envío de TCP pares de abrumadora la red se conoce como inicio lento y la congestión la evitación. Estos algoritmos de aumentar la cantidad de segmentos que el el remitente puede enviar, conocida como la ventana de envío, cuando inicialmente el envío de datos en la conexión y cuando se está recuperando de un segmento perdido. Inicio lento aumenta la ventana de envío por un segmento TCP completo por cada reconocimiento segmento recibido (para TCP en Windows XP y Windows Server 2003) o para cada segmento de reconocida (para TCP en Windows Vista y Windows Server 2008). Para evitar la congestión aumenta la ventana de envío por un segmento TCP completo para cada ventana de datos completa que es reconocido.

Estos algoritmos funcionan bien para LAN las velocidades de los medios y de menor tamaño de la ventana TCP los tamaños. Sin embargo, cuando usted tiene una conexión TCP con un gran reciben el tamaño de la ventana y un gran ancho de banda-retardo del producto (ancho de banda alto y alto retardo), tales como la replicación de datos entre dos servidores ubicados a través de una WAN de alta velocidad con un vínculo de 100 ms tiempo de ida y vuelta, estos los algoritmos de no aumentar la ventana de envío bastante rápido para totalmente utilizar el ancho de banda de la conexión. Por ejemplo, en un 1 Gigabit por segundo (Gbps) enlace WAN con un 100 ms tiempo de ida y vuelta (RTT), se puede tomar hasta una hora para que la ventana de envío inicialmente para aumentar la gran tamaño de la ventana que se anuncia por el receptor y recuperar al hay segmentos perdidos.

Para aprovechar mejor el ancho de banda de las conexiones TCP en estos situaciones, la Próxima Generación de la pila TCP/IP incluye TCP Compuesto (CTCP). CTCP de forma más agresiva aumenta la ventana de envío de conexiones con grandes tamaños de ventana de recepción y gran ancho de banda-retardo productos. CTCP intenta maximizar el rendimiento de estos tipos de las conexiones de monitoreo de las variaciones de retraso y pérdidas. CTCP también se asegura de que su comportamiento no afecta negativamente a otras TCP las conexiones.

En las pruebas realizadas internamente en Microsoft, gran copia de seguridad de archivos veces se redujeron casi a la mitad por una conexión de 1 Gbps con un 50ms RTT. Conexiones con un mayor ancho de banda retardo producto puede tener incluso mejor rendimiento. CTCP y Recibir ajuste Automático de Ventana de trabajar juntos para el aumento de la utilización del acoplamiento y pueden resultar en importantes rendimiento las ganancias de ancho de banda-retardo del producto conexiones.

Aclarar el Problema:

TCP tiene dos ventanas:

• La ventana de recepción: ¿cuántos bytes quedan en el buffer. Este es el flujo de control impuestas por el receptor. Usted puede ver el tamaño de la ventana de recepción en el wireshark, ya que se compone de el tamaño de la ventana y el cerramiento del factor de escala en el interior de la cabecera TCP. Ambos lados de la conexión TCP se anuncian su ventana de recepción, pero en general la que importa es la persona que recibe el grueso de los datos. En su caso, es el "servidor" ya que el cliente es la carga en el servidor
• La ventana de congestión. Este es el flujo de control impuestas por el Remitente. Este es mantenida por el sistema operativo y no se muestra en el encabezado TCP. Controla la tasa de cómo de rápido se envían datos.

En el archivo de captura proporcionada. Podemos ver que el búfer de recepción nunca es desbordante:



Mi análisis es que el remitente no se envío rápido porque la ventana de envío (también conocido como el control de la congestión de la ventana) no es la apertura suficiente para satisfacer el RWIN del receptor. Así que en breve el receptor dice "dame Más", y cuando Windows es el remitente no es el envío bastante rápido.

Esto se evidencia por el hecho de que en la gráfica anterior, el RWIN permanece abierto, y con el tiempo de ida y vuelta de .09 segundos y un RWIN de de ~ 500.000 bytes, podemos esperar un máximo rendimiento de acuerdo con el ancho de banda retardo de producto(500000/0.09) * 8 =~ 42 Mbit/s (y usted está consiguiendo solamente acerca de ~5 en su win a Linux en la captura).

Cómo solucionarlo?

No sé. interface tcp set global congestionprovider=ctcp suena como la cosa correcta de hacer para mí, porque aumentaría la ventana de envío (que es otro término para la ventana de congestión). Usted dijo que no está funcionando. Sólo para asegurarse de que:

1. ¿Reiniciar después de habilitar esta función?
2. Es la Chimenea de descarga? Si es que tal vez intente desactivarlo como un experimento. No sé exactamente lo que pone de descarga cuando esta habilitado, pero si el control de la ventana de envío es uno de ellos, tal vez congestionprovider no tiene ningún efecto cuando esta opción está habilitada... solo estoy adivinando...
3. Yo también creo que esto puede ser anterior a windows 7, pero usted puede tratar de añadir y jugando con las dos claves del registro llamado DefaultSendWindow y DefaultReceiveWindow en HKEY_LOCAL_MACHINE-System-CurrentControlSet-Servicios-AFD-Parámetros. Si estas incluso el trabajo, usted probablemente bid se han ctcp off.
4. Otra conjetura, intente comprobar netsh interface tcp show heuristics. Creo que podría ser RWIN, pero no lo dice, así que tal vez jugar con la deshabilitación/habilitación de que en caso de que los impactos de la ventana de envío.
5. También, asegúrese de que los controladores están actualizados en tu cliente de prueba. Tal vez es algo que sólo roto.

Me gustaría probar todos estos experimentos con todo lo que la descarga de las características off para empezar a eliminar la posibilidad de que los controladores de red están haciendo algunos reescritura/modificación de las cosas (mantenga un ojo de la CPU, mientras que la descarga está deshabilitado). El TCP_OFFLOAD_STATE_DELEGATED struct parece, al menos, implica que CWnd la descarga es al menos posible.

Ha habido algunos grandes info aquí por @Pat y @Kyle. Definitivamente la atención de la paga a @Kyle explicación de la TCP recibir y enviar de windows, creo que ha habido cierta confusión en torno a eso. Para confundir más, iperf se utiliza el término "de la ventana de TCP" con el -w que es un término ambiguo con respecto a la recepción, envío, o en general de la ventana deslizante. Lo que realmente hace es fijar el zócalo en el buffer de envío de la -c (cliente) de la instancia y el zócalo búfer de recepción en la -s (servidor) de la instancia. 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 Kyle menciona, el problema no es con la ventana de recepción en el cuadro de Linux, pero el remitente no es la apertura de la ventana de envío suficiente. No es que no abre hasta bastante rápido, sólo las tapas en los 64 kb.

El socket predeterminado de tamaño de búfer en Windows 7 es de 64 kb. He aquí lo que la documentación dice sobre el socket tamaño de búfer en relación con el rendimiento en MSDN

Cuando el envío de datos a través de una conexión TCP utilizando sockets de Windows, es importante para mantener una cantidad suficiente de datos pendientes (enviado pero no se reconoce todavía) en TCP con el fin de lograr el más alto rendimiento. El valor ideal para la cantidad de datos pendientes a lograr el mejor rendimiento de la conexión TCP se llama el ideal enviar retraso (ISB) de tamaño. El ISB de valor es una función de la ancho de banda-retardo producto de la conexión de TCP y el receptor del anuncian la ventana de recepción (y, en parte, la cantidad de congestión en el de la red).

Ok, bla, bla, bla, Ahora, aquí vamos:

Las aplicaciones que realizan un bloqueo o sin bloqueo de enviar la solicitud en un tiempo, en general, dependen interno enviar búfer de Winsock para lograr decente rendimiento. El búfer de envío límite para una conexión dada es controlado por el SO_SNDBUF opción de socket. Para el bloqueo y sin bloqueo método de envío, el búfer de envío de límite determina cuánto los datos se mantienen pendientes en TCP. Si el ISB valor para la conexión es más grande que el búfer de envío de límite, entonces el rendimiento alcanzado en la conexión no será el óptimo.

El promedio de rendimiento de su más reciente iperf prueba con el de 64 kb de la ventana es de 5.8 Mbps. Que a partir de las Estadísticas > Resumen en Wireshark, que cuenta con todos los bits. Probablemente, iperf es contar TCP rendimiento de datos que es de 5,7 Mbps. Vemos el mismo rendimiento que con la prueba de FTP así, ~5.6 Mbps.

El teórico y el rendimiento con un 64 kb en el buffer de envío y 91ms RTT es....5.5 Mbps. Lo suficientemente cerca como para mí.

Si nos fijamos en su 1MB ventana iperf de la prueba, el tput es 88.2 Mbps (86.2 Mbps por solo datos TCP). El teórico tput con un 1MB ventana es un 87,9 Mbps. De nuevo, lo suficientemente cerca para que el trabajo del gobierno.

Esto lo que demuestra es que el socket de envío buffer directamente los controles de la ventana de envío y que, junto con la de la ventana de recepción desde el otro lado, los controles de rendimiento. La publicidad de la ventana de recepción de habitación, por lo que no estamos limitados por el receptor.

Aguantar, lo que acerca de este autoajuste de negocio? No Windows 7 que manejar las cosas de forma automática? Como se ha mencionado, Windows no manejar auto-escalado 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:

Dinámica de enviar el almacenamiento en búfer para TCP fue agregado en Windows 7 y Windows Server 2008 R2. De forma predeterminada, la dinámica de enviar el almacenamiento en búfer para TCP está habilitado a menos que una aplicación establece la SO_SNDBUF opción de socket en el arroyo zócalo.

iperf utiliza SO_SNDBUF cuando se usa el -w opción, tan dinámico enviar el almacenamiento en búfer será desactivada. Sin embargo, si usted no usa -w entonces no uso SO_SNDBUF. Dinámica de enviar el almacenamiento en búfer debe ser activada por defecto, pero se puede comprobar:

netsh winsock show autotuning

La documentación dice que se puede desactivar con:

netsh winsock set autotuning off

Pero eso no funciona para mí. He tenido que hacer un cambio de registro y establecer a 0:

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

No creo que la desactivación de esto va a ayudar; es simplemente una FYI.

¿Por qué no su búfer de envío de escala por encima de los 64 kb predeterminado cuando el envío de datos a un cuadro de Linux con un montón de espacio en la ventana de recepción? Gran pregunta. Kernel de Linux también tienen un autoajuste pila TCP. Como T-pain y Kanye haciendo un autotune dueto juntos, es posible que no suena bien. Tal vez hay algún problema con los dos autoajuste de pilas TCP hablando el uno al otro.

Otra persona ha tenido un problema como el suyo y fue capaz de solucionarlo con una edición de registro para aumentar el valor predeterminado tamaño de búfer de envío. Por desgracia, eso no parece funcionar, al menos no para mí cuando me lo probé.

En este punto, creo que es claro que el factor limitante es el tamaño de búfer de envío en el host de Windows. Dado que no parece ser dinámicamente creciendo adecuadamente, ¿qué es una muchacha a hacer?

Usted puede:

• El uso de aplicaciones que permiten establecer el búfer de envío decir, la opción de la ventana
• El uso de un local de Linux proxy
• Uso remoto del servidor proxy de Windows?
• Abrir un caso con Microsofhahahahahahaha
• La cerveza

Descargo de responsabilidad: he pasado muchas horas investigando este y es correcta al mejor de mi conocimiento y mi google-fu. Pero no os lo juro por la tumba de mi madre (ella aún vive).

Una vez que la pila TCP atentos, usted todavía puede tener un cuello de botella en la capa de Winsock. He encontrado que la configuración de Winsock (Controlador de Función Auxiliar en el registro) hace una gran diferencia en la velocidad de carga (empujando los datos en el servidor) en Windows 7. Microsoft ha reconocido un error en el ajuste automático TCP para sockets de bloqueo -- justo el tipo de socket que los navegadores de uso ;-)

Agregar clave DWORD para DefaultSendWindow y establezca la BDP o superior. Estoy usando 256000.

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

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

Usted puede experimentar con diferentes nivel de socket de la configuración mediante el Violinista Proxy y comandos para ajustar el cliente y el servidor de socket tamaños de búfer:

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

Bien, me he encontrado con una situación similar a mí mismo (mi pregunta aquí), y al final he tenido que deshabilitar TCP escala heurística, establezca manualmente el autoajuste de perfil y habilitar 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.