[Sammelthread] Der 100Gbit Netzwerk Thread, ein bisschen 40gbit und „beyond“ ;)

Ah, das ist eine hilfreiche Info!

$ iperf -c 10.10.100.2 -P8
------------------------------------------------------------
Client connecting to 10.10.100.2, TCP port 5001
TCP window size: 325 KByte (default)
------------------------------------------------------------
[ 10] local 10.10.100.50 port 49212 connected with 10.10.100.2 port 5001
[ 3] local 10.10.100.50 port 49198 connected with 10.10.100.2 port 5001
[ 4] local 10.10.100.50 port 49200 connected with 10.10.100.2 port 5001
[ 5] local 10.10.100.50 port 49202 connected with 10.10.100.2 port 5001
[ 6] local 10.10.100.50 port 49204 connected with 10.10.100.2 port 5001
[ 7] local 10.10.100.50 port 49206 connected with 10.10.100.2 port 5001
[ 8] local 10.10.100.50 port 49208 connected with 10.10.100.2 port 5001
[ 9] local 10.10.100.50 port 49210 connected with 10.10.100.2 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 7.54 GBytes 6.48 Gbits/sec
[ 5] 0.0-10.0 sec 9.02 GBytes 7.75 Gbits/sec
[ 6] 0.0-10.0 sec 9.73 GBytes 8.36 Gbits/sec
[ 8] 0.0-10.0 sec 8.59 GBytes 7.38 Gbits/sec
[ 10] 0.0-10.0 sec 11.1 GBytes 9.50 Gbits/sec
[ 3] 0.0-10.0 sec 9.56 GBytes 8.21 Gbits/sec
[ 7] 0.0-10.0 sec 8.07 GBytes 6.93 Gbits/sec
[ 9] 0.0-10.0 sec 9.92 GBytes 8.52 Gbits/sec
[SUM] 0.0-10.0 sec 73.5 GBytes 63.1 Gbits/sec

Muss mal grad die VM neu starten und der ein paar Kerne mehr geben...

...was aber nichts bringt. 1.8GHz sind wohl zu lahm bzw. in der Richtung mit der VM als Server, scheint etwas anderes zu bremsen.

Der "localhost" gleichzeitig als server und client liefert zumindest genug Bumms:

$ iperf -c 10.10.100.50 -P8
------------------------------------------------------------
Client connecting to 10.10.100.50, TCP port 5001
TCP window size: 2.50 MByte (default)
------------------------------------------------------------
[ 9] local 10.10.100.50 port 45830 connected with 10.10.100.50 port 5001
[ 10] local 10.10.100.50 port 45828 connected with 10.10.100.50 port 5001
[ 4] local 10.10.100.50 port 45818 connected with 10.10.100.50 port 5001
[ 8] local 10.10.100.50 port 45826 connected with 10.10.100.50 port 5001
[ 5] local 10.10.100.50 port 45820 connected with 10.10.100.50 port 5001
[ 7] local 10.10.100.50 port 45824 connected with 10.10.100.50 port 5001
[ 6] local 10.10.100.50 port 45822 connected with 10.10.100.50 port 5001
[ 3] local 10.10.100.50 port 45816 connected with 10.10.100.50 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 19.0 GBytes 16.3 Gbits/sec
[ 8] 0.0-10.0 sec 20.8 GBytes 17.8 Gbits/sec
[ 5] 0.0-10.0 sec 18.2 GBytes 15.6 Gbits/sec
[ 7] 0.0-10.0 sec 18.8 GBytes 16.1 Gbits/sec
[ 6] 0.0-10.0 sec 21.2 GBytes 18.3 Gbits/sec
[ 3] 0.0-10.0 sec 18.6 GBytes 16.0 Gbits/sec
[ 10] 0.0-10.0 sec 18.6 GBytes 16.0 Gbits/sec
[ 9] 0.0-10.0 sec 20.7 GBytes 17.7 Gbits/sec
[SUM] 0.0-10.0 sec 156 GBytes 133 Gbits/sec

...wobei der i3 "intern" auch auf immerhin knapp 90 Gbits/sec kommt.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
tja. das sieht so exakt nach einem x8-Slot aus, das ist schon unheimlich. evtl gar nicht beim i3 sondern auf der anderen Seite ein shared-Slot?
 
Leider nein - steckt auf dem X11SPi-TF in Slot6 und der Shared nach meinem Verständnis nicht: https://www.supermicro.com/manuals/motherboard/C620/MNL-1900.pdf

