Methoden zum Testen der Leistung einer WAN-Verbindung


11

Wir haben zwei neue, unterschiedlich geroutete 1-Gbit / s-Ethernet-Verbindungen zwischen Standorten, die etwa 200 Meilen voneinander entfernt sind. Der 'Client' ist ein neuer, einigermaßen leistungsfähiger Computer (HP DL380 G6, zwei E56xx Xeons, 48 ​​GB DDR3, R1-Paar 300 GB 10krpm SAS-Festplatten, W2K8R2-x64), und der 'Server' ist ebenfalls ein ausreichend guter Computer (HP BL460c G6) , zwei E55xx Xeons, 72 GB, R1-Paar 146 GB 10-krpm-SAS-Festplatten, Dual-Port-Emulex-4-Gbit / s-FC-HBA, verbunden mit zwei Cisco MDS9509s, dann auf dediziertem HP EVA 8400 mit 128 x 450 GB, 15-krpm-FC-Festplatten, RHEL 5.3-x64).

Bei Verwendung von SFTP vom Client wird bei großen Dateien (> 2 GB) nur ein Durchsatz von ca. 40 KBit / s angezeigt. Wir haben Server-zu-anderen lokalen Server-Tests durchgeführt und sehen über die lokalen Switches (Cat 6509s) etwa 500 Mbit / s. Wir werden dasselbe auf der Client-Seite tun, aber das ist noch ein Tag oder so entfernt.

Welche anderen Testmethoden würden Sie verwenden, um den Linkanbietern zu beweisen, dass das Problem bei ihnen liegt?


Ich würde auch gerne eine Antwort auf diese Frage wissen. Wir bekommen unsere 100Mbit Mietleitung nächste Woche irgendwann installiert :)
Tom O'Connor

wie user37899 sagt - Ergebnisse wären willkommen.
pQd

Irgendwelche Updates? Ich bin gespannt, wie sich dieser entwickelt.
Kyle Brandt

Ich habe die Linkanbieter "ziemlich schlimm" verprügelt (ironischerweise sind sie Teil derselben Organisation, für die ich arbeite!) - sie sind noch nicht zu uns zurückgekehrt.
Chopper3

1
Ah okay, und übrigens, wenn Sie herausfinden können, warum ich 7 Stimmen für serverfault.com/questions/134467/… und 1 dafür bekomme , würde ich gerne wissen ;-)
Kyle Brandt

Antworten:


10

Tuning eines Elefanten:
Dies könnte eine Tuning erfordern, wahrscheinlich nicht das Problem hier, wie pQd sagt. Diese Art von Verbindung ist als "Long, Fat Pipe" oder Elefant bekannt (siehe RFC 1072 ). Da es sich um eine fette Gigabit-Pipe handelt, die über eine Distanz läuft (Distanz ist in diesem Fall wirklich Zeit / Latenz), muss das TCP-Empfangsfenster groß sein (Bilder siehe TCP / IP Illustrated Volume 1, Abschnitt TCP-Erweiterungen).

Um herauszufinden, wie das Empfangsfenster aussehen muss, berechnen Sie das Produkt für die Bandbreitenverzögerung:

Bandwidth * Delay = Product

Bei einer Latenz von 10 MS schätzt dieser Rechner , dass Sie ein Empfangsfenster von ca. 1,2 MByte wünschen. Wir können die Berechnung selbst mit der obigen Formel durchführen:

echo $(( (1000000.00/.01)/8  )) 
12500000

Daher möchten Sie möglicherweise einen Paketspeicherauszug ausführen, um festzustellen, ob die Skalierung des TCP- Fensters (die TCP-Erweiterung, die größere Fenster zulässt) richtig ist, um dies zu optimieren, sobald Sie das große Problem herausgefunden haben.

Fenstergebunden:
Wenn dies das Problem ist, dass Sie an eine Fenstergröße ohne Skalierung gebunden sind, würde ich die folgenden Ergebnisse erwarten, wenn keine Fensterskalierung vorhanden ist und unabhängig von der Rohrgröße eine Latenz von ca. 200 ms besteht:

Throughput = Recieve Window/Round Trip Time

So:

echo $(( 65536/.2 ))
327680 #Bytes/second

Um die Ergebnisse zu erhalten, die Sie sehen, müssen Sie nur nach der Latenz suchen. Dies wäre:

RTT = RWIN/Throughput

Also (für 40 kByte / s):

echo $(( 65536.0/40000.0 )) 
1.63 #Seconds of Latency

(Bitte überprüfen Sie meine Mathematik, und diese beinhalten natürlich nicht den gesamten Protokoll- / Header-Overhead.)


Du weißt, ich habe mich ein bisschen schuldig gefühlt, weil ich dich in der letzten Woche vorübergehend überholt habe, und der Grund dafür ist, wie verdammt gut deine Antworten sind - und BOOM! Sie verwenden sogar eine Shell, um Ihre Berechnungen durchzuführen, nicht die 1,5 MB Mac Calculator.app, die ich mache! :) Vielen Dank.
Chopper3

1
Sie haben auch gute Antworten, und ich mag es, dass ich jemanden habe, dem ich in der Nähe nahe stehe, der das Spiel ein wenig verbessert :-) Eine schnelle Google-Abfrage erinnert mich daran, dass Sie auch meine Fragen beantwortet haben: serverfault.com/questions/107263/ … . Ich schätze die aktiven Benutzer, die versuchen, diese Community zu verwirklichen, sehr. Aber danke für die Ergänzung!
Kyle Brandt

