iPerf - Aussagekraft und Download-Richtung

[Jirka]

Hallo,

irgendwie komme ich mit dem iPerf im LANCOM noch nicht wirklich zurecht.

1. Frage: Was haben die Messergebnisse überhaupt für eine Aussagekraft, wie kann ich die bewerten? Beispiel: Ich habe an meinem 1781EF+ einen L-322-R2 hängen (beides 9.24.0252; der AP hängt normal an einer PoE-Switch, die ich jetzt mal vorsichtshalber rausgenommen habe, der AP hängt also direkt am 1781EF+, also mit Gigabit Ethernet (FD1000B-TX)).

Code: Alles auswählen

> iperf -c 10.10.10.5 -d -p 5001
[Iperf-TCP-Client|64446] Connecting to server...
[Iperf-TCP-Client|64446] Connection accepted by 10.10.10.5:5001
[Iperf-TCP-Server|64447] Now listening on port 5001
[Iperf-TCP-Server|64447] Connection accepted from 10.10.10.5:10794
[Iperf-TCP-Client|64446] Connection closed actively
[Iperf-TCP-Client|64446] Sent 51775316 bytes within 10.000s -> 41.420 Mbit/s
[Iperf-TCP-Server|64447] Connection closed passively
[Iperf-TCP-Server|64447] Received 51093492 bytes within 10.154s -> 40.254 Mbit/s
[Iperf-TCP-Server|64447] Not longer listening on port 5001

Im sequentiellem bidirektionalem Modus sieht es etwas besser aus:

Code: Alles auswählen

> iperf -c 10.10.10.5 -r -p 5001
[Iperf-TCP-Client|64461] Connecting to server...
[Iperf-TCP-Client|64461] Connection accepted by 10.10.10.5:5001
[Iperf-TCP-Client|64461] Connection closed actively
[Iperf-TCP-Client|64461] Sent 111163736 bytes within 10.000s -> 88.930 Mbit/s
[Iperf-TCP-Server|64462] Now listening on port 5001
[Iperf-TCP-Server|64462] Connection accepted from 10.10.10.5:11220
[Iperf-TCP-Server|64462] Connection closed passively
[Iperf-TCP-Server|64462] Received 105769036 bytes within 10.308s -> 82.086 Mbit/s
[Iperf-TCP-Server|64462] Not longer listening on port 5001

Aber immer noch enttäuschend. 90 Mbit/s ist also Ende der Fahnenstange? Bei einem AP, der 150 Mbit/s pro Interface übertragen könnte? Ok, sagen wir 100 Mbit/s. Das wären dann aber 100 Mbit/s up und down bzw. 200 Mbit up oder down. Ich muss also testen, ob der Weg vom 1781EF+ zum L-322-R2 auch 100 Mbit/s symmetrisch durchlässt oder 200 Mbit/s in nur eine Richtung, damit ich beurteilen kann, ob der AP optimal angebunden ist. Die Messung zum L-322-R2 endet aber bei den obigen Werten, obwohl doch eigentlich in Wirklichkeit mehr geht? Oder gehen sollte? Warum? Ja weil der L-322-R2 mit 100 % CPU-Auslastung völlig lahmgelegt ist. Also entweder ist iPerf jetzt irgendwie nicht performant genug implementiert worden, oder ich sollte mal einen echten Durchsatztest machen. Aber so nützt mir das doch jetzt nichts, oder mache ich was falsch? Oder muss ich an die Stelle einen performanteren LANCOM hinstellen für die Messung und anschließend wieder den L-322-R2 anschließen, aber das ist doch irgendwo sinnfrei?!

Ich habe noch ein paar andere Tests gemacht, zum Beispiel Client und Server vertauscht -> kein Unterschied. Dann habe ich einen L-452 gegen einen 1781-4G getestet, da ist der 1781-4G dann das Nadelöhr. Der 1781-4G schafft doch aber 100 Mbit/s Routing-Performance, wieso ist dann bei 80 Mbit/s (sequentiell) im iPerf-Speedtest Schluss? Dann habe ich hier einen 9100+ gegen einen 1781VA antreten lassen. Der 9100+ geht dabei auf satte 50 % CPU-Last, der arme 1781VA dabei natürlich auf 100 %. Raus kommen aber trotzdem sequentiell max. 375 Mbit/s, das ist auch unter der Routing-Performance des 1781VA. Irgendwie kann ich mir nicht vorstellen, dass iPerf jetzt performancefressender ist, als Routing. Ich meine der Router braucht bei iPerf die Pakete doch nur anzunehmen, zu zählen, vielleicht noch auf die Größe zu achten und dann ab damit in die Mülltonne.

