距離を渡る遅い転送

19

ニューヨークのデータセンターから、遠く離れた場所への転送のパフォーマンスが低下しています。

速度テストを使用してさまざまな場所をテストすると、ボストンおよびフィラデルフィアへの100メガビットアップリンクを簡単に飽和させることができます。米国またはヨーロッパの西海岸の場所に速度テストを使用すると、約9メガビット/秒しか表示されないことがよくあります。

私の最初の反応は、これがウィンドウスケーリングの問題であることです（帯域幅遅延積）。ただし、西海岸のテストマシンでLinuxカーネルパラメーターを調整し、1秒あたり100メガバイトをサポートするのに十分なサイズにウィンドウがサイズ変更されるまでiperfを使用しましたが、速度はまだ低速です（Captureで検証済み）。また、Nagleアルゴリズムを無効にしようとしました。

LinuxとWindowsの両方からパフォーマンスは低下しますが、Windowsを使用した場合の速度は大幅に低下します（1/3）。

転送の形状（Nagleなし）は次のとおりです。ここに画像の説明を入力してください

10秒前後のDipには、重複する〜100個のAckがあります。

時間の経過に伴う受信機の最小ウィンドウサイズの形状は次のとおりです。

ここに画像の説明を入力してください

ボトルネックを突き止めるために次にどこに行くべきかについてのアイデアはありますか？

速度テストの結果（speedtest.netを使用してアップロード）：

  • フィラデルフィア：44メガビット（このサイトを使用している人々は残りを使用しています;-)）
  • マイアミ：15メガビット
  • ダラス：14メガビット
  • サンノゼ：9メガビット
  • ベルリン：5メガビット
  • シドニー：2.9 mbit

さらに多くのデータ：
マイアミ：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

サンノゼ：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

フィリー：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

ベルリン：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

更新：

トールジェフとこれを少し深く掘り下げると、奇妙なことがわかりました。送信側の TCPDumpによると、パケットはインターネット上で 65kパケットとして送信されます。受信側のダンプを見ると、予想どおり断片化された状態で到着します。

送信側でのパケットダンプは次のとおりです。ここに画像の説明を入力してください

その場合、送信者は64kパケットを送信しているだけであると考えますが、実際には、受信者に関する限り、パケットのバーストを送信しています。最終結果は混雑制御を台無しにします。これは、送信者が送信しているデータパケットのパケット長のグラフです。

ここに画像の説明を入力してください

Senderに64k MTUがあると思わせる原因は何ですか？たぶんいくつか/proc、ethtoolまたはifconfig parameter？（ifconfigMTUが1500であることを示します）。現時点での最良の推測は、ある種のハードウェアアクセラレーションですが、具体的にはわかりません。

Subedit 2-2 IV：
これらの64kパケットにはDFビットが設定されているので、考えてみましたが、おそらく私のプロバイダーはそれらを断片化し、MSS自動検出を台無しにしています！または、ファイアウォールが正しく構成されていない可能性があります...

付属編集9.73.4 20-60：
64kパケットが表示される理由は、セグメントオフロード（tsoおよびgso、ethtool -Kを参照）がオンになっているためです。これらをオフにした後、転送速度の改善は見られません。形状が少し変化し、再送信はより小さなセグメントになります。ここに画像の説明を入力してください

また、Linuxですべての異なる輻輳アルゴリズムを改善することなく試しました。私のNYプロバイダーは、私たちがいる施設からORのテストFTPサーバーにファイルをアップロードしようとしましたが、速度は3倍になっています。

NYからORへの要求されたMTRレポート：

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
networking  tcp 
— カイル・ブラント
ソース
Windows 2008 r2でパフォーマンスが低下していますか？
— ジムB
Windows 2008 R2はLinuxよりも悪いですが、Linuxではまだ20〜30メガビットしかプルできません。私はあらゆる種類のWindowsのチューニングを試みました。特に、ウィンドウのスケーリングに影響を与えるものについてです。しかし、私の理論では、接続はひどいものであり、Linuxはそのひどい接続を少しだけうまく処理します。
— カイルブラント
2
私の最初の推測は、あなたの場所と西海岸/ヨーロッパの間のISPの1つの悪い/遅いルートでしょう。
— xeon
1
ASパスはパフォーマンスの低い領域では異なるため、途中のアップストリームであるようには見えません。
— カイルブラント
1
UDPで良好な結果が得られない場合、TCPは確かに役に立ちません（もちろん、UDPでローカルにリンク速度まで実行できることを確認してください。そうしないと、iperfテストハードウェアに欠陥がある可能性があります）。
— ジェドダニエルズ

