Trasferimenti lenti su distanza

Dal nostro datacenter di New York, i trasferimenti verso località più lontane hanno prestazioni scarse.

Utilizzando il test di velocità per testare varie località, possiamo saturare facilmente il nostro uplink da 100 mbit a Boston e Filadelfia. Quando utilizzo il test di velocità per localizzare sulla costa occidentale degli Stati Uniti o in Europa, vedo spesso solo circa 9 mbit / s.

La mia prima reazione è che si tratta di un problema di ridimensionamento della finestra (prodotto di ritardo della larghezza di banda). Tuttavia, mi sono adattato con i parametri del kernel Linux su una macchina di prova sulla costa occidentale e ho usato iperf al punto in cui Window è dimensionato a sufficienza per supportare 100 MegaByte al secondo e ho ancora velocità lente (Verified in Capture). Ho anche provato a disabilitare l'algoritmo Nagle.

Otteniamo prestazioni scadenti sia da Linux che da Windows, ma è significativamente peggiore (1/3) della velocità con Windows.

La forma del trasferimento (senza Nagle) è:

Il tuffo intorno ai 10 ha circa 100 duplicati.

La dimensione della finestra Min nel tempo del ricevitore è:

Qualche idea su dove andare dopo per fissare il collo di bottiglia?

Alcuni risultati dei test di velocità (caricamento tramite speedtest.net):

• Filadelfia: 44 mbit (Le persone che usano il nostro sito stanno usando il resto ;-))
• Miami: 15 mbit
• Dallas: 14 mbit
• San Jose: 9 mbit
• Berlino: 5 mbit
• Sydney: 2.9 mbit

Ancora più dati:
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

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

Aggiornare:

Scavando un po 'più in profondità con Tall Jeff abbiamo trovato qualcosa di strano. Secondo il TCPDump sul lato del mittente, invia i pacchetti come pacchetti da 65k su Internet . Quando osserviamo le discariche sul lato del ricevitore, arrivano frammentate nel 1448 come ci si aspetterebbe.

Ecco come appare il dump del pacchetto sul lato mittente:

Quello che succede allora è che il mittente pensa che stia semplicemente inviando pacchetti da 64k, ma in realtà, per quanto riguarda il destinatario, sta inviando scoppi di pacchetti. Il risultato finale è un controllo della congestione incasinato. Puoi vedere che questo è un grafico delle lunghezze dei pacchetti di pacchetti di dati inviati dal mittente:

Qualcuno sa cosa potrebbe indurre il mittente a pensare che ci sia un MTU a 64k? Forse alcuni /proc, ethtoolo ifconfig parameter? ( ifconfigmostra che l'MTU è 1500). La mia ipotesi migliore in questo momento è una sorta di accelerazione hardware, ma non sono sicuro di cosa specificamente.

Subedit 2-2 IV:
Ho appena pensato, dal momento che questi pacchetti da 64k hanno il bit DF impostato, forse il mio provider li sta frammentando comunque e rovinando il rilevamento automatico di MSS! O forse il nostro firewall non è configurato correttamente ...

Aggiunta Modifica 9.73.4 20-60:
Il motivo per cui sto vedendo i pacchetti 64k è perché lo scaricamento del segmento (tso e gso, vedi ethtool -K) è attivo. Dopo aver disattivato quelli, non vedo alcun miglioramento nella velocità dei trasferimenti. La forma cambia leggermente e le ritrasmissioni sono in segmenti più piccoli:

Ho anche provato tutti i diversi algoritmi di congestione su Linux senza alcun miglioramento. Il mio fornitore di New York ha provato a caricare file su un server ftp di prova in sala operatoria dalla struttura in cui ci troviamo e sta ottenendo una velocità 3 volte maggiore.

Il rapporto MTR richiesto da NY a 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

Assicurarsi che anche la finestra TCP si apra abbastanza da coprire il ritardo della larghezza di banda sarebbe stata la mia prima ipotesi. Supponendo che sia configurato correttamente (e supportato da entrambe le estremità), esaminerei quindi una traccia di pacchetto per assicurarmi che la finestra si stia davvero aprendo e che uno dei salti nel percorso non stia eliminando il ridimensionamento della finestra. Se va bene, e sei certo di non sbattere contro un hop vincolato dalla larghezza di banda nel percorso, la causa probabile dei tuoi problemi è la caduta casuale dei pacchetti. Questa ipotesi è supportata dall'indicazione degli ACK duplicati che hai citato. (Gli ACK duplicati sono generalmente il risultato diretto della perdita di dati). Tieni inoltre presente che con un prodotto con ritardo di larghezza di banda elevato e quindi una grande finestra scorrevole aperta,

Nota a margine: per i trasferimenti di dati in blocco su TCP e su una connessione WAN multi-hop, non dovrebbero essere necessari motivi per disabilitare Nagle. In realtà, quello scenario esatto è il motivo per cui Nagle esiste. In generale, Nagle deve essere disabilitato solo per le connessioni interattive in cui i datagrammi di dimensioni inferiori a MTU devono essere forzati senza ritardi. vale a dire: per i trasferimenti di massa, vuoi quanti più dati possibile in ogni pacchetto.

hai messo a punto il tuo pacchetto riordinando la trebbia? Controllalo su tcp_reordering su / proc su Linux. Sui tubi lunghi, è comune un effetto multipath per causare la perdita di pacchetti falsi, la ritrasmissione e le diminuzioni di velocità inviate nel grafico. Causa anche molti duplicati di Ack, quindi vale la pena controllarli. Non dimenticare che devi sintonizzare entrambi i lati del tubo per avere buoni risultati e usare almeno un cubo. Un protocollo interattivo, come ftp, può danneggiare qualsiasi tcp per l'ottimizzazione di pipe lunghe che puoi fare. A meno che non si trasferiscano solo file di grandi dimensioni.

Quello che vedi mi sembra abbastanza normale, in base alla latenza che stai segnalando ai tuoi vari siti. La latenza ucciderà attraverso il throughput quasi ogni singola connessione, indipendentemente dalla larghezza di banda disponibile, molto rapidamente.

Silver Peak offre uno stimatore rapido e sporco per la velocità effettiva che ci si può aspettare di vedere con una determinata quantità di larghezza di banda un determinato livello di latenza qui: http://www.silver-peak.com/calculator/

Collega una connessione a 100 mbit con le latenze appropriate che stai vedendo e scoprirai che le tue velocità sono effettivamente abbinate (approssimativamente) a ciò che dovresti aspettarti di vedere.

Per quanto riguarda Windows che offre prestazioni peggiori rispetto a Linux, purtroppo non posso offrire buoni suggerimenti. Presumo che tu stia facendo un confronto mele-a-mele con hardware identico (schede di rete specifiche, in particolare)?