Ich auch, es gibt nichts, was ich mehr mag, als zu wissen, dass wir jemandem geholfen haben, der sich mit einem frustrierenden Problem allein fühlte - abgesehen von Käse natürlich. Das heißt, ich hasse es, wenn wir auch schlecht formulierte Fragen bekommen. Hast du meine Frage auf SO Podcast 82 gehört? habe auch ein kostenloses SF-T-Shirt dabei!
Chopper3

Ich höre mir die meisten Podcasts an, habe diese aber verpasst und werde sie mir noch einmal ansehen (wahrscheinlich dieses Wochenende).
Kyle Brandt

Entschuldigung für diesen pQd, ich habe Ihren Nick eigentlich immer als PDQ gelesen, wie in PDQ Bach: en.wikipedia.org/wiki/P._D._Q._Bach :-)
Kyle Brandt

6

40kbps sind sehr niedrig [bis zu dem Punkt, an dem ich fehlerhafte Medienkonverter / Duplex-Fehlanpassungen vermuten würde [aber Sie haben Gigabit, also gibt es keinen Platz für Halbduplex!] Usw.]. Es müssen Paketverluste oder sehr hoher Jitter auftreten.

iperf ist das erste Tool, das mir in den Sinn kommt, um den verfügbaren Durchsatz zu messen. an einer Seite laufen

iperf -s 

und auf der anderen Seite:

iperf -t 60 -c 10.11.12.13

Anschließend können Sie die Client / Server-Rollen austauschen, -d für Duplex usw. verwenden. Führen Sie vor Beginn des Tests mtr zwischen beiden Computern aus, um festzustellen, welche Latenz- / Paketverluste bei nicht verwendeten Verbindungen auftreten und wie sich diese während der Datenübertragung ändern.

Sie möchten sehen: sehr kleiner Jitter und keine Paketverluste, bis die Verbindung mit 90 Prozent ihrer Kapazität gesättigt ist.

iperf für * nix und win , lies hier und hier darüber.

mtr für * nix und gewinne .


Wir wissen, dass der Link aus 6 1000-Base-ZX-Links besteht, so dass durch all diese Wiederholungen zwangsläufig eine Latenz entsteht, aber trotzdem bin ich überrascht, wie niedrig er ist übrigens, ich hatte total vergessen, dass es existiert!
Chopper3

Bitte posten Sie Ihre Ergebnisse!
Der Unix-Hausmeister

1

Der Tracepath kann Ihnen Routingprobleme zwischen den beiden Standorten anzeigen.

iperf, ttcp und bwping können Ihnen nützliche Informationen geben.

Wissen Sie, wie dieser 1-GB-Link bereitgestellt wird? Überbrücken oder routen Sie diesen Link? Was ist Ihre SLA für den Link? Sie könnten von Ihrem Linkanbieter geprägt werden?

Wenn Sie nur 40 KBit / s haben, liegt ein ernstes Problem vor. Sind Sie sicher, dass es sich nicht um eine 1-MB-Verbindung handelt, sondern um eine 1-GB / s-Verbindung? Sie werden wahrscheinlich feststellen, dass die Geschwindigkeit des Links nicht so ist, wie Sie es denken :-)


Vielen Dank für Ihre Antwort. Es handelt sich um eine dedizierte Single-Mode-Glasfaserverbindung mit mehreren Segmenten. Es gibt überhaupt keine Formgebung, da es sich nur um L2 handelt. Oh, und ich hoffe, es handelt sich nicht um eine 1-Mbit / s-Verbindung, nicht um das Geld, das sie kostet :)
Chopper3

1
Wenn Sie eine Verbindung zu Ihrem LAN herstellen, dh nirgendwo weiterleiten, verschwenden Netzwerk-Broadcasts die Verbindungskapazität. Bei 1 GB ist dies ein kleiner Bruchteil, aber ein sich schlecht verhaltender Netzwerkdienst kann die Verbindung reduzieren. Ich nehme an, diese Brücken liegen außerhalb Ihrer Kontrolle. Diese Switches sind möglicherweise überlastet oder weisen eine sehr hohe Latenz auf. Hohe Latenz bedeutet geringe Bandbreite.
Der Unix-Hausmeister

@ user37899 - Eine hohe Latenz muss nicht mit einer geringen Bandbreite verbunden sein, sondern erfordert eine Optimierung. Wie viel Latenz können Sie auf 200 Meilen erreichen - wenn alles in Ordnung ist - nicht mehr als 3-10 ms. Arp [oder andere] Sendungen über die Gigabit-Verbindung machen wahrscheinlich nur einen sehr kleinen Teil der gesamten verfügbaren Kapazität aus.
pQd

1
Wenn Sie Netzwerksendungen haben, die so stark sind, dass die Leistung der Verbindung beeinträchtigt wird, hätten Sie vermutlich lange vor dem Eingang dieser neuen Leitung interne Leistungsprobleme gehabt und dies auch bemerkt.
Joeqwerty

@pQd Ich sprach tatsächlich über einen Broadcast-Sturm.
Der Unix-Hausmeister

0

RFC 2544 oder Y.156sam

Hierbei handelt es sich um Netzwerktests, die durchgeführt werden, um die SLA durch den Netzbetreiber nachzuweisen. IPERF und dergleichen sind keine überprüfbaren Netzwerktestmethoden.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.