19 votos

Retardar las Transferencias a través de la Distancia

Desde nuestro NY centro de datos, las transferencias a los lugares más alejados están teniendo un rendimiento deficiente.

El uso de la prueba de velocidad para probar varias ubicaciones, se puede saturar nuestros más de 100 mbit de enlace ascendente a Boston y Filadelfia fácilmente. Cuando yo uso la prueba de velocidad a la ubicación en la costa oeste de los estados unidos o de Europa, a menudo veo que sólo alrededor de 9 mbit/s.

Mi primera reacción es que esta es una escala de la ventana de problema (ancho de Banda Retardo de Producto). Sin embargo, he ajustado con los parámetros del kernel Linux en una máquina de prueba en la costa oeste y se utiliza iperf hasta el punto donde la Ventana es de tamaño suficiente para el apoyo de 100 MegaBytes por segundo y todavía tienen velocidades lentas (Verificado en la Captura). También he intentado desactivar el algoritmo de Nagle.

Tenemos un mal rendimiento de Linux y Windows, pero es significativamente peor (1/3) la velocidad usando Windows.

La forma de la transferencia (sin Nagle) es:enter image description here

El Dip alrededor de 10s ha ~100 ack duplicados.

La Forma de la Min tamaño de la Ventana del receptor a lo largo del tiempo es:

enter image description here

Alguna idea sobre dónde ir a precisar nuestro cuello de botella?

Algunos de Velocidad de los resultados de la prueba (Carga de uso speedtest.net):

  • Filadelfia: 44 mbit (Personas el uso de nuestro sitio están utilizando el resto ;-) )
  • Miami: 15 mbit
  • Dallas: 14 mbit
  • San José: 9 mbit
  • Berlín: 5 mbit
  • Sydney: 2.9 mb

Aún Más Datos:
Miami: 69.241.6.18

 2  stackoverflow-nyc-gw.peer1.net (64.34.41.57)  0.579 ms  0.588 ms  0.594 ms
 3  gig4-0.nyc-gsr-d.peer1.net (216.187.123.6)  0.562 ms  0.569 ms  0.565 ms
 4  xe-7-2-0.edge1.newyork1.level3.net (4.78.132.65)  0.634 ms  0.640 ms  0.637 ms
 5  vlan79.csw2.newyork1.level3.net (4.68.16.126)  4.120 ms  4.126 ms vlan89.csw3.newyork1.level3.net (4.68.16.190)  0.673 ms
 6  ae-81-81.ebr1.newyork1.level3.net (4.69.134.73)  1.236 ms ae-91-91.ebr1.newyork1.level3.net (4.69.134.77)  0.956 ms ae-81-81.ebr1.newyork1.level3.net (4.69.134.73)  0.600 ms
 7  ae-10-10.ebr2.washington12.level3.net (4.69.148.50)  6.059 ms  6.029 ms  6.661 ms
 8  ae-1-100.ebr1.washington12.level3.net (4.69.143.213)  6.084 ms  6.056 ms  6.065 ms
 9  ae-6-6.ebr1.atlanta2.level3.net (4.69.148.105)  17.810 ms  17.818 ms  17.972 ms
10  ae-1-100.ebr2.atlanta2.level3.net (4.69.132.34)  18.014 ms  18.022 ms  18.661 ms
11  ae-2-2.ebr2.miami1.level3.net (4.69.140.141)  40.351 ms  40.346 ms  40.321 ms
12  ae-2-52.edge2.miami1.level3.net (4.69.138.102)  31.922 ms  31.632 ms  31.628 ms
13  comcast-ip.edge2.miami1.level3.net (63.209.150.98)  32.305 ms  32.293 ms comcast-ip.edge2.miami1.level3.net (64.156.8.10)  32.580 ms
14  pos-0-13-0-0-ar03.northdade.fl.pompano.comcast.net (68.86.90.230)  32.172 ms  32.279 ms  32.276 ms
15  te-8-4-ur01.northdade.fl.pompano.comcast.net (68.85.127.130)  32.244 ms  32.539 ms  32.148 ms
16  te-8-1-ur02.northdade.fl.pompano.comcast.net (68.86.165.42)  32.478 ms  32.456 ms  32.459 ms
17  te-9-3-ur05.northdade.fl.pompano.comcast.net (68.86.165.46)  32.409 ms  32.390 ms  32.544 ms
18  te-5-3-ur01.pompanobeach.fl.pompano.comcast.net (68.86.165.198)  33.938 ms  33.775 ms  34.430 ms
19  te-5-3-ur01.pompanobeach.fl.pompano.comcast.net (68.86.165.198)  32.896 ms !X * *

