mejor rendimiento de TCP en una "red de alto retraso"

Estoy tratando de mejorar mi rendimiento TCP a través de una "red de alto retraso" entre máquinas Linux.

Configuré tcp_mem, tcp_wmemy tcp_rmem"8192 7061504 7061504".
Me puse rmem_max, wmem_max, rmem_defaulty wmem_defaultpara “7061504”.
Configuré netdev_max_backlogy txqueuelenen 10000.
Configuré tcp_congestion_controlen "escalable".

Estoy usando "nist" (cnistnet) para simular un retraso de 100 ms, y el BW que alcanzo es de aproximadamente 200mbps (sin demora alcanzo aproximadamente 790mbps).

Estoy usando iperf para realizar las pruebas y TCPTrace para analizar los resultados, y esto es lo que obtuve:

En el lado del receptor:
max win adv: 5294720 bytes
avg win adv: 5273959 bytes
sack paquetes enviados: 0

En el lado del remitente:
bytes de datos reales: 3085179704
bytes de datos rexmt: 9018144 propiedad
máxima: 5294577 bytes
propiedad promedio: 3317125 bytes
RTT mínima: 19,2 ms
RTT máxima: 218,2 ms
RTT promedio: 98,0 ms

¿Por qué solo alcanzo 200mbps? Sospecho que el "owin" tiene algo que ver con eso, pero no estoy seguro (estos resultados son de una prueba de 2 minutos. Una prueba de 1 minuto tuvo un "avg owin" de 1552900) ...

¿Me equivoco al esperar que el rendimiento sea de casi 790 mbps incluso si el retraso es de 100 ms?

(Intenté usar números más grandes en las configuraciones de la ventana, pero no pareció tener efecto)

Este es un problema TCP común llamado "Long Fat Pipe". Si busca en Google esa frase y TCP, encontrará mucha información sobre este problema y las posibles soluciones.

Este hilo tiene un montón de cálculos y sugerencias sobre cómo ajustar la pila TCP de Linux para este tipo de cosas.

El sitio

http://www.psc.edu/networking/projects/tcptune/

menciona que, como Linux hoy en día ajusta automáticamente la configuración de TCP, jugar con los valores probablemente no mejorará las cosas.

Dicho esto, tal vez 100 ms junto con un gran ancho de banda (al menos 790 mbps) podrían conducir a un BDP enorme, por lo que tal vez el ajuste automático decida que algo está mal y no llega lo suficientemente lejos ...

Intente configurar el tamaño de la ventana iperf para realmente mecanizar el producto de ancho de banda de ese enlace. Así que prom. RTT * 1Gbps debería darle aproximadamente 10 MB. A ver si eso mejora las cosas.

La única forma en que realmente puede comenzar a comprender lo que está sucediendo es obtener más datos; de lo contrario, solo está adivinando o pidiendo a otras personas que lo hagan. Recomiendo obtener una vista de nivel del sistema (CPU, memoria, interrupciones, etc.) sardesde el iostatpaquete. Además, debe obtener un volcado de paquetes con Wireshark o tcpdump. Luego puede usar Wireshark para analizarlo, ya que tiene muchas herramientas para esto. Puede graficar el tamaño de la ventana con el tiempo, la pérdida de paquetes, etc.

Incluso una pequeña pérdida de paquetes en un enlace de alta latencia tiende a dañar bastante el ancho de banda. Aunque se simule, esto es un poco extraño. Muchos paquetes pequeños también pueden causar interrupciones altas (¿aunque también podrían simularse?).

En resumen, obtenga TCPDump y Sar para ver qué sucede a nivel de paquete y con los recursos de su sistema.

¿Cuánta memoria tiene esta máquina? La tcp_memconfiguración parece ser una locura, configuró 28gb (7061504 * 4kb) para datos TCP a nivel mundial. (Pero este no es su problema de rendimiento, ya que lo más probable es que no alcance ese límite en una ejecución de prueba de pocos sockets. Solo quería mencionarlo, ya que establecer los valores tcp_mem en tcp_xmem muestra una idea errónea muy común).

El 7mb que ha configurado por defecto parece estar bien. Sin embargo, el máximo puede subir mucho más en tuberías de gran retraso. Para las pruebas, usaría 64 MB como el número máximo para tcp_wmemy tcp_rmem, luego, puede descartar que este sea su factor limitante. (Esto hincha los búferes, por lo que solo funciona si tiene una concurrencia limitada y la conexión tiene poca fluctuación y caídas).