Der 2. x16 in Slot4 geht auf x8 runter, wenn in Slot3 was steckt, slot6 aber nicht. Gut, das Ding ist halt voll, aber sollte ja an der Stelle keinen Unterschied machen.

Ich kann aber da auch nochmal ein Ubuntu booten und mal schauen was lspci -vv dazu sagt.

- - - Updated - - -

So. Ubuntu-live zu Ubuntu-live, mtu 9000, iperf(2.0.10) = ~80Gbit. Glaub der i3 ist echt einfach zu schwach, jetzt geht der schon auf Client-Seite auf quasi konstant 4x100% und als server wird er auch nicht schneller. Bim Silver 4108 ist hingegen kein Kern/Thread bei 100%.

Ubuntu.jpg

Jetzt müsste man also mal schauen, wie man den ESXi ggf. noch optimiert bekommt
 
Etwas OT, kann es aber gerade nicht testen, da die Systeme laufen müssen: Ist die MAC-Adresse bei Karten, die Transceiver (QSFP+) verwenden, eben vom Transceiver bestimmt (würde sich also bei Transceiver-Wechsel ändern) oder durch den Slot, bleibt also bei einer Karte immer gleich?
 
Der wird von der Karte selbst vorgegeben. Sollte bei Transceiverwechsel gleich bleiben.
 
Etwas OT, kann es aber gerade nicht testen, da die Systeme laufen müssen: Ist die MAC-Adresse bei Karten, die Transceiver (QSFP+) verwenden, eben vom Transceiver bestimmt (würde sich also bei Transceiver-Wechsel ändern) oder durch den Slot, bleibt also bei einer Karte immer gleich?

Wenn man sich einen Transceiver anschaut, dann erkennt man, dass dieser lediglich el. Signalen (xSFP) einfach in opt. Signale (LC/MPO...) wandelt. Er selber kennt also nur den Layer1 und sonst nichts.
Da die MAC eine Layer2 Komponenten ist, kann er also auch keine eigenen MAC besitzen und daher wird natürlich, wie sollte es anders sein, auch keine MAC geändert.
Transceiver sind nur ein erweiterter Arm des PHY einer Netzwerkkarte. Der PHY ist normal dafür zuständig, dass irgendwie ein analoges Signal, welcher Form auch immer, erzeugt wird. Er selber kennt nur Bits, was für Bits das sind, ist ihm egal. Er bekommt die Bits eines Ethernetpakets zu gespielt und ballert die dann raus. xSFP ist nichts anderes als eine standardisierte Schnittstelle um an PHYs flexible physikalische Übertragungswege anzudocken. Man hat also mal festgelegt, wie man Transceiver herstellerübergreifend ansteuert.
Früher war das anders, da gab es PHYs für opt. und welche für el. Wege. War OK, aber mit der Zunahme der verschiedenen Möglichkeiten, insbesondere im LWL-Bereich, war das irgendwann sehr doof.

Wenn der Transceiver die MAC ändern würde, müsste er selber Ethernetpakete schrauben und wäre damit wieder NIC.

Transceiver haben dennoch eine gewisse Intelligenz, das begrenzt sich aber nur auch ein paar wenige Codierungen und Transceivererkennung und ein paar Statistikwerte wie Temperatur oder Signalstärke. Das wird aber über einen separaten Kanal übertragen und hat erstmal nichts mit Ethernet zu tun.
 
Zuletzt bearbeitet:
Also, ich habs jetzt unter ESXi mit meiner Ubuntu-VM nochmal versucht, indem ich die Mellanox per Passthrough durchgereicht habe:

Code:
ubuntu@ubuntu:~$ iperf -c 10.10.100.1 -P8
------------------------------------------------------------
Client connecting to 10.10.100.1, TCP port 5001
TCP window size:  325 KByte (default)
------------------------------------------------------------
[ 10] local 10.10.100.2 port 37268 connected with 10.10.100.1 port 5001
[  4] local 10.10.100.2 port 37254 connected with 10.10.100.1 port 5001
[  5] local 10.10.100.2 port 37260 connected with 10.10.100.1 port 5001
[  6] local 10.10.100.2 port 37258 connected with 10.10.100.1 port 5001
[  9] local 10.10.100.2 port 37266 connected with 10.10.100.1 port 5001
[  7] local 10.10.100.2 port 37262 connected with 10.10.100.1 port 5001
[  3] local 10.10.100.2 port 37256 connected with 10.10.100.1 port 5001
[  8] local 10.10.100.2 port 37264 connected with 10.10.100.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[ 10]  0.0-10.0 sec  10.7 GBytes  9.23 Gbits/sec
[  4]  0.0-10.0 sec  10.3 GBytes  8.82 Gbits/sec
[  6]  0.0-10.0 sec  10.9 GBytes  9.38 Gbits/sec
[  9]  0.0-10.0 sec  9.19 GBytes  7.89 Gbits/sec
[  7]  0.0-10.0 sec  10.9 GBytes  9.39 Gbits/sec
[  3]  0.0-10.0 sec  10.3 GBytes  8.85 Gbits/sec
[  5]  0.0-10.0 sec  11.0 GBytes  9.44 Gbits/sec
[  8]  0.0-10.0 sec  10.0 GBytes  8.63 Gbits/sec
[SUM]  0.0-10.0 sec  83.4 GBytes  71.6 Gbits/sec