69.241.6.0/23 *[BGP/170] 1d 00:55:07, MED 3241, localpref 61, from 216.187.115.12
AS path: 3356 7922 7922 7922 20214 I
> to 216.187.115.166 via xe-0/0/0.0

San José: 208.79.45.81

 2  stackoverflow-nyc-gw.peer1.net (64.34.41.57)  0.477 ms  0.549 ms  0.547 ms
 3  gig4-0.nyc-gsr-d.peer1.net (216.187.123.6)  0.543 ms  0.586 ms  0.636 ms
 4  xe-7-2-0.edge1.newyork1.level3.net (4.78.132.65)  0.518 ms  0.569 ms  0.566 ms
 5  vlan89.csw3.newyork1.level3.net (4.68.16.190)  0.620 ms vlan99.csw4.newyork1.level3.net (4.68.16.254)  9.275 ms vlan89.csw3.newyork1.level3.net (4.68.16.190)  0.759 ms
 6  ae-62-62.ebr2.newyork1.level3.net (4.69.148.33)  1.848 ms  1.189 ms ae-82-82.ebr2.newyork1.level3.net (4.69.148.41)  1.011 ms
 7  ae-2-2.ebr4.sanjose1.level3.net (4.69.135.185)  69.942 ms  68.918 ms  69.451 ms
 8  ae-81-81.csw3.sanjose1.level3.net (4.69.153.10)  69.281 ms ae-91-91.csw4.sanjose1.level3.net (4.69.153.14)  69.147 ms ae-81-81.csw3.sanjose1.level3.net (4.69.153.10)  69.495 ms
 9  ae-23-70.car3.sanjose1.level3.net (4.69.152.69)  69.863 ms ae-13-60.car3.sanjose1.level3.net (4.69.152.5)  69.860 ms ae-43-90.car3.sanjose1.level3.net (4.69.152.197)  69.661 ms
10  smugmug-inc.car3.sanjose1.level3.net (4.71.112.10)  73.298 ms  73.290 ms  73.274 ms
11  speedtest.smugmug.net (208.79.45.81)  70.055 ms  70.038 ms  70.205 ms

208.79.44.0/22 *[BGP/170] 4w0d 08:03:46, MED 0, localpref 59, from 216.187.115.12
AS path: 3356 11266 I
> to 216.187.115.166 via xe-0/0/0.0

Filadelfia: 68.87.64.49

 2  stackoverflow-nyc-gw.peer1.net (64.34.41.57)  0.578 ms  0.576 ms  0.570 ms
 3  gig4-0.nyc-gsr-d.peer1.net (216.187.123.6)  0.615 ms  0.613 ms  0.602 ms
 4  xe-7-2-0.edge1.newyork1.level3.net (4.78.132.65)  0.584 ms  0.580 ms  0.574 ms
 5  vlan79.csw2.newyork1.level3.net (4.68.16.126)  0.817 ms vlan69.csw1.newyork1.level3.net (4.68.16.62)  9.518 ms vlan89.csw3.newyork1.level3.net (4.68.16.190)  9.712 ms
 6  ae-91-91.ebr1.newyork1.level3.net (4.69.134.77)  0.939 ms ae-61-61.ebr1.newyork1.level3.net (4.69.134.65)  1.064 ms ae-81-81.ebr1.newyork1.level3.net (4.69.134.73)  1.075 ms
 7  ae-6-6.ebr2.newyork2.level3.net (4.69.141.22)  0.941 ms  1.298 ms  0.907 ms
 8  * * *
 9  comcast-ip.edge1.newyork2.level3.net (4.71.186.14)  3.187 ms comcast-ip.edge1.newyork2.level3.net (4.71.186.34)  2.036 ms comcast-ip.edge1.newyork2.level3.net (4.71.186.2)  2.682 ms