回答:

5

TCPウィンドウが帯域幅遅延製品をカバーするのに十分な大きさで開いていることを確認することも、私の最初の推測でした。それが適切に構成されている（そして両端でサポートされている）と仮定すると、次にパケットトレースを調べて、ウィンドウが実際に開いており、パスのホップの1つがウィンドウスケーリングを除去していないことを確認します。それがすべて良好で、パス内の帯域幅が制限されたホップに突っ込んでいないことが確実な場合、問題の原因はランダムなパケットドロップです。この仮説は、あなたが言及した重複したACKの表示によって裏付けられています。（重複したACKは一般にデータの損失の直接的な結果です）。また、帯域幅遅延積が大きいため、スライディングウィンドウが大きく開いていることに注意してください。

サイド注：TCP経由のバルクデータ転送の場合とマルチホップWAN接続経由で、無効ネーグルに必要か、理由があってはなりません。実際、その正確なシナリオがNagleの存在理由です。一般的に、ネーグルは、サブMTUは、データグラムが遅延なく押し出さする必要がある大きさのインタラクティブな接続のために無効にする必要があります。例：バルク転送では、各パケットにできるだけ多くのデータが必要です。

— トールジェフ
ソース
1

パケットの並べ替えのしきい値を調整しましたか？Linux上での/ proc tcp_reorderingでそれを確認してください。長いパイプでは、一般的にマルチパス効果により、誤ったパケット損失の検出、再送信、およびチャートで送信した速度の低下が発生します。チェックする価値がある、それはので、それは、あまりにも重複ACKの多くの原因となります。あなたがチューンパイプの両側が良いresulsや用途に立方少なくともを持っている必要があります忘れないでください。FTPなどのインタラクティブなプロトコルは、あなたが行うことができます長いパイプの最適化のための任意のTCPを害することができます。大きなファイルのみを転送する場合を除きます。

— nmenezes
ソース
-2

さまざまなサイトに報告している待ち時間に基づいて、表示されているものは私にはかなり普通に見えます。遅延は、利用可能な帯域幅に関係なく、ほとんどすべての単一接続のスループットを非常に迅速に殺します。

Silver Peakは、一定量の帯域幅と一定レベルのレイテンシで見込めるスループットの迅速で汚い推定値を提供します：http : //www.silver-peak.com/calculator/

表示されている適切なレイテンシーで100メガビットの接続を接続すると、速度が実際に（およそ）表示されるはずのものと一致していることがわかります。

Linuxに比べてパフォーマンスが低いWindowsについては、残念ながらそこに良い提案をすることはできません。同一のハードウェア（具体的にはNIC）を使用して、りんごごとの比較を行っていると思いますか？

— レイン
ソース
1
帯域幅遅延製品を収容するのに十分な大きさのウィンドウがある場合、レイテンシが時間の経過とともにスループットに影響する理由はわかりません。
— カイルブラント
単一の接続で動作するとき、それはただの獣の性質です。同じ宛先への複数の同時接続を開始する場合、十分な同時接続があれば、帯域幅が両端に存在する場合はそれを埋めます。routerjockey.com/2009/05/07/how-does-latency-effect-throughputを
— レイン
2
@Layn：そのリンクの式は、帯域幅遅延積の計算方法です。十分な大きさのウィンドウサイズがあれば、それは問題ではありません。東海岸から西海岸へのTCP接続には、9mbitの2番目のハード制限がありません。これはばかげています。
— カイルブラント
1
@Layn：ちょっとした科学（またはデータ）を使って、そのようなステートメントをバックアップする必要があります。私はあなたが間違っていることを保証します。世界中にオフィスがあり、例として挙げたものより一貫して良い結果を出すことができます。28.8 mbpsでモントリオールからブエノスアイレスまでのscpテスト（レイテンシ145ミリ秒）を行いました。
— 独裁者
2
@Layn：レイテンシーに関係なく、UDPで100Mbpsリンクを飽和状態に近づけることができるはずです。そのため、引数は実際には飛びません。
— ジェドダニエルズ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.