Mal schauen, was noch so geht...

So, das sieht doch ganz gut aus, RDMA-test mit ib_send_bw von ubuntu zu ubuntu:

Code:
root@ubuntu:~# ib_send_bw -d mlx5_1 -i 1 -F --report_gbits 10.10.100.1
---------------------------------------------------------------------------------------
                    Send BW Test
 Dual-port       : OFF		Device         : mlx5_1
 Number of qps   : 1		Transport type : IB
 Connection type : RC		Using SRQ      : OFF
 TX depth        : 128
 CQ Moderation   : 100
 Mtu             : 4096[B]
 Link type       : Ethernet
 GID index       : 5
 Max inline data : 0[B]
 rdma_cm QPs	 : OFF
 Data ex. method : Ethernet
---------------------------------------------------------------------------------------
 local address: LID 0000 QPN 0x08b3 PSN 0xf91208
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:10:10:100:02
 remote address: LID 0000 QPN 0x08ab PSN 0x939acb
 GID: 00:00:00:00:00:00:00:00:00:00:255:255:10:10:100:01
---------------------------------------------------------------------------------------
 #bytes     #iterations    BW peak[Gb/sec]    BW average[Gb/sec]   MsgRate[Mpps]
 65536      1000             97.74              97.74  		   0.186427
---------------------------------------------------------------------------------------
root@ubuntu:~#

Oder? ;)
 
Zuletzt bearbeitet:
Danke an danielmayer & underclocker2k4 für die Info und Erläuterungen!

Freue mich auch ein wenig auf das baldige Experimentieren mit 40 GbE und Optane 905Ps im ZFS Mirror, nachdem ich bislang nur mit SATA-Laufwerken hantiert habe.
 
@JohnnyBGoode: Puh...Optane-Mirror. Bin neidisch. :) Ich hab halt nix, um die 100gbit auch nur annähernd auszulasten. Aber wie schon an anderer Stelle zugegeben, Netzwerk macht mich irgendwie an...

Mal schauen, ob ich meinen Vorsatz umsetze, den Startpost in ein kleines HowTo mit Linksammlung zu editieren.
 
Soll das 'ne Drohung sein? :d
 
Ist ja gut... ;) ... hab mal angefangen, den Startpost zu überarbeiten.

Anmerkungen, Kritik, Verbesserungen, Ergänzungen usw. gerne!

@Danielmayer: wenn Du mir noch die Daten zu deinen QSFP+ Transceivern und ggf. verwendete Kabel nennst, ergänze ich die Infos dazu auch gerne noch im Startpost.
 
Zuletzt bearbeitet:
So, da ich nicht einsehe, mehr Versandkosten (>40 Euro - die spinnen!) als Warenpreis zu bezahlen, habe ich mal bei Mellanox 6 Fullsize Brackets bestellt. Maximal 3 könnte ich zum Selbstkostenpreis weiterverkaufen.

Außerdem im Zulauf: QSFP+ Adapter auf SFP+ - für den Anschluss an die bestehende 10Gbe-Infrastruktur... mal gucken, ob's tatsächlich funzt.
 
Zuletzt bearbeitet:
Ich nehme natürlich zwei. PM bitte.
Lt Internet sind die Adapter bis inkl CX3 nicht in der Lage, in den breakout-Mode zu gehen. Zur CX4 habe ich noch nichts gefunden und noch keine Zeit für einen Test gehabt.
Eine 4->1 Verbindung sollte aber das Gleiche machen wie Dein o.g. Adapter.
Evtl heute Nacht...

edit: no-Name 40Gb-SR Transceiver, ich hatte seinerzeit für Intel-kompatibel bestellt, da ich XL710 ins Auge gefasst hatte. Plus OM4 MTP 12adrig 2m.IMG_20181020_150946.jpg
 
