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

hi
leider stimmt das nicht zwischen 2 vm sieht das ganz anders aus?
dein test ist sehr strange den die vm hab bei Virtualisierung ganz andere ebenen wie hier.
bei mir begrenzt da ehr Speicher und größer die ssd ...
 
@Salutos
Nur gehen alle Netzwerkverbindungen zu VMs durch den Layer 2 (Data Link Layer) - der Loopback eben nicht. Das versuche ich doch die ganze Zeit zu erklären. Es gibt kein ARP im Gegensatz zu VMs. Die Geschwindigkeit von VM und Loopback sind nur bedingt abhängig. Auf keinen Fall kann man vom Loopback alleine auf die VM-Speed schließen.

Zudem gibt es keinerlei Speed-Negotiation auf dem Loopback. Mit wem auch.

--- Update ---

Hat schon jemand Erfahrung mit neuen EPYC Systemen, wie sieht es da aus mit dem Netzwerkdurchsatz?
Und das hast du ganz sicher nicht gemessen mit dieser Methode *buck*

--- Update ---

Also auf beiden Rechnern läuft Windows 10 in der gleichen Version und Patchstand. (wie in der Headline geschrieben)
Danke hatte ich übersehen :)

Hast du eigentlich den Microsoft Loopback Adapter installiert auf allen Maschinen? Oder einfach die IP benutzt?
 
Zuletzt bearbeitet:
Aber zurück zum einfachen Fall AMD Desktop / Intel Laptop
Hat noch jemand eine Idee weshalb hier so eine Differenz besteht?

Grüße
Salutos
Laß auf beiden mal das gleiche laufen.
Also entweder beide senden und empfangen oder
auf beiden nur empfangen.
 
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".

Sorry, aber das dürfte ziemlicher Quatsch sein. Vor allem beim Loopback-Device. Ein Port auf einer IP-Adresse kann nur von einem Prozess als Listener registriert werden, aber es können selbst darüber mehrere Asynchrone Verbindungen laufen.
 
Na klar können verschieden Dienste gleichzeitig ihren Port auf der selben IP laufen lassen. Doch jedes IP Paket muss warten bis der andere fertig ist. Wenn du also versuchst die max. Geschwindikeit des Netzwerkstacks zu messen, dann nutzt du einen Port zum senden und einen zum empfangen die sich abwechseln und nie gleichzietig senden und empfangen können. Und je mehr Ports du auf diese IP in Dienst stellst desto mehr teilen sich die Zeit beim senden und empfangen. Desto langsamer läuft dein Benchmark den du auf Port 2101 protokollierst.

Hier ist die Frage was du unter gleichzeitig verstehst. Es kann immer nur ein Paket gesendet oder empfangen werden auf einer IP-Adresse. Du schreibst ja selber Asynchrone Verbindungen. Das ist das Gegenteil von Gleichzeitig.
 
Mit iperf wird auch nicht gleichzeitig gesendet und empfangen sondern der Client empfängt zuerst eine Zeit lang und sendet anschließend eine Zeit lang.
Mittels fullduplex ist das am loopback device zum Serverteil natürlich möglich.

Ob letztendlich eine tatsächliche Parallelität auf der TCP Paketebene am loopback device stattfinden kann ist eine Frage der Implementierung des TCP/IP Stacks.
Über ein Netzwerkkabel kann schließlich nur ein Paket pro Zeiteinheit übertragen werden.
Was allerdings hier keine Rolle spielt.

Als Test kann man ja 2 Stück Server und 2 Stück Clients laufen lassen und dann die Zahlen beobachten.
Teilen sich die beteiligten die Bandbreite oder addieren sich die Bandbreiten?
Das ist hier die Frage.
 
Aber wie ich ja schon vorher schrieb findet auf dem Loopback keine Layer-2 Kommunikation statt. Keine ARP Anfragen und somit kein Austausch von MAC-Adressen. Somit hat man schon kein vollständiges IP-Paket und es fehlt ein Teil der bei realen Netzwerken zwingend erforderlich ist. Selbst VMs benötigen den Layer-2 um dem vNIC eine MAC-Adresse zuzuordnen. Ich will damit lediglich klar machen, dass hier keine Benchmarks stattfinden die für den realen Netzwerkverkehr von Bedeutung sind oder gar diesen Abbilden. Loopback ist und bleibt ein lokaler Funktionstest für Diagnosen und kein Speed-Test. Den Werten alleine kann man nichts sinnvolles entnehmen.

tomturbos Methode ist die einzige sinnvolle, da hier auch MAC-Adressen involviert sind und sämtliche relevanten Netzwerk-Layer genutzt werden müssen. Und dann testet man in der Regel auch lediglich ob das theoretische Maximum der genutzten physikalischen Leitungen (1 Gbit/s, 10 Gbit/s etc) auch saturiert wird. Wenn ja nimmt man einen weiteren NIC dazu bis eben kein zusätzlicher NIC mehr voll ausgelastet wird.
 
Du irrst complicated.
Das IP Protokoll braucht keine MAC Adressen um funktionieren zu können.
MAC Adressen braucht nur Ethernet. IP funktioniert auch auf Standleitungen z.B. mit PPP Protokoll ganz ohne MAC.
ARP ist auch nur wegen dem Ethernet vorhanden.
Das alles braucht ein loopback device nicht und ist trotzdem ein richtiges IP device.
 
Ich würde irren wenn ich gesagt hätte das IP Protokoll benötigt MAC Adressen. Habe ich aber nicht.
Somit hat man schon kein vollständiges IP-Paket und es fehlt ein Teil der bei realen Netzwerken zwingend erforderlich ist.
Edit: Ein IP-Paket besteht aus mehr als nur dem IP-Protokoll - eventuell war das missverständlich:
https://de.wikipedia.org/wiki/IP-Paket
Damit wird das gesamte Internet-Protokoll Datagram bezeichnet. Ich hatte allerdings den gesamten Ethernetframe gemeint und ihn als IP-Paket bezeichnet, was auch ungenau ist. Hier eine Grafik die das beschreibt:
ARP_und_Routing.png


Und aus was besteht deine Standleitung?
PPP over Ethernet (PPPoE) ist die Verwendung des Netzwerkprotokolls Point-to-Point Protocol (PPP) über eine Ethernet-Verbindung. Das Protokoll definiert zwei Phasen: PPPoE Discovery und PPP Session. In der ersten Phase PPPoE Discovery wird die MAC-Adresse eines Access Concentrators ermittelt. Danach werden in der zweiten Phase PPP Session Daten nach PPP ausgetauscht.
Es gibt kaum noch etwas das ohne MAC-Adresse auskommt.

--- Update ---

Das alles braucht ein loopback device nicht und ist trotzdem ein richtiges IP device.
Das hat ebenfalls niemand angezweifelt. Wir diskutieren hier lediglich sinnvolle Messverfahren auf dem Loopback und warum man dort nicht Benchmarks mit Aussagekraft für die Geschwindigkeit des Netzwerkes machen kann. Ob Ryzen, Opteron oder mobiler Intel schneller sind wirst du dort nicht erfahren. Siehe Ausgangsposting und Thread-Überschrift.
 
Zuletzt bearbeitet:
PPP ist nicht pppoe. SLIP Protokoll, wurde früher verwendet, ist auch nicht Ethernet. ATM ebenso. Auch da gibt es keine MAC Adresse.
Wikipedia ist bullshit Halbwissen. Sorry.
IP benötigt kein Ethernet um zu funktionieren. Wurde erfunden ohne Ethernet.
Ein loopback device braucht keine MAC Adressen weil es kein Ethernet ist!
Nur 802.3 basierende Protokolle brauchen eine MAC Adresse.
Glaub es mir ich bin CCNP und weiß wovon ich rede.
 
Ich fragte dich doch welche Standleitung du meinst. Wozu diese MAC Diskussion relevant sein soll entgeht mir allerdings. Ich habe ja präzisiert was ich meinte.

Und ob ein Loopbackdevice eine MAC braucht ist wichtig weil?
Ich schrieb doch schon Beiträge zuvor, dass ein Loopback den Layer 3 nicht verlässt und genau deswegen keinen Nutzen hat als Benchmark. Warum Alternativen zu Ethernet hier wichtig sein sollen in der Diskussion kannst su mir sicher jetzt erklären.

Wenn du CCNP bist und weist wovon du redest, versuch doch mal nicht am Thema vorbei zu reden.

PPPoE habe ich als Beisoiel angeführt weil du sagtes PPP benötigt keine MAC Adresse. Damit wollte ich aufzeigen, dass dies nicht automatisch der Fall ist und PPP auch mit Mac adressen existiert. Ob Mac Adressen benötigt werden oder nicht liegt nicht am Layer 3 Protokoll.
 
Zuletzt bearbeitet:
Hey, Du kommst dauernd mit irgend welchen MACs auf Layer2 und ARP Protokoll, was alles am loopback device fehlt und deswegen es nicht testbar sein soll.
Ich zeigte auf, dass das nicht benötigt wird um den IP Stack zu testen.
Ich bringe das Beispiel PPP, Du kommst mit PPPoE.
Also rede Dich jetzt nicht raus.

Über den Test des TEs kannst Du die Performance des Loopback Devices testen. Allerdings eingeschränkt auf ein cygwin Proggramm, welches ganz sicher nicht optimal dafür geeignet ist.
Meiner Meinung nach zeigt es eher den Unterschied zwischen cygwin Programmen auf unterschiedlichen Plattformen. Der IP Stack ist hierbei sicher nicht ausgelastet.
Warum sich das ganze so verhält, müsste man mittels profiling klären, sonst bleiben nur die nackten Zahlen.

Ich mache mir nun die Mühe auf meiner Kiste mal W10 zu starten um das cygwin Proggie auszuführen.
Auf der gleichen Hardware dann das native unter Linux, wofür es geschrieben wurde. Mal sehen welche Unterschiede das zeigt.


EDIT:

Also die Zahlen auf der gleichen Hardware wie in http://www.planet3dnow.de/vbulletin...0-bescheiden?p=5179993&viewfull=1#post5179993 unter W10 sind wie folgt:

C:\Tools\iperf-3.1.3-win64>iperf3 -c 127.0.0.1
Connecting to host 127.0.0.1, port 5201
[ 4] local 127.0.0.1 port 61945 connected to 127.0.0.1 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 256 MBytes 2.15 Gbits/sec
[ 4] 1.00-2.00 sec 320 MBytes 2.67 Gbits/sec
[ 4] 2.00-3.00 sec 317 MBytes 2.66 Gbits/sec
[ 4] 3.00-4.00 sec 322 MBytes 2.71 Gbits/sec
[ 4] 4.00-5.00 sec 320 MBytes 2.68 Gbits/sec
[ 4] 5.00-6.00 sec 311 MBytes 2.60 Gbits/sec
[ 4] 6.00-7.00 sec 318 MBytes 2.68 Gbits/sec
[ 4] 7.00-8.00 sec 296 MBytes 2.48 Gbits/sec
[ 4] 8.00-9.00 sec 304 MBytes 2.56 Gbits/sec
[ 4] 9.00-10.00 sec 327 MBytes 2.74 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 3.02 GBytes 2.59 Gbits/sec sender
[ 4] 0.00-10.00 sec 3.02 GBytes 2.59 Gbits/sec receiver

iperf Done.

Vorher ca. 25 Gbit/s jetzt 2,59 Gbit/s
Damit sehen wir: Dieses Programm ist nicht wirklich geeignet um etwas auszusagen.

EDIT2:

Mit der Option "-P3" also 3 parallele streams bin ich in W10 auf ca 3,5 Gbit/s gekommen.
Unter Linux auf knapp 30 Gbit/s
Auf der gleichen Hardware
 
Zuletzt bearbeitet:
Hey, Du kommst dauernd mit irgend welchen MACs auf Layer2 und ARP Protokoll, was alles am loopback device fehlt und deswegen es nicht testbar sein soll.
Ich zeigte auf, dass das nicht benötigt wird um den IP Stack zu testen.
Und schon wieder geht es direkt am Thema vorbei - ich zitiere was ich dazu schrieb und du kannst dir das langatmige erklären von Dingen die wir beide wissen sparen. Nur damit wir nicht in immer mehr Sinnlos-Schleifen enden. Schritt für Schritt: Stimmst du hier mit mir überein?
Also bitte nochmal lesen was ich schrieb: JA zum Funktionstest - NEIN zum Speedtest über 127.0.0.1?
 
Vorher ca. 25 Gbit/s jetzt 2,59 Gbit/s
Damit sehen wir: Dieses Programm ist nicht wirklich geeignet um etwas auszusagen.

EDIT2:

Mit der Option "-P3" also 3 parallele streams bin ich in W10 auf ca 3,5 Gbit/s gekommen.
Unter Linux auf knapp 30 Gbit/s
Auf der gleichen Hardware
Damit haben wir das ja erfolgreich geklärt und stimmen dann miteinander überein.
 
Zurück
Oben Unten