2. Frage: Wie kriege ich es hin, dass ich einen parallelen oder sequentiellen bidirektionalen Modus zu einem öffentlichen iPerf-Server realisiere? Also auf gut Deutsch: Ich will testen, wie die Downloadgeschwindigkeit des Internetzugangs ist. Ich stelle mich vermutlich zu doof an, oder geht das so gar nicht?:

Code: Alles auswählen

iperf -c speedtest.serverius.net -d -p 5002

Mit

Code: Alles auswählen

iperf -c <mein-am-schnellsten-angebundener-LANCOM> -d

funktioniert es, aber ich weiß ja nicht, ob der LANCOM im Upload gerade noch Kapazitäten frei hat. Bei obigem Server ist das anzunehmen. (Serverliste: https://iperf.fr/iperf-servers.php)

Vielen Dank und viele Grüße,
Jirka

[alf29]

IPerf belastet die CPU im LANCOM deutlich mehr als einfaches Bridging im AP-Modus oder auch das Routen von Paketen, weil in dieser Betriebsart das LANCOM die Verbindung terminiert und die Pakete deutlich mehr Layer auf dem LCOS durchlaufen müssen. Gerade das TCP ist recht CPU-intensiv, versuche einmal IPerf mit UDP anstelle von TCP zu nutzen.

Gruß Alfred

[Jirka]

Hallo Alfred,

vielen Dank für die Info, auch wenn ich das echt krass finde, dass es so ist.
Mit UDP schaue ich mir heute Abend dann mal an.

Viele Grüße,
Jirka

[alf29]

Moin,

ehrlich gesagt: ich hatte seinerzeit auch Bedenken geäußert, einen IPerf-Client ins LCOS zu integrieren, aber man wollte es halt so. Das Problem mit TCP ist, daß im Gegensatz zu Bridging/Routing und auch wohl IPerf über UDP die Daten bzw. Pakete segmentiert und Richtung Applikation wieder zu einem Stream zusammengefügt werden, und das bedingt im TCP ein Umkopieren der Nutzdaten. Umkopieren der Daten tut aber besonders dem "kleinen" 8314 mit seinen kleinen Caches sehr weh. Solange das TCP nur für SSH und ein paar HTTP(S)-Zugriffe genutzt wird, fällt das nicht wirklich auf.

Gruß Alfred

[Dr.Einstein]

Hey Alfred,

wenn man z.B. einfach einen ADSL oder auch VDSL Anschluss messen will, ist die Funktion doch top. Man kann nachweisen, dass die versprochene Übertragungsrate geliefert wird. Das ein GBit Interface nicht simuliert werden kann mit einer kleinen CPU sollte bekannt sein und würd auch auf jedem LANUpdate erwähnt.

Gruß Dr.Einstein

[alf29]

Moin,

Ja, bei einem ADSL-Router, dessen ADSL-Interface maximal 16 MBit macht, "paßt" das auch für einen Router mit der kleinen CPU. Bei einem 11n-WLAN-AP, dessen primäre Aufgabe aber nun einmal ist, Pakete zwischen WLAN und LAN hin- und herzuschieben, und der das auch mit der kleinen Freescale-CPU auf Layer 2 mit gut 130 MBit schafft, paßt das irgendwie nicht mehr zusammen...

Daß das auf einem LANupdate erwähnt wird, kann ich mir vorstellen, aber was ist mit den 90% Kunden, die nie bei einem LANupdate waren und nur das Handbuch haben...

Gruß Alfred

[Jirka]

Hallo Alfred, hallo Dr. Einstein,

ehrlich gesagt: ich hatte seinerzeit auch Bedenken geäußert, einen IPerf-Client ins LCOS zu integrieren

ich finde das prinzipiell auch nicht schlecht, nur steht nirgends, wie man damit umzugehen hat oder wo die Grenzen dieser Funktionalität sind. (Ich hoffe die Aussage stimmt, ich habe nämlich auch nicht wirklich danach gesucht.)
Gibt es da vielleicht ein Techpaper zu?

wenn man z.B. einfach einen ADSL oder auch VDSL Anschluss messen will, ist die Funktion doch top.

Solange man den VDSL an einem VDSL-LANCOM hat ja. An einem 1781EF sieht es da schon schlechter aus.

Aber wo Du gerade davon schreibst, kannst Du mir nicht eine Antwort auf meine eingangs gestellte zweite Frage geben? Oder habt Ihr eigene Server gegen die Du testest?

Dass ein GBit Interface nicht simuliert werden kann mit einer kleinen CPU, sollte bekannt sein

Also mir war es das nicht, jedenfalls nicht bis heute.

und wird auch auf jedem LANupdate erwähnt.

Dann sollte ich da vielleicht doch mal hingehen? Bisher habe ich das immer für überflüssig gehalten. Du kannst mir ja mal Bescheid geben, wenn Du das nächste Mal hingehst, dann könnte man sich bei der Gelegenheit endlich mal persönlich kennenlernen.

Vielen Dank und viele Grüße,
Jirka

[Jirka]

Hallo Alfred,

Bei einem 11n-WLAN-AP, dessen primäre Aufgabe aber nun einmal ist, Pakete zwischen WLAN und LAN hin- und herzuschieben, und der das auch mit der kleinen Freescale-CPU auf Layer 2 mit gut 130 MBit schafft, paßt das irgendwie nicht mehr zusammen...

genau das ist mein Problem...
Ich habe mal eine P2P-Strecke durchgetestet (bestehend aus zwei L-322 (R1)), etwas über 50 Mbit/s sind bei rausgekommen - ich weiß aber jetzt nicht, ob das jetzt real ist, weil die CPU-Last bei 98 % lag.
Hier heißt es:

LANCOM-Geräte beinhalten eine iPerf2-kompatible Funktion zur Messung der Netzwerkperformance direkt zwischen den Netzwerkzugangspunkten (z. B. Router, VPN-Gateway, AP). Damit vereinfacht sich die Messung z. B. des Datendurchsatzes über WAN- oder WLAN-Point-to-Point-Verbindungen.

Daraus schließe ich, dass ich auch P2P-Verbindungen testen kann oder vom Router zum AP.
Vermutlich hätte es eines zusätzlichen proprietären, nicht so CPU-lastigen Speedtests bedarft, um zwischen LANCOMs besser messen zu können. Da hätte ich auch auf iPerf-Kompatibilität verzichtet, ist zwar vielleicht ganz nett, aber wenn man erst mal ein paar LANCOMs hat, dann kann man darauf ohne Probleme verzichten. Bringt ja anscheinend sowieso nur für die Upload-Richtung was, sofern meine zweite Frage niemand beantworten kann.

Daß das auf einem LANupdate erwähnt wird, kann ich mir vorstellen, aber was ist mit den 90% Kunden, die nie bei einem LANupdate waren und nur das Handbuch haben...

Und ich dachte schon, ich gehöre schon wieder nicht zum Mainstream, wenn ich da nicht hin gehe... Danke, dass auch jemand an die erwähnten 90 % denkt...

Vielen Dank und viele Grüße,
Jirka

[Dr.Einstein]

Hey Jirka,

Solange man den VDSL an einem VDSL-LANCOM hat ja. An einem 1781EF sieht es da schon schlechter aus.

Dagegen sieht's an einem 1781EF+ schon wieder besser aus. Und selbst bei WLAN APs kann ich 50% der Fälle abdecken, wenn nicht sogar mehr. z.B. die ganzen Hotels, die von uns betreut werden, da wollen die Gäste ins INet. Ich kann dann schön mich auf den hintersten AP schalten inkl aller Funkbrücken und schauen, ob z.B. 20 Mbit/s durchkommen könnten. Klar, ne 300 Mbit/s Funkbrücke wird da nix.

Aber wo Du gerade davon schreibst, kannst Du mir nicht eine Antwort auf meine eingangs gestellte zweite Frage geben? Oder habt Ihr eigene Server gegen die Du testest?

Bei uns standen noch nen paar ungenutzte 9100+ an einer 1 Gbit/s Leitung rum. Erfüllt sein Zweck. Server wäre wieder extra Geld, extra "Wartung" etc.

Dann sollte ich da vielleicht doch mal hingehen? Bisher habe ich das immer für überflüssig gehalten.

Ehrlich gesagt glaube ich, dass das nix für dich ist. Du wirst dich zu 90% der Zeit langweiligen, weil du alles kennst und hier im Forum deine Infos von Entwicklern beziehst. Und ich denke, zukünftige Lancom Modelle / LCOS Features wie damals BGP etc. interessieren dich nicht direkt.

Gruß Dr.Einstein

[GrandDixence]

Für aussagekräftige IPerf(3)-Messungen lässt man die Finger von dem im LANCOM-Gerät enthaltenen IPerf(2).

Für P2P-Strecken installiert man am besten auf zwei Rechnern einen IPerf3-Client und einen IPerf3-Server. Und misst die P2P-Strecke zwischen diesen beiden Rechnern aus:

https://iperf.fr/

Für die Ausmessung des Internetanschluss verwendet man am besten einen eigenen, leistungsfähigen IPerf3-Server:

Aussagekräftig sind vor allem die Paketverlustraten der UDP-Messungen. Bei den UDP-Messungen ist darauf zu achten, dass die IP-Pakete nicht fragmentiert werden. In der Default-Einstellung verwendet IPerf3 für UDP-Messungen eine UDP-Paketgrösse von 8 Kilobyte, was zu fragmentierten IP-Pakete führt.

https://iperf.fr/iperf-doc.php#3doc

Fragmentierte IP-Pakete führen zu Performance-Verluste und können die UDP-Messungen verfälschen. Siehe auch:

http://www.lancom-forum.de/aktuelle-lan ... tml#p90338

[Jirka]

Hallo Dr. Einstein,

Dagegen sieht's an einem 1781EF+ schon wieder besser aus.

na definitiv.
So nach und nach ist mir jetzt ja auch klar, was ich da für ein Werkzeug habe und was ich damit machen kann und was nicht. Dir hat das am Anfang vermutlich jemand gesagt (z. B. auf dem LANupdate). Mir aber nicht. Und nachdem ich das so gelesen/überflogen hatte und das eigentlich schon immer mal ausprobieren wollte, nur nie richtig Zeit dafür da war, kam jetzt eines zum anderen und nun wollte und musste ich das mal einsetzen. Aber so wie ich mir das nach den Beschreibungen gedacht hatte, funktioniert es nicht. Und da war ich zugegebenermaßen erst mal enttäuscht. Ich meine ich habe ja gleich gemerkt, was da Sache war, ein Blick auf die CPU-Last und alles war klar. Aber komisch war's trotzdem noch (und ist es auch immer noch). Hat ja auch nie was einer von den Experten hier im Forum zu gesagt. Die Funktionalität ist ja nun schon ein Weilchen drin, aber so richtig angeschaut scheint sich das ja noch niemand zu haben - gut, von Dir und GrandDixence jetzt abgesehen.

Und selbst bei WLAN APs kann ich 50% der Fälle abdecken, wenn nicht sogar mehr. z.B. die ganzen Hotels, die von uns betreut werden, da wollen die Gäste ins INet. Ich kann dann schön mich auf den hintersten AP schalten inkl aller Funkbrücken und schauen, ob z.B. 20 Mbit/s durchkommen könnten. Klar, ne 300 Mbit/s Funkbrücke wird da nix.

Genau. Ich habe allerdings den Anspruch dass da 50 Mbit/s schon durchkommen müssen, sonst habe ich irgendwas falsch gemacht.

Bei uns standen noch nen paar ungenutzte 9100+ an einer 1 Gbit/s Leitung rum. Erfüllt sein Zweck. Server wäre wieder extra Geld, extra "Wartung" etc.

Ah ja, wie ich vermutet habe. Den 9100+ habe ich hier auch noch stehen - nur an der Gbit-Leitung mangelt es
Das bedeutet also, Du hast auch keine Antwort auf meine Frage und Du bist dem Problem (?) einfach elegant ausgewichen. Ich kann es nur leider nicht ganz so elegant.

Und ich denke, zukünftige Lancom Modelle / LCOS Features wie damals BGP etc. interessieren dich nicht direkt.

Klar, BGP interessiert mich jetzt echt nicht. Aber neue Modelle, das ist schon sehr interessant. Als seinerzeit noch das LANCOM-Forumstreffen war, bekam man da Infos über die geplanten Modelle für die kommenden 12 Monate - das war richtig Klasse. Bei der letzten Veranstaltung waren es jedoch nur noch knapp 6 Monate. Und nun ist schon lange nichts mehr gewesen und wird vermutlich auch so schnell nicht. Wenn ich z. B. vor einem Jahr schon von dem virtuellen LANCOM-Router gewusst hätte, hätte ich vermutlich verhindern können, dass ein Systemhaus sich einen virtuellen MikroTik-Router angeschafft hätte und anschließend noch viele "echte" MikroTiks dazu... Na ja, dass es bei LANCOM kein VPN-Bonding gibt, spielte da leider auch noch mit rein. Aber besser planen kann man schon, wenn man weiß was kommt und wo die Richtung hingeht und ob man sowas schon mal anbieten/ansprechen kann.

Hallo GrandDixence,

vielen Dank für Deine total fundierten Darlegungen hier, aber das geht mir ein wenig an meiner Frage vorbei, deswegen nachfolgend ein paar kritische Bemerkungen.

Für aussagekräftige IPerf(3)-Messungen lässt man die Finger von dem im LANCOM-Gerät enthaltenen IPerf(2).

das mag jetzt zwar alles richtig sein, war aber nicht meine Frage. Meine Frage ist definitiv, was kann ich mit dem LANCOM iPerf machen und was nicht und wie kann ich es machen.

Für P2P-Strecken installiert man am besten auf zwei Rechnern einen IPerf3-Client und einen IPerf3-Server. Und misst die P2P-Strecke zwischen diesen beiden Rechnern aus

Auch das mag für die professionelle Messung perfekt sein, bringt mich aber nicht weiter. Um das so zu machen, müsste ich erst mal vor Ort hinfahren, alleine das ist teilweise gar nicht mal eben machbar. Ich muss mit der Netzwerktechnik, die vor Ort installiert ist, remote versuchen rauszubekommen, wo das Problem ist. Oder schauen, ob die derzeitigen Kapazitäten reichen, oder ob das erweitert werden muss. Dein Testszenario kann ich hier auf dem Schreibtisch aufstellen oder auch bei Erstinstallation zur Anwendung bringen, aber mir ging es jetzt eben gerade darum zu schauen, ob sowas eben auch kostengünstiger geht, also z. B. mit den LANCOMs, die da eh schon überall verteilt sind. Das habe ich mir jetzt zwar auch besser vorgestellt, aber man muss nehmen, was man hat...

Für die Ausmessung des Internetanschluss verwendet man am besten einen öffentlichen IPerf3-Server:
https://iperf.fr/iperf-servers.php

Genau. Hatte ich oben ja schon geschrieben. Wenn Du mir jetzt noch sagen kannst, wie ich die mit einem LANCOM-Router anspreche, so dass ich die Downloadrate des Anschlusses, an dem der LANCOM-Router hängt, prüfen kann, dann bekommst eine Flasche Wein.
Ich habe von iPerf jetzt nicht so die Ahnung, wie Du. Ist denn iPerf3 nicht abwärtskompatibel zu iPerf2 (LANCOM)?

Vielen Dank und viele Grüße,
Jirka

[GrandDixence]

Meine Frage ist definitiv, was kann ich mit dem LANCOM iPerf machen und was nicht und wie kann ich es machen.

Wie bereits einige Vorredner mitgeteilt haben, eignet sich der LANCOM-interne IPerf2 für Messungen mit einer Datenübertragungsrate bis maximal 30 MBit/s. Wenn IPerf-Messungen mit höheren Datenübertragungsraten durchgeführt werden sollen, ist die CPU der meisten LANCOM-Geräte einfach zu langsam.

http://lancom-wiki.de/index.php?title=L ... er%C3%A4te

Für IPerf-Messungen mit Datenübertragungsraten > 30 MBit/s ist zwingend eine leistungsfähige CPU für den IPerf-Client und IPerf-Server einzusetzen. Ansonsten frisst die Anwendung IPerf2 der "IP Router"-Anwendung von LCOS die CPU-Rechenzeit auf dem LANCOM-Gerät weg, was zu Verfälschungen der IPerf-Messung führt (Motto: "Wer misst, misst Mist"). Siehe auch das LANCOM Techpaper "Routing Performance":

https://www.lancom-systems.de/fileadmin ... .10-DE.pdf

[GrandDixence]

Einer der Faktoren, welcher Einfluss auf die Kanalkapazität bzw. maximale Datenübertragungsrate einer Datenverbindung hat, ist die Paketverlustrate:

https://de.wikipedia.org/wiki/Paketverlustrate

https://de.wikipedia.org/wiki/Paketverlust

Ist die Paketverlustrate zu hoch, verkleinert TCP das TCP-Fenster (TCP Window Size), was die verwendete Datenübertragungsrate reduziert:

https://en.wikipedia.org/wiki/TCP_window_scale_option

Für die Fehlersuche einer Datenverbindung ist die Paketverlustrate der UDP-Messungen (Lost Datagrams) von IPerf aussagekräftiger als die Messung der maximalen Datenübertragungsrate mit TCP. Als Faustregel gilt:

Bitfehlerrate < 1 % => Datenverbindung/Leitung in Ordnung
Bitfehlerrate > 1 % => Datenverbindung/Leitung gestört

Wichtig: Für die IPerf-Messung muss die Datenverbindung/Leitung unbelastet sein. Die UDP-Paketgrösse ist so zu wählen, dass keine IP-Pakete fragmentiert werden. Und die Datenübertragungsrate darf in keiner Netzwerkkomponente einen QoS-Mechanismus aktivieren, welcher IP-Pakete verwirft.

Als Beispiel ist eine Paketverlustrate-Messung mit UDP unter:

http://www.lancom-forum.de/aktuelle-lan ... tml#p90338

abgebildet. Im abgebildeten Beispiel wird ein VoIP-Telefongespräch mit dem Audio Codec G.711 simuliert.

[Jirka]

Hallo GrandDixence,

auf die Frage, für deren Lösung ich inzwischen eine Flasche Wein ausgelobt habe, hast Du also auch keine Antwort?

Wie bereits einige Vorredner mitgeteilt haben, eignet sich der LANCOM-interne IPerf2 für Messungen mit einer Datenübertragungsrate bis maximal 30 MBit/s.

Also das sagst Du jetzt. So viele Vorredner waren hier ja nun nicht. Alfred hat lediglich Bedenken geäußert, Dr. Einstein hat gar von VDSL gesprochen, was ja üblicherweise so 50 bis 100 Mbit/s sind. Bleibe noch ich mit meinen Äußerungen, die aber bisher nicht in Stein gemeißelt sind und eher der Frage "Was mache ich falsch?" zuzuordnen sind.
Nachdem, was ich jetzt mittlerweile weiß, kann man gut und gerne 100 Mbit/s durchmessen (wenn man denn eine Gegenstelle hat), z. B. mit dem 1781VA, dem von mir in der jüngeren Vergangenheit am meisten verbauten Router. Und wenn man sequentiell misst, dann sind 50 Mbit/s auch mit den alten Geräten drin. Und wenn man 100 Mbit/s mit den alten Geräten messen muss, dann geht das mit UDP auch.

Ansonsten frisst die Anwendung IPerf2 der "IP Router"-Anwendung von LCOS die CPU-Rechenzeit auf dem LANCOM-Gerät weg,

Das iPerf terminiert meiner Ansicht nach im LANCOM, da wird also nicht mehr geroutet.

was zu Verfälschungen der IPerf-Messung führt (Motto: "Wer misst, misst Mist"). Siehe auch das LANCOM Techpaper "Routing Performance":
https://www.lancom-systems.de/fileadmin ... .10-DE.pdf

Welche Stelle meinst Du in dem Dokument genau? Ich wüsste jetzt nicht, was da stehen soll, was diese Aussage belegt.

Vielen Dank und viele Grüße,
Jirka

[Dr.Einstein]

Hi Jirka,

Wenn Du mir jetzt noch sagen kannst, wie ich die mit einem LANCOM-Router anspreche, so dass ich die Downloadrate des Anschlusses, an dem der LANCOM-Router hängt, prüfen kann, dann bekommst eine Flasche Wein.
Ich habe von iPerf jetzt nicht so die Ahnung, wie Du. Ist denn iPerf3 nicht abwärtskompatibel zu iPerf2 (LANCOM)?

IPerf3 ist nicht abwärtskompatibel zu IPerf2. Dadurch kannst du die vielen verfügbaren Public Server leider nicht verwenden.

Gruß Dr.Einstein