10  te-4-3-ar01.philadelphia.pa.bo.comcast.net (68.86.91.162)  3.507 ms  3.716 ms  3.716 ms
11  te-9-4-ar01.ndceast.pa.bo.comcast.net (68.86.228.2)  7.700 ms  7.884 ms  7.727 ms
12  te-4-1-ur03.ndceast.pa.bo.comcast.net (68.86.134.29)  8.378 ms  8.185 ms  9.040 ms

68.80.0.0/13 *[BGP/170] 4w0d 08:48:29, MED 200, localpref 61, from 216.187.115.12
AS path: 3356 7922 7922 7922 I
> to 216.187.115.166 via xe-0/0/0.0

Berlín: 194.29.226.25

 2  stackoverflow-nyc-gw.peer1.net (64.34.41.57)  0.483 ms  0.480 ms  0.537 ms
 3  oc48-po2-0.nyc-telx-dis-2.peer1.net (216.187.115.133)  0.532 ms  0.535 ms  0.530 ms
 4  oc48-so2-0-0.ldn-teleh-dis-1.peer1.net (216.187.115.226)  68.550 ms  68.614 ms  68.610 ms
 5  linx1.lon-2.uk.lambdanet.net (195.66.224.99)  81.481 ms  81.463 ms  81.737 ms
 6  dus-1-pos700.de.lambdanet.net (82.197.136.17)  80.767 ms  81.179 ms  80.671 ms
 7  han-1-eth020.de.lambdanet.net (217.71.96.77)  97.164 ms  97.288 ms  97.270 ms
 8  ber-1-eth020.de.lambdanet.net (217.71.96.153)  89.488 ms  89.462 ms  89.477 ms
 9  ipb-ber.de.lambdanet.net (217.71.97.82)  104.328 ms  104.178 ms  104.176 ms
10  vl506.cs22.b1.ipberlin.com (91.102.8.4)  90.556 ms  90.564 ms  90.553 ms
11  cic.ipb.de (194.29.226.25)  90.098 ms  90.233 ms  90.106 ms

194.29.224.0/19 *[BGP/170] 3d 23:14:47, MED 0, localpref 69, from 216.187.115.15
AS path: 13237 20647 I
> to 216.187.115.182 via xe-0/1/0.999

Actualización:

La excavación en este un poco más de Altura, con Jeff hemos encontrado algo extraño. De acuerdo con el TCPDump en el remitente del lado que enviar los paquetes como 65k paquetes a través de Internet. Cuando nos fijamos en los vertederos en el lado del receptor llegan fragmentado 1448 como era de esperar.

Aquí es lo que el paquete de volcado se parece en el lado del Remitente:enter image description here

Lo que sucede entonces es que el emisor piensa que es sólo el envío de paquetes de 64 kb, pero en realidad tan lejos como el receptor está en cuestión es el envío de ráfagas de paquetes. El resultado final está en mal estado de control de congestión. Usted puede ver este es un gráfico del paquete de las longitudes de los paquetes de datos que son enviados por el remitente:

enter image description here

Alguien sabe lo que podría provocar que el Remitente pensar que hay un 64 kb MTU? Tal vez algunos /proc, ethtool o ifconfig parameter? (ifconfig muestra la MTU de 1500). Mi mejor conjetura ahora es una especie de aceleración de hardware -- pero no estoy seguro de lo concreto.

Subedit 2-2 IV:
Sólo tenía un pensamiento, ya que estos 64 kb paquetes tienen el DF conjunto de bits, tal vez, mi proveedor es la fragmentación de ellos de todos modos, y jugar MSS auto descubrimiento! O tal vez nuestro firewall mal configurado...

Adjunto Editar 9.73.4 20-60:
La razón por la que estoy viendo el de 64 kb paquetes es porque segmento de descarga (tso y de la osg, ver ethtool-K). Después de la vuelta de los de fuera, estoy viendo que no hay mejoras en la velocidad de las transferencias. La forma cambia un poco y la retransmite en segmentos más pequeños:enter image description here

También he probado con todos los diferentes congestión de los algoritmos en Linux, sin mejoría. Mi NY proveedor trató de subir los archivos a una prueba de servidor ftp O desde el centro en el que estamos y es llegar 3 veces la velocidad.

La solicitada MTR informe de NY O:

root@ny-rt01:~# mtr haproxy2.stackoverflow.com -i.05 -s 1400 -c 500 -r
HOST: ny-rt01.ny.stackoverflow.co Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. stackoverflow-nyc-gw.peer1.n  0.0%   500    0.6   0.6   0.5  18.1   0.9
  2. gig4-0.nyc-gsr-d.peer1.net    0.0%   500    0.6   0.6   0.5  14.8   0.8
  3. 10ge.xe-0-0-0.nyc-telx-dis-1  0.0%   500    0.7   3.5   0.5  99.7  11.3
  4. nyiix.he.net                  0.0%   500    8.5   3.5   0.7  20.8   3.9
  5. 10gigabitethernet1-1.core1.n  0.0%   500    2.3   3.5   0.8  23.5   3.8
  6. 10gigabitethernet8-3.core1.c  0.0%   500   20.1  22.4  20.1  37.5   3.6
  7. 10gigabitethernet3-2.core1.d  0.2%   500   72.2  72.5  72.1  84.4   1.5
  8. 10gigabitethernet3-4.core1.s  0.2%   500   72.2  72.6  72.1  92.3   1.9
  9. 10gigabitethernet1-2.core1.p  0.4%   500   76.2  78.5  76.0 100.2   3.6
 10. peak-internet-llc.gigabiteth  0.4%   500   76.3  77.1  76.1 118.0   3.6
 11. ge-0-0-2-cvo-br1.peak.org     0.4%   500   79.5  80.4  79.0 122.9   3.6
 12. ge-1-0-0-cvo-core2.peak.org   0.4%   500   83.2  82.7  79.8 104.1   3.2
 13. vlan5-cvo-colo2.peak.org      0.4%   500   82.3  81.7  79.8 106.2   2.9
 14. peak-colo-196-222.peak.org    0.4%   499   80.1  81.0  79.7 117.6   3.3

16voto

Mike Pennington Puntos 6056

Descripción

Kyle, usted debe esperar a ver el diferente rendimiento de TCP para un único socket TCP con diferentes tiempos de ida y vuelta. El general en el rendimiento de TCP fórmula1:

Tmax = Rcv_Win / RTT

Para la estimación de RTT de observados ancho de banda:

RTT = Rcv_Win / Tput

Análisis

Supongamos que todos sus ventanas de recepción fueron de 64 kb (usando la ventana de escala), conecte su rendimiento para la estimación de RTT...

Tabla 1. Estimado RTT vs Observado RTT, basado en la observación de FTP rendimiento

+-----------+---------------+---------------+-----------------+
|   City    | Observed Tput | Estimated RTT | Observed Result |
+-----------+---------------+---------------+-----------------+
| Philly    |       44Mbps  |      11.9ms   |        ~9ms     |
+-----------+---------------+---------------+-----------------+
| Miami     |       15Mbps  |      34.9ms   |       ~33ms     |
+-----------+---------------+---------------+-----------------+
| Dallas    |       14Mbps  |      37.4ms   |       Unk       |
+-----------+---------------+---------------+-----------------+
| San Jose  |        9Mbps  |      58.3ms   |       ~70ms     |
+-----------+---------------+---------------+-----------------+
| Berlin    |        5Mbps  |     104.8ms   |       ~90ms     |
+-----------+---------------+---------------+-----------------+
| Sydney    |      2.9Mbps  |     180.8ms   |       Unk       |
+-----------+---------------+---------------+-----------------+

No debemos objeto si la estimación de RTT está cerca o por debajo de la medida de la RTT. Nuestro problema es que si el rendimiento de TCP es menor (debido a una mayor derivada de la RTT). La única vez que veo esta situación en los datos que hasta ahora es el de Berlín; aun así, dada la típica congestión puede ver en público trans-oceánico enlaces, no estoy alarmado tan lejos... tal vez usted podría re-post detallado RTT mediciones para el resto de los sitios (me gustaría medir con mtr por un tiempo, en lugar de traceroute).

Los Tamaños De Paquetes

Respecto a la pregunta de los 64 kb de paquetes IP que se ve de la tcpdump, recordemos que hay una diferencia entre el vínculo local MTU IP y el tamaño de los paquetes. Si el host de envío de los fragmentos de la gran paquete IP, es perfectamente legítimo para enviar un 64KB de paquetes IP a más de 1500 bytes MTU enlaces2.

Me estoy casando en 24 horas, y mi novia-a-ser, sería tostado mí a lo largo de un incendio si ella sabía que yo estaba respondiendo a preguntas sobre la SF en lugar de prepararse para la boda. Trataré de seguir más adelante este fin de semana, pero por el momento estoy fuera de tiempo. Espero que esto ayude...

EDITAR 2011-06-13:

Un par de pensamientos... en primer lugar, me hizo perder la gráfica de tamaños de ventana en su pregunta, gracias por su paciencia. Supongo que la situación y las condiciones de los datos son un poco claro hasta ahora...

  • La pregunta habla sobre iperf, speedtest.net y FTP rendimiento, pero como direcciones 69.241.6.18 no responden a las conexiones de FTP de mi servidor linux. Tendría sentido que se han tratado diversos protocolos y técnicas, pero los detalles de la correlación de que la conexión de la técnica de gráficos de conexión métricas, así como la identificación específica de origen / destino se vuelven relevantes a medida que más se recopilan los datos.
  • Cuando se utiliza iperf, por favor, sé que he sido testigo de los patéticos resultados de iperf bajo windows XP. Otros ServerFault preguntas han mencionado problemas similares en Windows 7. Mi solución es arrancar en linux con un LiveCD en la máquina en cuestión... suddently iperf resultados de empezar a hacer mucho más sentido, lo que me lleva a creer que esta puede ser un problema con iperf bajo cualquier tipo de kernel de windows, pero que no podía decir más que eso. También, que iperf interruptores están utilizando en cada extremo cuando se prueba?
  • Si FTP es la preocupación, cómo y por qué fue exactamente lo que usted pruebas (elaborada en el origen, destino, y de cliente / servidor de versiones usa)?
  • Siempre he surfeado a speedtest.net en el pasado, se midió con múltiples paralelas sockets TCP; esto es muy diferente de la medición de lo que se ve durante una transferencia FTP (TCP socket). Si estás midiendo con varios sockets TCP y obtener resultados que son significativamente menores que la velocidad del puerto, este es un dato importante para mí, ya que mi experiencia con el paralelo sockets (3 - 5 en paralelo) fácilmente saturada de una conexión, incluso en la cara de una modesta pérdida de paquetes en el camino.
  • Podría publicar más detalles con un resumen de los resultados de una mtr de seguimiento de y para cada punto de prueba en cuestión? Tal vez una tabla que muestra lo que el protocolo / prueba de la técnica utilizada, el rendimiento, los resultados de la prueba, mtr de pérdida de paquetes, mtr de ida y tiempo de respuesta. mtr mediciones deben ser realizadas antes de la transferencia ocurre.

Finalmente, veo algunas referencias a un firewall en tu pregunta. Hice consultas en google "escalado de la ventana tcp firewall" y encontré varias anécdotas referencias a problemas de rendimiento con la escala de ventana de TCP a través de firewalls; lamentablemente no hubo bugids o incluso los proveedores mencionados. Tal vez usted podría tratar de un par de transferencias FTP desde un equipo portátil con un knoppix o livecd debian dentro y fuera de su firewall (y así tener una consistente plataforma de referencia entre las pruebas).


FINAL DE NOTAS:
  1. Referencia: Marco de Rendimiento de TCP Pruebas, la Sección 3.3.1
  2. Ver el final de las notas en esta pregunta en Unix y Linux para obtener más detalles.

5voto

Tall Jeff Puntos 878

Asegurarse de que la ventana TCP es abrir de par en par bastante para cubrir el ancho de Banda Retardo Producto hubiera sido mi primera conjetura demasiado. Suponiendo que está correctamente configurado (y apoyada en ambos extremos) me gustaría siguiente examinar un paquete de seguimiento para asegurarse de que la ventana que realmente se está abriendo y que uno de los saltos en la ruta no está privando a la escala de la ventana. Si que es buena, y está seguro de que no están golpeando en un ancho de banda restringido hop en el camino, la probable causa de sus problemas es al azar paquete de gotas. Esta hipótesis es apoyada por la indicación de los ACKs duplicados que usted ha mencionado. (ACKs duplicados en general son un resultado directo de la pérdida de datos). También tenga en cuenta que con un gran ancho de banda retardo del producto y, por tanto, una gran apertura de ventana deslizante, incluso niveles bajos de azar paquete de gotas puede entorpecer el rendimiento total de la conexión.

Nota: Para grandes transferencias de datos a través de TCP y a través de una multi-hop de conexión WAN, no debería haber ninguna necesidad o razón para deshabilitar Este. De hecho, ese mismo escenario es la razón por la Nagle existe. En general, Nagle sólo debe estar deshabilitado para las conexiones interactivas donde los sub-MTU del tamaño de los datagramas deben ser forzados a cabo sin ningún tipo de demora. es decir: Para transferencias masivas, desea la mayor cantidad de datos en cada paquete como sea posible.

1voto

nmenezes Puntos 111

¿afinar su paquete de reordenación threshould? Comprobar en tcp_reordering en /proc en Linux. En largas pipas, es común que un multipath efecto a causa falsa pérdida de paquetes dectection, retransmisión y las gotas en la velocidad de envío de su carta. Esto hace que una gran cantidad de Ack duplicados, así que vale la pena ser revisado. No se olvide que usted debe ajustar ambos lados de la tubería para tener buena resuls y utilizar por lo menos cúbicos. Un sistema interactivo de protocolo, como ftp pueden dañar a cualquier tcp para tubo largo de optimización que puede hacer. A menos que usted es sólo la transferencia de archivos de gran tamaño.

-2voto

Layn Puntos 13

Lo que estamos viendo se ve bastante normal para mí, basado en la latencia de la que informes a sus sitios diferentes. Latencia asesinato a través de rendimiento de casi cualquier conexión, independientemente del ancho de banda disponible, muy rápidamente.

Silver Peak ofrecer un rápido y sucio estimador del rendimiento que puede esperar para ver con una determinada cantidad de ancho de banda de un determinado nivel de latencia aquí: http://www.silver-peak.com/calculator/

Conecte un 100mbit conexión con el adecuado latencias que estamos viendo, y usted encontrará que sus velocidades son de hecho de la coincidencia (Aproximadamente) con lo que usted debe esperar para ver.

Como para Windows la entrega de un peor rendimiento que los de Linux, que no puede ofrecer ningún buenas sugerencias, por desgracia. Supongo que usted está haciendo una de las manzanas con manzanas comparación con idéntico hardware (tarjetas de red, específicamente)?

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: