Ryzen 7, TCP/IP-Stack Performance unter Windows 10 bescheiden

Salutos

Commander
Mitglied seit
27.09.2017
Beiträge
153
Renomée
14
Hallo Gemeinde,

im Rahmen von diversen Netzwerk-Performance Messungen mit iperf habe ich auch mal den lokalen Durchsatz meines neuen AMD Rechners mit Ryzen X1700 gemessen.
Ich muss sagen ich bin enttäuscht!
Zum System
ASUS Prime B350-Plus, 16GB DDR4-2400, Ryzen 7 X1700, Samsung 960 500GB
Auf dem Desktop bekomme ich einen Durchsatz von ca. 550MB/s.
Mein betagtes Lenovo T430S kommt da auf ca. 650MB/s.

Getestet wurde wie folgt
2x Konsolenfenster mit Admin Rechten geöffnet
Im einen Fenster wurde iperf wie folgt gestartet iperf64 -s .
Im zweiten iperf64 -c 127.0.0.1

Hat das mal jemand probiert, was bekommt ihr für Werte heraus?

Gleiches Verhalten kann ich auf unseren Opteron ESXsen (Supermicro H8DGU / Opt 6348 ) und Intel ESXsen feststellen, hier ist der Unterschied noch deutlicher 330MB/s zu 680MB/s.

Hat schon jemand Erfahrung mit neuen EPYC Systemen, wie sieht es da aus mit dem Netzwerkdurchsatz?

Gruß
Salutos
 
Ich glaube iperf nutzt nicht mal den TCP Loopback Fast Path, von daher praktisch ehh nicht relevant. Ansonsten ist das vermutlich Latenz, oder zu viele Interrupts, oder sowas, oder Microsoft hat was kaputt gemacht.
 
Mit der Antwort gebe ich mich nicht zufrieden ;-)
Beide Rechner Laptop und Desktop sind default mässig installiert und bis zum aktuellen Stand gepacht.
Bisher keine weiteren Optimierungen vorgenommen. Die Testbedingungen sind gleich.
Heisst das die Intel Kisten erfahren von Microsoft einen besseren Support, auch im Serverbereich?

Wenn das auch bei den neuen EPYC Servern der Fall ist kann sich AMD beerdigen!
 
Klemm doch mal 2 Kisten mit SSD aneinander und schieb eine große Datei über die Leitung. Dann siehst du, wie schnell es wirklich ist. Zwischen Desktop-Rechner (FX8350) und NAS (Athlon5350) komme ich mindestens auf 720MBit/s und das bei Realtek-Karten
 
Sorry, bist du dir sicher das iperf ein verlässliches Tool ist?

Gut mögen alt sein, aber die Tendenz scheint klar zu sein:

https://arstechnica.com/civis/viewtopic.php?t=1113215

https://github.com/esnet/iperf/issues/234

Die scheinen immer mal wieder diverse Bugs zu haben. Der arstechnica - das waren Intelmaschinen unter Windows unter 400 die selbe Hardware in Linux gebootet lieferte das GiB..
Allerdings habe ich auf die schnelle mit Google nichts in Bezug auf AMD gefunden. Also entweder haste da was entdeckt - oder du bist der Einzige der das Problem hat.
Check doch mal im Forum des "Herstellers" ob denen da was bekannt ist - vielleicht ist es auch nur ein known Bug. By the way - ist nicht erst mal davon auszugehen, dass der Netzwerkhersteller (also Chip aufm Mainboard/Treiber dafür) das Problem verursacht?

P.S.: bschicht86 Ratschlag einfach befolgen. Wirst du ja sehen was geht.
 
Zuletzt bearbeitet:
Zunächst mal danke für den Vorschlag.
Ich teste ja in beiden Fällen gegen das Loopback-Device des Rechners, damit sollte kein Netzwerktreiber einer Hardware mit im Spiel sein.
Und falls das falsch rübergekommen sein sollte bei meinen Werten handelt es sich um MBytes/s
Ähnliche Performance-Unterschiede zeigt auch das MS Tool NTttcp an.

PS: hat hier noch jemand einen AMD Server mit Opteron 63xx CPUs im Einsatz?
 
Damit ich das richtig verstehe, du brauchst die Performance zwischen VM's und nicht das, was wirklich übers Kabel rausgeht? Weil dann war ich ja auf dem Holzweg.
PS: hat hier noch jemand einen AMD Server mit Opteron 63xx CPUs im Einsatz?
einmal ein Sys mit K10-Opteron und eins mit 62xx-Opteron
 
Mit der Antwort gebe ich mich nicht zufrieden ;-)
Beide Rechner Laptop und Desktop sind default mässig installiert und bis zum aktuellen Stand gepacht.
Bisher keine weiteren Optimierungen vorgenommen. Die Testbedingungen sind gleich.
Heisst das die Intel Kisten erfahren von Microsoft einen besseren Support, auch im Serverbereich?

Wenn das auch bei den neuen EPYC Servern der Fall ist kann sich AMD beerdigen!

Das Loopback-Device ist eine reine Softwarekomponente von Microsoft - das funktioniert auch ohne jegliche Netzwerkkarte im System.
 
Ja das ist richtig, das Kabel möchte ich zunächst außen vor lassen.
Nutzt du den 62xx zur Virtualisierung?
Falls ja und es gibt es eine VM mit Windows Server 2008 R2 oder 2012 R2 drauf?
Oder auch ein Windows Server der nativ auf dem Server läuft.

Also falls es dir keine zu großen Umstände bereitet, würdest du mal eine Messung (Parameter wie Anfangs geschrieben) auf einem der Server laufen lassen und die Werte teilen?
https://iperf.fr/download/windows/iperf-3.1.3-win64.zip
 
hi Salutos,
der string ist dann aber iperf3 nicht 64 ;)
lg
 
Nutzt du den 62xx zur Virtualisierung? Falls ja und es gibt es eine VM mit Windows Server 2008 R2 oder 2012 R2 drauf? Oder auch ein Windows Server der nativ auf dem Server läuft.]
Ausschliesslich für BOINC. 2008 R2 ist drauf (2008 auf den K10) und Linux in VM. Aber für BOINC ist die Übertragungsgeschwindigkeit nicht relevant für mich.
 
hi Salutos,

ich denke du hast ein system problem?
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 1.25 GBytes 1.07 Gbits/sec sender
[ 4] 0.00-10.00 sec 1.25 GBytes 1.07 Gbits/sec receiver
sagt mein System mit dem Ryzen, der Lapi mit Intel I5 sagt ~500Mb also wäre der Ryzen doch um einiges schneller, hast du den Stromspar modus zufällig nicht beachtet?
lg
 
Hallo Mente,

cool dass sich jemand am Testen beteiligt!
Als Energie plan nutze ich den ADM Ryzen Balanced.
Ob deine Werte meine Zufriedenheit jetzt steigern weiss ich noch nicht. Du unterschlägst die ersten 10 Zeilen. :]
Mein AMD System liefert folgende Werte
Connecting to host 127.0.0.1, port 5201
[ 4] local 127.0.0.1 port 61056 connected to 127.0.0.1 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 273 MBytes 2.28 Gbits/sec
[ 4] 1.00-2.00 sec 280 MBytes 2.36 Gbits/sec
[ 4] 2.00-3.00 sec 369 MBytes 3.09 Gbits/sec
[ 4] 3.00-4.00 sec 408 MBytes 3.41 Gbits/sec
[ 4] 4.00-5.00 sec 406 MBytes 3.40 Gbits/sec
[ 4] 5.00-6.00 sec 434 MBytes 3.64 Gbits/sec
[ 4] 6.00-7.00 sec 444 MBytes 3.73 Gbits/sec
[ 4] 7.00-8.00 sec 445 MBytes 3.74 Gbits/sec
[ 4] 8.00-9.00 sec 445 MBytes 3.73 Gbits/sec
[ 4] 9.00-10.00 sec 446 MBytes 3.74 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 3.86 GBytes 3.31 Gbits/sec sender
[ 4] 0.00-10.00 sec 3.86 GBytes 3.31 Gbits/sec receiver

Mir geht es um den Durchsatz in MBytes pro Sekunde. Und da bin ich der Meinung die 450MB/s sind zu wenig.

Nun die Werte des Lenovo T430S!
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 127.0.0.1, port 49672
[ 5] local 127.0.0.1 port 5201 connected to 127.0.0.1 port 49673
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-1.00 sec 488 MBytes 4.09 Gbits/sec
[ 5] 1.00-2.00 sec 546 MBytes 4.58 Gbits/sec
[ 5] 2.00-3.00 sec 706 MBytes 5.92 Gbits/sec
[ 5] 3.00-4.00 sec 725 MBytes 6.08 Gbits/sec
[ 5] 4.00-5.00 sec 716 MBytes 6.01 Gbits/sec
[ 5] 5.00-6.00 sec 763 MBytes 6.40 Gbits/sec
[ 5] 6.00-7.00 sec 760 MBytes 6.38 Gbits/sec
[ 5] 7.00-8.00 sec 794 MBytes 6.66 Gbits/sec
[ 5] 8.00-9.00 sec 764 MBytes 6.41 Gbits/sec
[ 5] 9.00-10.00 sec 775 MBytes 6.50 Gbits/sec
[ 5] 10.00-10.00 sec 293 KBytes 5.16 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-10.00 sec 0.00 Bytes 0.00 bits/sec sender
[ 5] 0.00-10.00 sec 6.87 GBytes 5.90 Gbits/sec receiver
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------

Da liegen Welten dazwischen!
Im Übrigen sieht das Verhältnis auf meinen Servern ähnlich drastisch aus.

Noch jemand der Werte liefern kann?


Grüße
Salutos

PS: werde das morgen an einem baugleichen AMD System noch - neu aufgesetzt - testen.
 
Mir geht es um den Durchsatz in MBytes pro Sekunde. Und da bin ich der Meinung die 450MB/s sind zu wenig.
Welchen Durchsatz erwartest du denn? 1 Gbit-LAN überträgt ca. 110 MB/s. Du hast 4-6 Gbit/s Übertragung mit deinem Ryzen. Wie schnell sollte es denn sein? Ich meine, was ist das Problem?
 
Complicated macht es complicated (Sorry fürs Wortspiel) ;) Die 4-6 GBit/s waren auf einem Lappi und brauchen tut man die Speed wohl zwischen VM's, die einen virtuellen Ethernetadapter mit dem Host-Sys teilen.
 
Seit wann haben VMs 10GBit NICs?
VMware und Virtualbox stellen doch nur 1GBit/s NICs zur Verfügung.
Nichtsdestotrotz sieht das merkwürdig aus.
Mal schauen ob ich iperf zum Laufen bekomme. Server startet und Client verbindet sich, aber lasttechnisch tut sich da nichts.
 
@TE: hast Du die diversen Stromsparfunktionen des Ryzen schon als Auslöser ausgeschlossen? Dazu müsstest Du im BIOS die Funktionen Cool'n'Quiet, C1E und C6 abschalten. Dann bitte nochmal testen. Würde mich interessieren, ob sich was ändert.

@Complicated: ich denke, der TE würde gerne wissen, weshalb sein nagelneues Ryzen-System bei diesem Test nur halb so schnell ist wie ein betagter Laptop. Eine berechtigte Frage würde ich meinen. Klar deckelt im Normalfall beim Homeuser das Gigabit-LAN, aber in einem Server mit mehreren VMs oder einem Terminal-Server z.B. wo der Traffic nicht durch Gb-LAN gebremst wird, wäre es ein Makel.
 
Ich weiss nicht was ihr habt:

iperf3 -c 127.0.0.1
Connecting to host 127.0.0.1, port 5201
[ 5] local 127.0.0.1 port 57158 connected to 127.0.0.1 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 2.94 GBytes 25.2 Gbits/sec 0 2.19 MBytes
[ 5] 1.00-2.00 sec 2.89 GBytes 24.8 Gbits/sec 0 2.31 MBytes
[ 5] 2.00-3.00 sec 2.90 GBytes 24.9 Gbits/sec 0 2.81 MBytes
[ 5] 3.00-4.00 sec 2.91 GBytes 25.0 Gbits/sec 0 3.00 MBytes
[ 5] 4.00-5.00 sec 2.88 GBytes 24.7 Gbits/sec 0 3.12 MBytes
[ 5] 5.00-6.00 sec 3.06 GBytes 26.3 Gbits/sec 0 3.12 MBytes
[ 5] 6.00-7.00 sec 2.96 GBytes 25.5 Gbits/sec 0 3.12 MBytes
[ 5] 7.00-8.00 sec 3.00 GBytes 25.8 Gbits/sec 0 3.12 MBytes
[ 5] 8.00-9.00 sec 2.94 GBytes 25.3 Gbits/sec 0 3.12 MBytes
[ 5] 9.00-10.00 sec 3.20 GBytes 27.5 Gbits/sec 0 3.12 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 29.7 GBytes 25.5 Gbits/sec 0 sender
[ 5] 0.00-10.04 sec 29.7 GBytes 25.4 Gbits/sec receiver

:P

no, just kidding, war Linux ...

Also ein cygwin Programm wie das hier vorhandene kann nicht optimal von der Performance sein.

Ich denke, dass die oberen Zahlen das deutlich machen.
Auf der einen Seite Eure Zahlen, auf der anderen das was tatsächlich über ein Loopback Interface gehen kann.
 
Zuletzt bearbeitet:
Es ist eben auch mehr Complicated als es auf den ersten Blick aussieht. ;)

Also zunächst einmal kannst du überhaupt keine konsistenten Tests über den Speed machen wenn du zwei verschiedene Ports auf der selben IP verwendest zum Testen. Der localhost ist eine IP und du sendest Daten an die selbe IP nur auf einen anderen Port. Für einen echten Speedtest benötigst du zwei IP Adressen. So etwas:
Connecting to host 127.0.0.1, port 5201
[ 5] local 127.0.0.1 port 57158 connected to 127.0.0.1 port 5201
Kann keine konsistenten Ergebnisse bringen. Die selbe IP sendet und empfängt abwechselnd - wie soll man da messen wie hoch die Geschwindigkeit sein kann? Das einzige was hier gemessen wird ist wie schnell der Software-Stack umschaltet und Kollisionen verwirft - das ist wohl im Laptop mit geringeren Latenzen konfiguriert. Die Loopbackadresse eignet sich für einen Funktionstest, doch überhaupt nicht für einen Geschwindigkeitstest.
 
Das hat schon prinzipiell Relevanz für Inter-Prozess-Kommunikation auf der gleichen Maschine, beziehungsweise wohl auch für manche VM-Lösungen. Wobei die meisten Anwendungsfälle da kaum hohe Bandbreiten brauchen.
 
Das stimmt alles, nur kannst du keine Geschwindigkeit messen für die du dann am Ende die CPU des Systems verantwortlich macht. Also setzt du die VMs auf und misst was da raus kommt. Du brauchst 2 IP Adressen wo die eine empfängt und die andere sendet. Und nicht nur zwei verschiedene Ports die sich abwechseln auf einer IP. Zumindest wenn du etwas sinnvolles messen willst. Letztendlich bestimmt dein Datenspeicher wo das Limit ist in einem Server/System

Hier als Quelle:
http://www.tcpipguide.com/free/t_IPReservedPrivateandLoopbackAddresses.htm
Normally, when a TCP/IP application wants to send information, that information travels down the protocol layers to IP where it is encapsulated in an IP datagram. That datagram then passes down to the data link layer of the device's physical network for transmission to the next hop, on the way to the IP destination.

However, one special range of addresses is set aside for loopback functionality. This is the range 127.0.0.0 to 127.255.255.255. IP datagrams sent by a host to a 127.x.x.x loopback address are not passed down to the data link layer for transmission. Instead, they “loop back” to the source device at the IP level. In essence, this represents a “short-circuiting” of the normal protocol stack; data is sent by a device's layer three IP implementation and then immediately received by it.

The purpose of the loopback range is testing of the TCP/IP protocol implementation on a host. Since the lower layers are short-circuited, sending to a loopback address allows the higher layers (IP and above) to be effectively tested without the chance of problems at the lower layers manifesting themselves. 127.0.0.1 is the address most commonly used for testing purposes.

Das verlässt niemals den Layer 3.
 
Zuletzt bearbeitet:
Die Kommunikation erfolgt ja nicht ausschließlich über die Adresse.
Diese ist ja nur ein Teil des Kommunikationskanals der aufgebaut wird.
Der Kanal besteht ja aus dem ausgehenden Port und dem eingehenden Port.
Daher ist es kein Problem und auch korrekt auf dem Loopback Netzwerkdevice zu kommunizieren.

Die Kommunikation erfolgt halt nicht nach außen sondern als eine Art Interprozesskommunikation zwischen 2 beteiligten einer Maschine in sich über den TCP/IP Stack.

In der Praxis ist das durchaus oft üblich.
Zum Beispiel hört eine Datenbank nur auf port 127.0.0.1 um nicht von außen angesprochen werden zu können.
Damit können aber Clients auf der Maschine selbst sehr wohl mit der Datenbank kommunizieren.
 
Zuletzt bearbeitet:
Mein AMD System liefert folgende Werte

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 3.86 GBytes 3.31 Gbits/sec sender
[ 4] 0.00-10.00 sec 3.86 GBytes 3.31 Gbits/sec receiver

Mir geht es um den Durchsatz in MBytes pro Sekunde. Und da bin ich der Meinung die 450MB/s sind zu wenig.

Nun die Werte des Lenovo T430S!

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-10.00 sec 0.00 Bytes 0.00 bits/sec sender
[ 5] 0.00-10.00 sec 6.87 GBytes 5.90 Gbits/sec receiver
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------

Da liegen Welten dazwischen!
Weiß ja nicht, was es ausmacht, dass der eine nur sendet, der andere sendet und empfängt.
Da wäre der AMD mit 2x3,31 GBit/s sogar schneller.
 
Also bitte nochmal lesen was ich schrieb: JA zum Funktionstest - NEIN zum Speedtest über 127.0.0.1

Die beiden Ports können nicht GLEICHZEITIG auf der selben IP kommunizieren, sondern nur abwechselnd. Ein Port ohne die IP-Adresse kann gar nichts. Es kann nur 1 Port zugleich die IP-Adresse nutzen. Nur zusammen ergeben IP-Adresse und Port den Kommunikations-"Socket".

Nur weil etwas angesprochen werden kann, ist es nicht sinnvoll darüber den Speed zu messen und dies dann auch noch der CPU zuzuschreiben, wo keinerlei Hardware im Spiel ist.

Bitte hier nachlesen warum, wenn man mehr Details möchte: http://www.netzmafia.de/skripten/netze/netz8.html Dort den Abschnitt ARP-Protokoll lesen. Das fällt bei Loopback völlig weg.

Hier die spezifischen Loopback Eigenschaften:
https://blogs.technet.microsoft.com...h-windows-server-2012-tcp-loopback-fast-path/
TCP Loopback Fast Path is a new feature introduced in Windows Server 2012 and Windows 8. If you use the TCP loopback interface for inter-process communications (IPC), you may be interested in the improved performance, improved predictability, and reduced latency the TCP Loopback Fast Path can provide. This feature preserves TCP socket semantics and platform capabilities including the Windows Filtering Platform (WFP), and works on both non-virtualized and virtualized operating system instances.
Reine Softwarefrage.

Vielleicht ist bei den Testsystemen auch dies entscheidend:
TCP Loopback Fast Path is a new feature introduced in Windows Server 2012 and Windows 8.
Welches OS da getestet wurde bei Laptop/Opteron/EPYC war ja nicht beschrieben. Vielleicht der Opteron noch unter Windows7/Server2008? Der Laptop mit Windows 8 oder 10? EPYC?
 
Zuletzt bearbeitet:
Endlich kommt mal Fahrt in das Thema. :D

Also auf beiden Rechnern läuft Windows 10 in der gleichen Version und Patchstand. (wie in der Headline geschrieben)
Ich gebe zu, die Diskussion ist etwas entglitten. Beschränken wir uns weiterhin auf Windows 10 / AMD Desktop Ryzen / Intel Laptop
Neben der Tatsache, dass das Loopback Interface sehr wohl duplexfähig ist, spielt es auch keine Rolle, ob die Daten verschiedene Netzwerklayer durchlaufen.
Die Testbedingungen sind auf beiden Geräten gleich, die Ergebnisse könnten nicht unterschiedlicher sein.

Wie BoMbY schon treffend angemerkt hat, auf einem ESX Host mit verschiedenen VMs (alle auf dem gleichen ESX) kommt es, je nach Fall, sehr wohl auf Geschwindigkeit an, bspw. beim Backup über einen Agent in der VM. Um nur ein Beispiel zu nennen.
Meine Erfahrung ist, die Geschwindigkeit, die das Loopback Interface erreicht, liegt immer über der, wie meine VM nach extern kommunizieren kann!

Aber zurück zum einfachen Fall AMD Desktop / Intel Laptop
Hat noch jemand eine Idee weshalb hier so eine Differenz besteht?
Möchte sich noch jemand mit eigenen Tests einbringen?

Grüße
Salutos
 
Zurück
Oben Unten