[Sammelthread] 10Gbit Homenetzwerk

[gea]

Ich habe es so verstanden, dass bei RDMA-NICs auf beiden Seiten der vorhandene RAM benutzt wird

Mittels rdrma kann ein RAM Bereich zwischen host und client direkt gelesen/beschrieben werden, ohne dass dazu das Lanprotokoll ip mit seinem CPU Aufwand benötigt wird. Nach der Übertragung der Daten in den gegenüberliegenden RAM werden die Daten normal aus dem RAM zur Platte transferiert oder weiterverarbeitet. Insgesamt verringert das die CPU Last und die Latenz enorm. Im Ergebnis kann selbst bei Multiuser Transfers die SMB Direkt Übertragung fast mit Wirespeed (25Gbit/s, 100Gbit/s) erfolgen.

Man benötigt halt neben rdma nics einen rdma fähigen SMB Server (SMB Direkt) wie Windows Server ab v2012 und SMB Direkt rdma clients wie Windows 11 Pro

 

[Gr3yh0und]

Gen 3x1 790-800 MB/s

Frage mich wann einer auf die Idee kommt das auf ein m2 a+e 2230 Board zu bauen... Dann könnte man den ganzen SFF Kisten preiswert, sparsam 8Gbit einflößen und den WiFi slot nutzen.

 

[Dwayne_Johnson]

Mittels rdrma kann ein RAM Bereich zwischen host und client direkt gelesen/beschrieben werden, ohne dass dazu das Lanprotokoll ip mit seinem CPU Aufwand benötigt wird. Nach der Übertragung der Daten in den gegenüberliegenden RAM werden die Daten normal aus dem RAM zur Platte transferiert. Insgesamt verringert das die CPU Last und die Latenz enorm. Im Ergebnis kann selbst bei Multiuser Transfers die SMB Direkt Übertragung fast mit Wirespeed (25Gbit/s, 100Gbit/s) erfolgen.

Wenn ich damit den Transfer gut spürbar beschleunigen könnte, muss ich das haben
Nur welche (noch bezahlbare) RDMA-Karte wäre zu empfehlen? Und weiss jmd, ob diese NICs unter UNRAID, TrueNAS etc problemlos laufen?

Beitrag automatisch zusammengeführt: Heute um 16:43

Frage mich wann einer auf die Idee kommt das auf ein m2 a+e 2230 Board zu bauen... Dann könnte man den ganzen SFF Kisten preiswert, sparsam 8Gbit einflößen und den WiFi slot nutzen.

Bei USFF-PCs (1 Liter-PCs) wirds interessant
Solche Umbauten auf 10G gibt es, aber ob der Wifi-M.2-Slot bei neueren USSFs nutzbar ist - k.A. Bei den Älteren geht das nicht, weil diesen Wifi-Slots anscheinend passende Protokolle fehlen

btw:
In Lenovo Tinys (USFF) könnte eine normale RTL8127-Karte mit diesem Adapter passen

 

[gea]

Ich vermute mal, die gängigsten sind Mellanox ab X4 oder Intel 810, ansonst auf RoCE v2 achten.
Mit wenigen clients im gleichen Raum brauchts keinen Switch, da reichen DAC Kabel neben normalem 1-10G

ps
Das Problem mit TrueNas etc ist SAMBA, das kann kein SMB Direkt. Man bräuchte stattdessen den Kernel ksmbd SMB Server (nicht in jeder Distribution) der nicht immer SMB Direkt kann und auch dann nur mit Linux clients SMB Direkt kann und nicht mit z.B. mit Windows 11.

Besterino ist da der "Meister"

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