Zuletzt bearbeitet:
Ich hatte hier bei Mellanox gelesen, dass Breakout nur die mellanox-Switche können, die Karten nicht: Mellanox Breakout Cables 40G 4x10G and 100... | Mellanox Interconnect Community

Auch laut Forumeintrag geht es nicht für die Karten: How to configure Mellanox card to accept breako... | Mellanox Interconnect Community

Important: The 40GbE split options is supported only on Mellanox switches and not supported on Mellanox adapters (e.g. ConnectX-3) when equipped with 40GbE ports.

Betraf allerdings unmittelbar nur 40G...
 
Zuletzt bearbeitet:
... was hab ich nur angerichtet :asthanos:
 
Ach komm, Du warst doch der Verkäufer... :d
 
Windows nervt. Zumindest als VM unter ESXi.

Wollte zu Testzwecken einen Port der Karte per PCIe-Passthrough durchreichen, das findet Windows (Server 2016 wie Win10 Pro gleichermaßen) aber irgendwie doof und kann/will das Gerät schon gar nicht starten. Hab' das Ausrufezeichen im Gerätemanager jedenfalls noch nicht weg bekommen. Ubuntu im Vergleich jammert gar nicht sondern bläst brav ~70gbit auch als VM durch's Glas.

Ich könnte noch testen, ob sich etwas ändert, wenn ich die Karte von ETH auf IB umstelle oder mal testweise beide Ports durchreiche. Fehlt mir aber gerade irgendwie die Motivation.
 
Zuletzt bearbeitet:
Ich bin da vielleicht nicht ganz so schwarz/weiß wie andere. Ich sehe in der Windowswelt, wie auch der Linux-, Solaris- oder vmWare-Welt jeweils durchaus viele positive Dinge. Perfekt ist keine. Nur Scheiße aber auch nicht.

Das gilt in meinen Augen für Server-OS wie Client-OS. Und das eine Windows-Server-VM unter ESXi mit Passthrough vielleicht nicht das Ideal-Setting für problemlosen Betrieb ist, ist mir auch bekannt. Darum bereue ich meinen kurzen Emotionsausbruch oben fast schon und hätte mich nur auf eine nüchterne Beschreibung des Phänomens beschränken sollen. ;)
 
Zuletzt bearbeitet:
Ich bin da vielleicht nicht ganz so schwarz/weiß wie andere. Ich sehe in der Windowswelt, wie auch der Linux-, Solaris- oder vmWare-Welt jeweils durchaus viele positive Dinge. Perfekt ist keine. Nur Scheiße aber auch nicht.

Das gilt in meinen Augen für Server-OS wie Client-OS.

ich finde es nur immer fazinierend die FW anpassen zu müssen für ein Windows Server OS
 
Baremetal liefen die unter Server/Windows 10 sofort oob ohne alles und das Dell Firmware lief easy einfach zusammen mit dem Installer durch.
 
Baremetal liefen die unter Server/Windows 10 sofort oob ohne alles und das Dell Firmware lief easy einfach zusammen mit dem Installer durch.

wie du aber sahst ändert sich das schlagartig in einer VM
die Linux/BSD sind da unzickig
 
FB und Netflix haben recht ausführliche Artikel über ihre 100G Kisten geschrieben, evtl ist da noch etwas hilfreiches bei. Out of the Box liefen auch da keine 100G.
 
Und nochmal eine Frage im Blick auf 100Gb MM: Kann ich mehrere QSFTP+ Verbindungen durch ein 24er MTP ziehen, also gibt es da auch Adapter Kabel: z.B. 24er MTP auf 3x 8er MTP? Aber vielleicht sollte ich dazu lieber in den 100G Thread wechseln...

Ja, kannst Du, wenn Du bei FS z.B. zwei entsprechende Breakout-Kabel bestellst. Die machen auch durchaus custom-orders, hatte ich selbst schon mit 12 MTP -> (8 MTP + 4xLC). Achte allerdings darauf, dass bei 3 Kabeln nur eines davon die Fasernrichtung umkehrt: 24->24 = Typ A, 24->3x8 Typ A und 24->3x8 Typ B, wobei "B" gegenüber FS klar zu definieren ist. Custom Order heißt sonst "pech gehabt".
Preislich ist das allerdings sehr uninteressant, da 24er Kabel mindestens doppelt zu teuer wie die 12er sind und die Breakouts sicherlich auch.
 
Zuletzt bearbeitet:
aber keine MPO24 to MPO8 breakouts, sondern nur MPO->LC. Das hatte er aber nicht gefragt ;)
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh