Frage Langsame Transfers über Distanz


Von unserem NY Datacenter haben Transfers zu weiter entfernten Standorten eine schlechte Leistung.

Mit dem Speed-Test zum Testen verschiedener Standorte können wir unseren 100-MBit-Uplink nach Boston und Philadelphia problemlos sättigen. Wenn ich Geschwindigkeitstest an der Westküste der USA oder in Europa verwende, sehe ich oft nur 9 Mbit / s.

Meine erste Reaktion ist, dass dies ein Fenster-Skalierungsproblem ist (Bandwidth Delay Product). Allerdings habe ich mich mit Linux-Kernelparametern auf einer Testmaschine an der Westküste eingestellt und iperf an den Punkt gebracht, an dem das Window so groß dimensioniert ist, dass es 100 MegaByte pro Sekunde unterstützt und trotzdem geringe Geschwindigkeiten hat (Verified in Capture). Ich habe auch versucht, den Nagle-Algorithmus zu deaktivieren.

Wir bekommen schlechte Leistung von Linux und Windows, aber es ist deutlich schlechter (1/3) die Geschwindigkeit mit Windows.

Die Form der Übertragung (ohne Nagle) ist:enter image description here

Der Dip um 10s hat ~ 100 Duplikate.

Die Form der Min-Fenster-Größe des Empfängers im Zeitverlauf ist:

enter image description here

Irgendwelche Ideen, wohin wir unseren Flaschenhals nähen sollen?

Einige Speed-Testergebnisse (Upload mit speedtest.net):

  • Philadelphia: 44 Mbit (Leute, die unsere Seite benutzen, benutzen den Rest ;-))
  • Miami: 15 Mbit
  • Dallas: 14 Mbit
  • San Jose: 9 Mbit
  • Berlin: 5 Mbit
  • Sydney: 2,9 Mbit

Noch mehr Daten:
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

Aktualisieren:

Mit Tall Jeff haben wir etwas tiefer in das Thema eingedrungen. Laut der TCPDump auf der Absender Seitlich senden die Pakete als 65k-Pakete über das Internet. Wenn wir uns die Depots auf der Empfängerseite anschauen, kommen sie fragmentiert wie erwartet.

So sieht der Paket-Dump auf der Senderseite aus:enter image description here

Was dann passiert, ist, dass der Sender denkt, dass er nur 64k-Pakete sendet, aber in Wirklichkeit, was den Empfänger betrifft, sendet er Bursts von Paketen. Das Endergebnis ist eine vermummte Überlastungskontrolle. Sie sehen, dass dies ein Diagramm der Paketlängen von Datenpaketen ist, die vom Absender gesendet werden:

enter image description here

Wer weiß, was der Sender davon halten könnte, dass es 64k MTU gibt? Vielleicht einige /proc, ethtool oder ifconfig parameter? (ifconfig zeigt die MTU ist 1500). Meine beste Vermutung ist momentan eine Hardwarebeschleunigung - aber ich bin mir nicht sicher, was genau.

Unterauftrag 2-2 IV:
Ich hatte nur einen Gedanken, da diese 64k-Pakete das DF-Bit gesetzt haben, vielleicht zersplittert mein Provider sie sowieso und vermasselt MSS Auto-Discovery! Oder vielleicht ist unsere Firewall falsch konfiguriert ...

Zusatz Edit 9.73.4 20-60:
Der Grund, warum ich die 64k-Pakete sehe, ist, weil das Segment-Offloading (tso und gso, siehe ethtool -K) eingeschaltet ist. Nachdem ich diese ausgeschaltet habe, sehe ich keine Verbesserungen in der Übertragungsgeschwindigkeit. Die Form ändert sich ein wenig und die Retransmits sind in kleineren Segmenten:enter image description here

Ich habe auch alle anderen Stausalgorithmen auf Linux ohne Verbesserung ausprobiert. Mein NY-Provider hat versucht, Dateien auf einen Test-FTP-Server in OR von der Einrichtung, in der wir uns befinden, hochzuladen und erhält die dreifache Geschwindigkeit.

Der angeforderte MTR-Bericht von NY nach 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

19
2018-06-08 15:51


Ursprung


ist Ihre schlechte Leistung unter Windows 2008 R2? - Jim B
Windows 2008 R2 ist schlimmer als Linux, aber mit Linux kann ich immer noch nur 20-30mbit ziehen. Ich habe alle Arten von Windows-Tuning versucht, insbesondere bei Sachen, die die Fensterskalierung beeinflussen. Aber meine Theorie ist, dass die Verbindung saugt, und Linux behandelt nur die sucky Verbindung ein bisschen besser. - Kyle Brandt♦
Meine erste Vermutung wäre eine schlechte / langsame Route auf einem der ISPs zwischen Ihrem Standort und der Westküste / Europa. - xeon
Da die AS-Pfade für Bereiche mit schlechter Leistung unterschiedlich sind, scheint es nicht so, als ob es sich um Upstream-Pfade handelt. - Kyle Brandt♦
Wenn Sie mit UDP keine guten Ergebnisse erzielen, dann hilft TCP sicherlich nicht (stellen Sie sicher, dass Sie die Geschwindigkeit lokal mit UDP verknüpfen können, sonst könnte Ihre iperf-Testhardware fehlerhaft sein). - Jed Daniels


Antworten:


Sicherzustellen, dass das TCP-Fenster sich weit genug öffnet, um das Bandbreitenverzögerungsprodukt abzudecken, wäre auch meine erste Vermutung gewesen. Unter der Annahme, dass dies richtig konfiguriert ist (und von beiden Enden unterstützt wird), würde ich als nächstes eine Paketverfolgung untersuchen, um sicherzustellen, dass das Fenster sich wirklich öffnet und dass einer der Hops in dem Pfad die Fensterskalierung nicht entfernt. Wenn das alles gut ist und Sie sicher sind, dass Sie nicht auf einen bandbreitenbeschränkten Hop im Pfad stoßen, ist die wahrscheinliche Ursache für Ihre Probleme zufällige Paketverluste. Diese Hypothese wird durch die Angabe der duplizierten ACKs unterstützt. (Doppelte ACKs sind im Allgemeinen ein direktes Ergebnis von verlorenen Daten). Beachten Sie außerdem, dass bei einem großen Bandbreite-Verzögerungsprodukt und daher einem großen offenen Schiebefenster sogar geringe Mengen zufälliger Paketabfälle den Gesamtdurchsatz der Verbindung erheblich beeinträchtigen können.

Seite Hinweis: Für Massen-Datenübertragungen über TCP und über eine Multi-Hop-WAN-Verbindung sollte Nagle nicht deaktiviert werden. Genau dieses Szenario ist der Grund, warum Nagle existiert. Im Allgemeinen muss Nagle nur für interaktive Verbindungen deaktiviert werden, bei denen Sub-MTU-große Datagramme ohne Verzögerung herausgedrückt werden müssen. zB: Für Massentransfers möchten Sie so viele Daten wie möglich in jedem Paket haben.


5
2018-06-08 22:43





Hast du deine Pake-Umsortierungsschwelle eingestellt? Überprüfen Sie es bei tcp_reordering unter / proc unter Linux. Bei langen Pipes ist es üblich, dass ein Multipath-Effekt zu einer falschen Paketverlusterkennung, erneuten Übertragung und zu Geschwindigkeitsverlusten führt, die Sie in Ihrem Diagramm gesendet haben. Es verursacht auch viele doppelte Acks, also lohnt es sich, überprüft zu werden. Vergessen Sie nicht, dass Sie beide Seiten der Pfeife stimmen müssen, um gute Ergebnisse zu erzielen und mindestens kubisch zu verwenden. Ein interaktives Protokoll, wie ftp, kann jeden TCP für eine lange Rohrleitungsoptimierung beschädigen, die Sie tun können. Es sei denn, Sie übertragen nur große Dateien.


1
2018-06-11 11:54





Was Sie sehen, sieht für mich ziemlich normal aus, basierend auf der Latenz, die Sie Ihren verschiedenen Websites melden. Die Latenz wird durch den Durchsatz fast jede einzelne Verbindung, unabhängig von der verfügbaren Bandbreite, sehr schnell morden.

Silver Peak bietet einen schnellen und dreckigen Schätzer für den Durchsatz, den Sie bei gegebener Bandbreite mit einer gegebenen Latenzzeit erwarten können: http://www.silver-peak.com/calculator/

Schließen Sie eine 100-Bit-Verbindung mit den entsprechenden Latenzen an, die Sie sehen, und Sie werden feststellen, dass Ihre Geschwindigkeiten tatsächlich (ungefähr) mit dem übereinstimmen, was Sie erwarten sollten.

Da Windows schlechter abschneidet als Linux, kann ich leider keine guten Vorschläge machen. Ich nehme an, Sie machen einen Apfel-zu-Äpfel-Vergleich mit identischer Hardware (speziell NICs)?


-2
2018-06-08 17:33



Ich sehe nicht, warum die Latenz den Durchsatz im Laufe der Zeit beeinflussen würde, wenn ein ausreichend großes Fenster vorhanden wäre, um das Bandbreitenverzögerungsprodukt unterzubringen. - Kyle Brandt♦
Es ist nur die Natur des Biests, wenn man mit einer einzigen Verbindung arbeitet. Wenn Sie mehrere gleichzeitige Verbindungen zu demselben Ziel starten, wird die Bandbreite an beiden Enden vorhanden sein, vorausgesetzt, dass genügend gleichzeitige Verbindungen vorhanden sind. Lies etwas davon routerjockey.com/2009/05/07/how-does-latency-effect-throughput - Layn
@Layn: Diese Formel in diesem Link ist, wie das Produkt Bandbreite Verzögerung berechnet. Angesichts einer ausreichend großen Fenstergröße sollte das keine Rolle spielen. TCP-Verbindungen von Ost nach West haben keine 9mbit eine Sekunde harte Begrenzung - das wäre albern. - Kyle Brandt♦
@Layn: Du solltest solche Aussagen mit ein bisschen Wissenschaft (oder Daten ...) wirklich unterstützen. Ich versichere Ihnen, dass Sie sich irren. Wir haben Niederlassungen auf der ganzen Welt und wir können beständig besser als das, was Sie als Beispiel geben. Ich habe gerade einen scp-Test von Montreal nach Buenos Aires (Latenz von 145ms) bei 28.8 Mbps gemacht. - DictatorBob
@Layn: Du solltest in der Lage sein, eine 100Mbps-Verbindung mit UDP zu erreichen, unabhängig von der Latenzzeit. - Jed Daniels