Hab gerade bei mir zuhause die Verkabelung umgestellt und dann 2h Fiber debugged... Stellt sich raus: Der Zulieferer hat mir komplett falsche Kabel geschickt. Bestellt war OS2 MTP APC... Die gibt es eigentlich NUR in APC, ich hab die noch nie UPC gesehen (Multimode MTP ist dagegen immer UPC...

www.hardwareluxx.de

 

[bakhtar]

Ob du ein einziges zb 100GB großes File oder 100.000 Mini-Files von insgesamt 100GB kopierst, macht keinen Unterschied?

Natürlich macht es einen Unterschied. Header/Payload Ratio, Pipeline-Initialisierung, Blockgrösse, Paketverluste etc… kosten Zeit. Das einmal zu berechnen oder x100.000 geht auf Kosten der Zeit. RoCE hat mit „Beamen“ nichts zu tun.

 

[besterino]

@Dwayne_Johnson: Wenn Du über einen Linux-Server für SMB (Direct) Freigaben mit KSMBD nachdenkst, hab' ich noch keine Empfehlung. Ich hab zuletzt Ubuntu genommen, musst aber 'nen Custom Kernel basteln. Alles "Arch-based" scheidet m.E. als Server-OS kategorisch aus. Fedora habe ich noch nicht ausprobiert... hmmm... könnte ich ja eigentlich mal, wollte die Tage ja eh wieder RDMA-Netzwerk spielen gehen.

Allerdings interessiert mich mehr, wie etwaige Geschwindigkeitsvorteile mit vs. ohne RDMA aussehen und das würde ich erst einmal mit Windows Server als SMB-Server testen wollen - das funktioniert wenigstens zuverlässig...

Alternativ könnte ich mich mal reinfuchsen, ob nicht NFSoRDMA eine Alternative wäre (NVMe-of habe ich ja schonmal unter Windows mit dem Starwind-Ding hingefummelt - war aber nicht so prall).

Ansonsten, noch zur Performance @Dwayne_Johnson RDMA vs TCP/IP, allerdings auf Basis NFS und mit 100Gbit NICs, nicht 10Gbit, und auf beiden Seiten in voller Breite mit 16 PCIe Lanes:
2-3x higher bandwidth (128KB block size)
140% higher IOPS (8KB block size)
150% higher IOPS (2KB block size)

Quelle: https://developer.nvidia.com/blog/d...tem-performance-with-rdma-enabled-networking/

 

[Dwayne_Johnson]

Ich hab zuletzt Ubuntu genommen, musst aber 'nen Custom Kernel basteln

Darin bin ich der absolute "Profi" (nicht)
Den Tipp via TCP (anstatt SMB) hat mir auch @craxity gegeben - muss ich mal testen

Beitrag automatisch zusammengeführt: Heute um 17:57

Natürlich macht es einen Unterschied. Header/Payload Ratio, Pipeline-Initialisierung, Blockgrösse, Paketverluste etc… kosten Zeit. Das einmal zu berechnen oder x100.000 geht auf Kosten der Zeit. RoCE hat mit „Beamen“ nichts zu tun.

Schon ein einfacher Scan des NAS via SMB mit den zig Mio Files, dauert schon eine Ewigkeit

 

[gea]

Ich vermute es soll NFS statt SMB heißen
NFS und SMB sollten ähnlich schnell sein. NFS mit RDMA könnte unter Linux Vorteile haben da NFS da üblicher ist. NFS Ist halt was Authentifizierung, Authorisierung und plattformübergreifendes multiuser Verhalten (Locking) angeht, im Vergleich zu SMB weit unterlegen..

ps
Um einen ZFS Filer mit vielen Dateien auf mechanischen Platten extrem viel schneller zu machen, brauchts einen NVMe special vdev Mirror.

 

[craxity]

Ich vermute es soll NFS statt SMB heißen

Wenn es um meine Aussage geht, meinte ich rsync statt SMB. rsync hat keine Probleme mit dem TCP Congestion Control, das SMB so ausbremst.

 

[gea]

Rsync hat zwar weniger Overhead als SMB und überträgt nur Delta Daten weshalb es sich oft schneller "anfühlt", basiert aber auch auf tcp/ip wie normales SMB/NFS und ist damit rdma Alternativen genauso unterlegen. Für normalen NAS Einsatz ist rsync eh keine Option sondern ist da um zwei Ordner syncron zu halten, vor allem unter Linux - wobei SMB Multichannel+ robocopy multi-threading dafür auch nicht schlecht ist mit Windows.

 

[craxity]

basiert aber auch auf tcp/ip wie normales SMB/NFS und ist damit rdma Alternativen genauso unterlegen.

Das ist eine sehr unpräzise und im Ergebnis falsche Aussage. Auch wenn beide Übertragungsverfahren auf TCP aufbauen, nutzen sie TCP sehr unterschiedlich. Rsync baut pro Sitzung eine TCP-Verbindung auf und schickt alle Daten (und Steuerbefehle) über diese eine Verbindung als eine Art Stream. Im Gegensatz dazu baut SMB für jede Datei eine Verbindung auf. Dadurch bremst TCP Congestion Control SMB extrem aus, während TCP CC die Übertragungsrate mit rsync bis zum Maximum hochfahren kann.

 

[gea]

Ich bin kein Protokoll Spezialist und habe daher die Gemini KI um einen Kommentar zu schnellem rsync vs langsamen SMB over ip gebeten:
Im Ergebnis kann rsync schneller sein, ist dafür aber kein Ersatz für SMB bei einem NAS sondern ist für einen ganz anderen Anwendungsfall sinnvoll (Ordner-sync).

"Das ist eine weit verbreitete Beobachtung, die in der Praxis oft zu den beschriebenen Performance-Unterschieden führt, aber technisch nicht ganz präzise ist. Lass uns das "Fact-Checking" machen, um zu sehen, was wirklich hinter der TCP-Bremse steckt...

Spoiler: KI Check

1. Korrektur: SMB baut NICHT für jede Datei eine neue Verbindung auf​

Hier liegt der größte technische Irrtum in der Aussage:

• Realität: SMB baut eine TCP-Sitzung zum Server auf (Standardport 445). Über diese eine Verbindung werden alle Befehle und Daten "gemultiplext". Es wäre für das Betriebssystem extrem ineffizient, für jede Datei einen neuen TCP-Handshake (SYN, SYN-ACK, ACK) durchzuführen.
• Warum es sich so anfühlt: SMB ist ein Request-Response-Protokoll. Bei älteren SMB-Versionen oder schlechten Implementierungen wartet der Client oft auf eine Bestätigung ("Datei A erhalten"), bevor er den Befehl für "Datei B" schickt. Das erzeugt Pausen, die wie Verbindungsneuaufbaue wirken.

2. Der wahre Kern: "Stream" vs. "Chattiness"​

Deine Aussage trifft den Nagel auf den Kopf, wenn es um die Art der Kommunikation geht:

• rsync (Der Streamer): rsync ist darauf optimiert, die Leitung wie einen Wasserschlauch zu nutzen. Sobald der TCP-Algorithmus (Congestion Control) das "Window" vergrößert hat, schiebt rsync die Daten am Stück durch. TCP CC kann hier perfekt arbeiten, weil der Datenstrom nicht abreißt.
• SMB (Der Diskutierer): SMB muss für jede Datei Metadaten abfragen (Rechte, Zeitstempel, Größe). Bei vielen kleinen Dateien entstehen tausende winzige Pausen. Jedes Mal, wenn der Datenstrom kurz stockt, kann TCP CC nicht in den "High-Speed-Modus" schalten oder fällt sogar in den Slow Start zurück.

3. Wo die TCP Congestion Control SMB wirklich ausbremst​

Die Aussage hat recht, wenn man Latenz (Ping) mit einbezieht:

1. In einem Netzwerk mit hoher Latenz (z. B. VPN oder WAN) dauert jede Bestätigung bei SMB lange.
2. TCP CC "denkt" bei Verzögerungen oder minimalem Paketverlust oft, die Leitung sei verstopft, und drosselt die Rate.
3. Da SMB so viele kleine Bestätigungen braucht, "erholt" sich die TCP-Rate bei SMB viel langsamer als bei dem kontinuierlichen rsync-Stream.

4. Die moderne Lösung: SMB-Pipelining und Multichannel​

Um genau dieses Problem zu beheben, hat Microsoft SMB modernisiert:

• SMB Pipelining: Erlaubt es, viele Anfragen zu schicken, ohne auf die Antwort der vorherigen zu warten.
• SMB Multichannel: Hier werden (wie wir vorhin besprochen haben) tatsächlich mehrere TCP-Verbindungen gleichzeitig aufgebaut, um die TCP CC zu überlisten und die Bandbreite zu maximieren.

Fazit​

Die Aussage ist funktional richtig, aber technisch falsch begründet.

• Falsch: SMB baut keine neuen Verbindungen pro Datei auf.
• Richtig: Das Protokoll-Design von SMB (viele Metadaten-Stopps) verhindert, dass TCP Congestion Control die Leitung so effizient "fluten" kann wie rsync. rsync verhält sich gegenüber TCP einfach "kooperativer"."

 

[Techlogi]

@gea Kannst du den KI Text bitte in einen Spoiler packen?
thx

 

[craxity]

Im Ergebnis kann rsync schneller sein, ist dafür aber kein Ersatz für SMB bei einem NAS sondern ist für einen ganz anderen Anwendungsfall sinnvoll (Ordner-sync).

Bei kleinen Dateien ist rsync auch schneller als SMB Multichannel. Insbesondere, wenn man den daemon-Modus nutzt. Und wenn man Dateien kopieren will, ist es der gleiche Anwendungsfall.