Transferts lents sur la distance

Depuis notre centre de données de NY, les transferts vers des emplacements plus éloignés ont de mauvaises performances.

En utilisant le test de vitesse pour tester divers emplacements, nous pouvons facilement saturer notre liaison montante de 100 Mbits vers Boston et Philadelphie. Lorsque j'utilise le test de vitesse à un emplacement sur la côte ouest des États-Unis ou de l'Europe, je ne vois souvent que 9 mbit / s environ.

Ma première réaction est qu'il s'agit d'un problème de mise à l'échelle de la fenêtre (Bandwidth Delay Product). Cependant, je me suis ajusté avec les paramètres du noyau Linux sur une machine de test sur la côte ouest et j'ai utilisé iperf au point où la fenêtre est suffisamment grande pour prendre en charge 100 mégaoctets par seconde et avoir toujours des vitesses lentes (vérifié dans Capture). J'ai également essayé de désactiver l'algorithme Nagle.

Nous obtenons des performances médiocres à la fois sous Linux et Windows, mais la vitesse d'utilisation de Windows est nettement pire (1/3).

La forme du transfert (sans Nagle) est:

Le Dip around 10s a environ 100 doublons.

La forme de la taille de la fenêtre minimale du récepteur au fil du temps est la suivante:

Des idées sur où aller ensuite pour épingler notre goulot de bouteille?

Quelques résultats des tests de vitesse (téléchargement à l'aide de speedtest.net):

• Philadelphie: 44 mbit (les personnes utilisant notre site utilisent le reste ;-))
• Miami: 15 mbit
• Dallas: 14 mbit
• San Jose: 9 mbit
• Berlin: 5 mbit
• Sydney: 2,9 mbit

Encore plus de données:
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 Jose: 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

Philly: 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

Berlin: 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

Mise à jour:

En creusant un peu plus profondément avec Tall Jeff, nous avons trouvé quelque chose d'étrange. Selon le TCPDump du côté de l' expéditeur, il envoie les paquets en tant que paquets de 65 000 sur Internet . Lorsque nous regardons les décharges côté récepteur, elles arrivent fragmentées 1448 comme vous vous en doutez.

Voici à quoi ressemble le vidage de paquets du côté de l'expéditeur:

Ce qui se passe alors, c'est que l'expéditeur pense qu'il envoie simplement des paquets de 64k, mais en réalité, en ce qui concerne le récepteur, il envoie des rafales de paquets. Le résultat final est un contrôle de congestion foiré. Vous pouvez voir ceci est un graphique de la longueur des paquets de paquets de données envoyés par l'expéditeur:

Quelqu'un sait-il ce qui pourrait faire croire à l'expéditeur qu'il existe un MTU 64k? Peut-être certains /proc, ethtoolou ifconfig parameter? ( ifconfigindique que le MTU est de 1500). Ma meilleure supposition en ce moment est une sorte d'accélération matérielle - mais je ne sais pas quoi en particulier.

Subedit 2-2 IV:
Je viens de penser, puisque ces paquets 64k ont ​​le bit DF défini, peut-être que mon fournisseur les fragmente de toute façon et gâche la découverte automatique MSS! Ou peut-être que notre pare-feu est mal configuré ...

Édition complémentaire 9.73.4 20-60:
La raison pour laquelle je vois les paquets de 64k est parce que le déchargement de segment (tso et gso, voir ethtool -K) est activé. Après avoir désactivé ces options, je ne constate aucune amélioration de la vitesse des transferts. La forme change un peu et les retransmissions sont en segments plus petits:

J'ai également essayé tous les différents algorithmes de congestion sous Linux sans aucune amélioration. Mon fournisseur de NY a essayé de télécharger des fichiers sur un serveur ftp de test en OR depuis l'installation dans laquelle nous nous trouvons et obtient 3 fois plus de vitesse.

Le rapport MTR demandé de NY à OR:

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

S'assurer que la fenêtre TCP s'ouvre suffisamment pour couvrir le produit de retard de bande passante aurait également été ma première supposition. En supposant que cela est correctement configuré (et pris en charge par les deux extrémités), j'examinerais ensuite une trace de paquet pour m'assurer que la fenêtre s'ouvre vraiment et que l'un des sauts du chemin ne supprime pas la mise à l'échelle de la fenêtre. Si tout cela est bon et que vous êtes certain de ne pas vous heurter à un saut limité en bande passante sur le chemin, la cause probable de vos problèmes est la perte aléatoire de paquets. Cette hypothèse est étayée par l'indication des ACK dupliqués que vous avez mentionnés. (Les ACK dupliqués sont généralement le résultat direct de la perte de données). Notez également qu'avec un produit de retard à large bande passante et donc une grande fenêtre coulissante ouverte,

Remarque latérale: pour les transferts de données en masse via TCP et via une connexion WAN à plusieurs sauts, il ne devrait pas être nécessaire ni nécessaire de désactiver Nagle. En fait, ce scénario exact explique pourquoi Nagle existe. En général, Nagle ne doit être désactivé que pour les connexions interactives où les datagrammes de taille inférieure à MTU doivent être expulsés sans délai. c'est-à-dire: pour les transferts en masse, vous voulez autant de données que possible dans chaque paquet.

avez-vous réglé votre paquet en réordonnant? Vérifiez-le sur tcp_reordering sur / proc sous Linux. Sur les longs tuyaux, il est courant qu'un effet de trajets multiples provoque une fausse détection de perte de paquets, une retransmission et les baisses de vitesse que vous avez envoyées dans votre graphique. Il provoque également de nombreux Acks en double, donc cela vaut la peine d'être vérifié. N'oubliez pas que vous devez régler les deux côtés du tuyau pour avoir de bons résuls et utiliser au moins cubique. Un protocole interactif, comme ftp, peut nuire à n'importe quel TCP pour l'optimisation des longs tuyaux que vous pouvez faire. À moins que vous ne transfériez que des fichiers volumineux.

Ce que vous voyez me semble assez normal, en fonction de la latence que vous signalez à vos différents sites. La latence tuera à travers le débit presque n'importe quelle connexion unique, quelle que soit la bande passante disponible, très rapidement.

Silver Peak offre un estimateur rapide et sale pour le débit que vous pouvez vous attendre à voir avec une quantité de bande passante donnée et un niveau de latence donné ici: http://www.silver-peak.com/calculator/

Branchez une connexion de 100 Mbits avec les latences appropriées que vous voyez, et vous constaterez que vos vitesses correspondent réellement (approximativement) à ce que vous devriez vous attendre à voir.

En ce qui concerne Windows offrant des performances inférieures à Linux, je ne peux malheureusement pas proposer de bonnes suggestions. Je suppose que vous faites une comparaison de pommes à pommes avec du matériel identique (NIC, en particulier)?