[Sammelthread] 10Gbit Homenetzwerk

ok!
Werte kommen:

Interrupt Moderation: on off
" Rate: adaptive; extreme high low off

RSS Queues 1; 2; 4; 8

Rec buffers 128 - 4096 (hab ich scon rauf auf 1024;-)
Transmit Buffers 256 - 8192

hab in der Zwischenzeit mal das Server Bios auf PCIe Gen 3 eingestellt
Karte ist im 1. langen Slot (Grafikkarte)
NetIO ist sogar etwas schlechter geworden.. siehe #1981

und Get-NetAdapterHardwareInfo liefert immer noch PCIe 1.1
ist da am Mainboard was faul oder energy...mode?

- - - Updated - - -

erste Erfolge....:

receive + transmit Buffers auf BEIDEN Cards runter auf 512 und siehe da:
aber was bedeutet das??? brauch ich neue Maschinen ??

NETIO - Network Throughput Benchmark, Version 1.32
(C) 1997-2012 Kai Uwe Rommel

TCP connection established.
Packet size 1k bytes: 544.82 MByte/s Tx, 277.66 MByte/s Rx.
Packet size 2k bytes: 556.02 MByte/s Tx, 243.91 MByte/s Rx.
Packet size 4k bytes: 612.44 MByte/s Tx, 234.34 MByte/s Rx.
Packet size 8k bytes: 581.56 MByte/s Tx, 228.72 MByte/s Rx.
Packet size 16k bytes: 615.82 MByte/s Tx, 264.77 MByte/s Rx.
Packet size 32k bytes: 458.33 MByte/s Tx, 343.96 MByte/s Rx.

N:\1_1>netio -s

NETIO - Network Throughput Benchmark, Version 1.32
(C) 1997-2012 Kai Uwe Rommel

UDP server listening.
TCP server listening.
TCP connection established ...
Receiving from client, packet size 1k ... 527.44 MByte/s
Sending to client, packet size 1k ... 286.70 MByte/s
Receiving from client, packet size 2k ... 538.68 MByte/s
Sending to client, packet size 2k ... 253.75 MByte/s
Receiving from client, packet size 4k ... 612.34 MByte/s
Sending to client, packet size 4k ... 243.95 MByte/s
Receiving from client, packet size 8k ... 581.38 MByte/s
Sending to client, packet size 8k ... 238.14 MByte/s
Receiving from client, packet size 16k ... 615.62 MByte/s
Sending to client, packet size 16k ... 264.77 MByte/s
Receiving from client, packet size 32k ... 458.18 MByte/s
Sending to client, packet size 32k ... 343.95 MByte/s
Done.
TCP server listening.
listening (servermode) war der PC
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Also:

Interrupt Moderation reduziert die Interrupts und spart dadurch CPU-Ressourcen. Kann man ganz abschalten und dann die CPU-Last beobachten.
Die Interrupt Moderation Rate ist demnach die Einstellung wie aggressiv das gemacht wird.

Grundsätzlich: Je weniger Interrupt Moderation, desto mehr Durchsatz, aber desto höher auch die CPU-Last.

Die RSS Queues beeinflussen gleichermaßen die CPU-Last. Wenn der Default 1 war, dann stell mal auf 2. Wenn der Default 2 war lass ihn so, ich glaube nicht dass mehr als 2 Queues noch was bringen in so einem Setup.

Die Buffer geben an wie viel Netzwerktraffic gepuffert wird. Auch wenn es so aussieht, es ist keine Angabe in Byte. Je mehr man hier zulässt, desto mehr RAM wird belegt und desto besser wird die Performance. Bis zu einem gewissen Punkt natürlich, das geht nicht unendlich. Dass es besser wird wenn man den Wert senkt ist sehr merkwürdig. Du hast nicht zufällig verschiedene Dinge auf einmal geändert?

Und natürlich muss man die Einstellungen auf beiden Seiten vornehmen.
 
Version 1.1 oh jeeh - das wird der Fehler sein!! ?? aber wie ändere ich das?
Nein, das passt schon. Es gibt da offenbar nur die Werte 1.0 oder 1.1. Siehe MSFT_NetAdapterHardwareInfoSettingData class (Windows)

--> im Manual vom Z97-Deluxe steht: slot2 PCIe 2.0/3.0 x 16_1 Steckplatz hmm

Board = Asus Z97-Deluxe
dlcdnet.asus.com/pub/ASUS/mb/LGA1150/Z87-DELUXE/G9061_Z97-DELUXE.pdf

am PC läuft Win7/64 gäbs da einen ähnlichen Befehl?
- CPU-Z > Tools > Save Report as TXT
- Im Report suchen nach "Ethernet Controller"
Code:
PCI capability

	Caps class		PCI Express
	Caps offset		0x60
	Device type		PCI-E Endpoint Device
	Port			8
	Version			2.0
	Link width		4x (max 8x)
Version ist hier tatsächlich die PCIe-Version.
Link width gibt die verwendeten Lanes an.
Link Speed fehlt zwar explizit, ist aber bei PCIe 2.0 5GT/s.
NetIO:

NETIO - Network Throughput Benchmark, Version 1.32
(C) 1997-2012 Kai Uwe Rommel

TCP connection established.
Packet size 1k bytes: 259.50 MByte/s Tx, 272.15 MByte/s Rx.
Packet size 2k bytes: 209.72 MByte/s Tx, 249.67 MByte/s Rx.
Packet size 4k bytes: 206.46 MByte/s Tx, 234.97 MByte/s Rx.
Packet size 8k bytes: 210.92 MByte/s Tx, 225.79 MByte/s Rx.
Packet size 16k bytes: 227.14 MByte/s Tx, 264.13 MByte/s Rx.
Packet size 32k bytes: 292.49 MByte/s Tx, 344.30 MByte/s Rx.

UDP server listening.
TCP server listening.
TCP connection established ...
Receiving from client, packet size 1k ... 259.46 MByte/s
Sending to client, packet size 1k ... 281.23 MByte/s
Receiving from client, packet size 2k ... 209.65 MByte/s
Sending to client, packet size 2k ... 257.88 MByte/s
Receiving from client, packet size 4k ... 199.80 MByte/s
Sending to client, packet size 4k ... 242.73 MByte/s
Receiving from client, packet size 8k ... 203.98 MByte/s
Sending to client, packet size 8k ... 235.68 MByte/s
Receiving from client, packet size 16k ... 227.07 MByte/s
Sending to client, packet size 16k ... 264.13 MByte/s
Receiving from client, packet size 32k ... 292.40 MByte/s
Sending to client, packet size 32k ... 344.29 MByte/s
Done.
Da sollte tatsächlich noch deutlich mehr drin sein.

Schon geprüft, ob die ausgehandelte Verbindungsgeschwindigkeit überall 10G ist. Also LEDs am Switch und in Windows bei den Adaptereigenschaften "Status"?
 
wow jetzt läuft sich das ding warm :-)
@DunklerRabe: "Interrupt Moderation reduziert die Interrupts und spart dadurch CPU-Ressourcen. Kann man ganz abschalten"
auf beiden abgeschsaltet:

D:\1_1>netio -t garfield

NETIO - Network Throughput Benchmark, Version 1.32
(C) 1997-2012 Kai Uwe Rommel

TCP connection established.
Packet size 1k bytes: 542.02 MByte/s Tx, 644.82 MByte/s Rx.
Packet size 2k bytes: 837.87 MByte/s Tx, 919.91 MByte/s Rx.
Packet size 4k bytes: 1.149 GByte/s Tx, 548.51 MByte/s Rx.
Packet size 8k bytes: 967.70 MByte/s Tx, 952.62 MByte/s Rx.
Packet size 16k bytes: 1.127 GByte/s Tx, 666.83 MByte/s Rx.
Packet size 32k bytes: 788.46 MByte/s Tx, 674.61 MByte/s Rx.
Done.

netio -s

NETIO - Network Throughput Benchmark, Version 1.32
(C) 1997-2012 Kai Uwe Rommel

TCP server listening.
UDP server listening.
TCP connection established ...
Receiving from client, packet size 1k ... 541.76 MByte/s
Sending to client, packet size 1k ... 667.18 MByte/s
Receiving from client, packet size 2k ... 837.74 MByte/s
Sending to client, packet size 2k ... 950.60 MByte/s
Receiving from client, packet size 4k ... 1.110 GByte/s
Sending to client, packet size 4k ... 567.44 MByte/s
Receiving from client, packet size 8k ... 967.54 MByte/s
Sending to client, packet size 8k ... 984.10 MByte/s
Receiving from client, packet size 16k ... 1.127 GByte/s
Sending to client, packet size 16k ... 666.83 MByte/s
Receiving from client, packet size 32k ... 788.21 MByte/s
Sending to client, packet size 32k ... 674.60 MByte/s
Done.

was soll ich als nächstes in Angriff nehmen :-)
Ihr seid alle einsame Spitze :-)


TCP server listening.
 
Zuletzt bearbeitet:
Ich hatte mir ebenfalls 2 Asus XG-C100C und den XG-U2008 gekauft. Ich habe in dem anderen 10GB Thread dazu etwas geschrieben.
Bei mir hatte ich ebenfalls mit den Einstellungen im Treiber getestet. Insbesondere das Deaktivieren der Interrupt Moderation brachte den erwarteten Durchsatz.
Wenn Du bei beiden Karten die Jumbo Packets auf 9014 Bytes stellst, bekommst Du in beide Richtungen volle Geschwindigkeit auch über den XG-U2008.

Copy.jpg
 
@myBerg @DunklerRabe
also was ich bis jetzt geändert habe:
Receive Buffers auf 512 - hier könnte ich wieder hochschrauben, oder?
Interrupt Moderation abgeschaltet
10GB fest eingestellt
Jumbo auf 90xx

der XG-U2008 scheint es auch zu "machen" wenngleich er sehr heiss wird... (hat aber auch 30° im Serverraum:)

nur beim Filecopy bleiben die ca. 300 MBytes /s trotz beidseitig SSD's hmm...
NetIO liefert super Durchsatz, oder?

ich muss immer den Server neu starten, damit eine Änderung in den Einstellungen greift...
und die Karten brauchen fast genau 20 sec. bis das Netzwerk steht.
hoffe mal dass da bald ein neuer Treiber kommt...

durch den XG-U2008 wird hoffentlich auch das übrige 1GB Netz schneller (gleichzeitige Zugriffe zum Server, oder?)

also jetzt freut mich die Umstellung - wollte schon alles wieder zurückschicken...
 
Transmit und Receive Buffer solltest du gleichmäßig und auf beiden Systemen ändern. Ob und wie viel das bringt musst du mal testen, es wird auch davon abhängen wie hoch du die schraubst. Während du das machst solltest du die Speicherauslastung des Systems betrachten. Da können schnell mal 20 GB zusammenkommen und wenn das System dann nicht genug Speicher hat ist das natürlich sehr kontraproduktiv.

Die reale Bandbreite wird wohl von den SSDs limitiert werden, insbesondere wenn es kleine Modelle sind. Am schnellsten geht es wohl noch wenn du von der 850 Evo liest und auf die 850 Pro schreibst. Das Ergebnis wird nicht in alle Richtungen gleich sein in Abhängigkeit davon wie die Raids implementiert sind und ob auf die 850 Evo geschrieben wird.
 
Zuletzt bearbeitet:
ja genau so ist es:
wenn ich auf! den Server kopiere ist ja das Raid (nur Spiegelung) der limtierende Faktor, da gehts ab 16GB voll runter - muss erst die Datenplatten gegen SSD's tauschen - jetzt wo es so schön läuft...

soll ich an den RSS Queues was einstellen (default = 4) möglich 1 - 8 ?
Buffers bin ich grad dabei...

noch eine Frage:
Netio ist unsymmetrisch:

vom PC!! aus aufgerufen (also der PC = Server bei dieser Messung)
N:\1_1>netio -s

NETIO - Network Throughput Benchmark, Version 1.32
(C) 1997-2012 Kai Uwe Rommel

TCP server listening.
UDP server listening.
TCP connection established ...
Receiving from client, packet size 1k ... 530.49 MByte/s
Sending to client, packet size 1k ... 776.84 MByte/s
Receiving from client, packet size 2k ... 946.83 MByte/s
Sending to client, packet size 2k ... 950.75 MByte/s
Receiving from client, packet size 4k ... 1.108 GByte/s
Sending to client, packet size 4k ... 929.21 MByte/s
Receiving from client, packet size 8k ... 1.077 GByte/s
Sending to client, packet size 8k ... 651.66 MByte/s
Receiving from client, packet size 16k ... 1.101 GByte/s
Sending to client, packet size 16k ... 1.149 GByte/s
Receiving from client, packet size 32k ... 1.153 GByte/s
Sending to client, packet size 32k ... 1.147 GByte/s
Done.

liegt das an den Mainboards / CPU's ?
 
Zuletzt bearbeitet:
4 Queues sind mehr als genug, ich glaube nicht, dass 8 noch was ändert.

Die NetIo-Werte liegen innerhalb der Messtoleranz, du hast nur einen Ausreißer bei 8k:
Receiving from client, packet size 8k ... 1.077 GByte/s
Sending to client, packet size 8k ... 651.66 MByte/s

Ist das reproduzierbar? Wenn nein, dann kann man es eh vergessen. Wenn ja, mhm, seltsam, wird dich aber in der Praxis erstmal nicht weiter limitieren.
 
Danke für die super Erklärungen!

Trans: 1024
Rec: 256
liefert komischwerweise die besten reproduzierbaren Ergebnisse

jetzt noch die Queues dann kommt nochmal ein NetIO Ergebnis

es wird nicht mehr besser, bei der 2.ten + folgenden Messung ist es geringfügig schlechter.... (Karte zu heiss?:)

TCP server listening.
UDP server listening.
TCP connection established ...
Receiving from client, packet size 1k ... 530.27 MByte/s
Sending to client, packet size 1k ... 710.46 MByte/s
Receiving from client, packet size 2k ... 980.92 MByte/s
Sending to client, packet size 2k ... 904.97 MByte/s
Receiving from client, packet size 4k ... 1.134 GByte/s
Sending to client, packet size 4k ... 958.82 MByte/s
Receiving from client, packet size 8k ... 1.099 GByte/s
Sending to client, packet size 8k ... 845.07 MByte/s
Receiving from client, packet size 16k ... 961.28 MByte/s
Sending to client, packet size 16k ... 1.145 GByte/s
Receiving from client, packet size 32k ... 1.154 GByte/s
Sending to client, packet size 32k ... 1.150 GByte/s
Done.
TCP server listening.
 
Zuletzt bearbeitet:
Möglich, 10G-Karten aus dem Serverbereich sollte man normalerweise aktiv kühlen. Wie es bei denen hier ist weiß ich nicht, musst du mal schauen was Asus in den Specs dazu sagt.
 
Jetzt hab ich nur noch das Problem, dass die Karte 20-30 sec. braucht bis eine Verbindung zum Server steht.
Dadurch kommt beim starten immer: keine Netzlaufwerke gefunden usw...

wenn ich sie de+aktiviere:
15 sec.: Netzwerkkabel wurde entfernt
15 sec.: Netzwerkidentifizierung (DHCP via Dom Server)

hab den PC extra nochmal ins AD gehängt

Karte initialisiert aber beim Server genausolang.

die Karten werden nur warm nicht heiss - würde also passen...
 
ist die Netzwerkgeschwindigkeit auf "Automatisch" ?
Kann man die festnageln auf 10Gb/s ?
 
@thb

benötigen Deine beiden XG-C100C auch so lange zum initialisieren?
wenn du sie beispielsweise deaktivierst und wieder aktivierst
hab da bestimmt 2 Montagsausgaben erwischt...
 
Ja, leider nicht zu vergleichen mit der Initialisierung des Intel OnBoard LAN.
Das dauert bei meinen Karten ca. 18-20s. (kein DHCP, feste IP). Wenn ich Linkspeed auf 10G setzte dauert es etwas länger als bei automatischer Aushandlung.
 
Hat schon jemand Verbrauchsmessungen mit und ohne die XG-C100C gemacht? Auch würde mich interessieren, welche Package-C-States damit erreicht werden können.
 
20 sec. Initialisieren XG-C100C
ob da ein (irgendwann mal kommendes) Treiberupdate helfen wird?
Mist, jetzt wo der Durchsatz so gut wäre.
Ist halt nur weil die Netzlaufwerke nicht schnell genug verbinden...
 
Ich warte meistens bei der Anmeldung kurze Zeit bis die Netzwerkverbindung steht. Dann gibt es keine Fehlermeldung zu den verbundenen Netzlaufwerken.
Meistens habe ich den PC aber im Standby (Server läuft 24h). Da sehe ich dann zwar kurz die Unterbrechung der Netzverbindung, es gibt jedoch keine Meldung. Insoweit stört mich die lange Initialisierungszeit der Karte nicht allzu sehr. Ich hoffe aber auch, dass dieses mit einem zukünftigen Treiberupdate verbessert wird.
 
ja bei manueller Anmeldung geht das einwandfrei - ich hab das autologon (technet) gesetzt
und da ist's durch die SSD zu schnell oder besser: die Ausus viel! zu langsam...
die Karte haben sie mit heisser Nadel gestrickt... ich glaube nicht, dass man das nicht
hätte berücksichtigen können.
es gibt x Beiträge über diesen Sachverhalt - aber keiner geht bei mir:
Windows soll mit Anmeldung warten bis das Netzwerk steht. - aber jetzt wirds OT.
 
Ich rate zur Entspannung. Das ist auch bei anderen Karten bisweilen so (Intel), und die Fehlermeldung kann man doch ganz entspannt ignorieren?
 
Im Anschluss an die Postings zum Geschwindigkeitstuning von 10 GBit unter Windows mein Erfahrungsbericht dazu:

Ich habe hier auch einen ASUS XG-U2008, um den Rechner im Büro und ein paar weitere Geräte mit dem zentralen Switch im Keller zu verbinden, an dem wiederum 2 Server mit 10G hängen.

Mit iPerf gemessene Geschwindigkeit zwischen den beiden Servern am zentralen Switch (jeweils 1x Intel x520): 9.65 Gbits/sec

Anfängliche Geschwindigkeit vom Büro aus (Win 10, Intel x540, via ASUS Switch) war 3,5 GBit/s.

PCIe Slot Daten:

Code:
	Caps class		PCI Express
	Caps offset		0xA0
	Device type		PCI-E Endpoint Device
	Port			0
	Version			2.0
	Link width		8x (max 8x)

Durch Aktivieren von Jumbo Packets ging die Rate auf 4,5 GBit/s hoch. Dann habe ich dank der Tipps hier im Thread die Interrupt-Drosselung auf dem Client abgestellt, das brachte die Geschwindigkeit auf 6,5 GBit/s. Anschließend habe ich dem Win-Rechner noch Langeweile verordnet (CPU-intensive Programme beendet), damit ging die Geschwindigkeit bei 8 GBit/s. Flusssteuerung deaktiveren brachte die Geschwindigkeit auf 8,2 GBit/s.

Änderung der Empfangs- und Sendepuffer von 512 auf 1024 hatte nur eine größere Variabilität in den gemessenen Geschwindigkeiten (8.1 bis 8.25 GBit/s) zur Folge, aber keine Geschwindigkeitssteigerung.
Reduzierung der RSS-Warteschlangen von 8 (Standard) auf 2 war ohne merkliche Auswirkung auf die Geschwindigkeit.

D.h. ich gehe mal davon aus, dass ich mehr als 8,2 GBit/s unter Windows aus der Karte nicht herausholen kann (die Karte steckte vorher im Server, da waren die Werte ähnlich denen der X520 jetzt). Den ASUS Switch aus der Kette herauszunehmen, hatte keinen Einfluss auf die Geschwindigkeit. Vermutlich müsste ich nun noch einen Server ins Büro verfrachten, um einen Einfluss der Kabel auszuschließen, aber das ist mir der Spaß nicht wert. :)
 
Normalerweise sollte es schon möglich sein annähernd 10G zu erreichen, ~8G ist etwas knapp. Hat einer der beteiligten Rechner jetzt vielleicht einen Engpass bei CPU oder RAM? Hast du die X540 ordentlich gekühlt?
 
Bei IPerf muss man mehrere "streams" aufmachen, dann kommt man auch noch höher.

Taugt wie gesagt m.E. nicht so perfekt zur Geschwindigkeitsmessung - in realen Anwendungen (file copy) war die speed dann trotzdem da.

Hab da auch länger mit rumgewürgt, erst um heraus zu finden wo der Engpass ist (Storage vs. Netz) um eben dann rauszufinden, dass IPerf unter Windows eher unzuverlässige Ergebnisse liefert: 10G-Netzwerk; Datentransferoptimierung WinLinux/BSD/OS/etc.
 
In der Tat, das war es. :banana:

Win-Client, 1 Streams:
Code:
[  9] local 192.168.1.74 port 5001 connected with 192.168.1.3 port 63637
[  9]  0.0-10.0 sec  9.00 GBytes  7.73 Gbits/sec

Win-Client, 5 Streams:
Code:
[  5] local 192.168.1.74 port 5001 connected with 192.168.1.3 port 63618
[  6] local 192.168.1.74 port 5001 connected with 192.168.1.3 port 63614
[  4] local 192.168.1.74 port 5001 connected with 192.168.1.3 port 63616
[  7] local 192.168.1.74 port 5001 connected with 192.168.1.3 port 63615
[  8] local 192.168.1.74 port 5001 connected with 192.168.1.3 port 63617
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0-10.0 sec  1.93 GBytes  1.66 Gbits/sec
[  6]  0.0-10.0 sec  1.94 GBytes  1.66 Gbits/sec
[  4]  0.0-10.0 sec  2.86 GBytes  2.45 Gbits/sec
[  7]  0.0-10.0 sec  2.85 GBytes  2.45 Gbits/sec
[  8]  0.0-10.0 sec  1.93 GBytes  1.66 Gbits/sec
[SUM]  0.0-10.0 sec  11.5 GBytes  9.87 Gbits/sec

Linux-Client (anderer Server), 1 Stream:
Code:
[  9] local 192.168.1.74 port 5001 connected with 192.168.1.24 port 50334
[  9]  0.0-10.0 sec  11.4 GBytes  9.78 Gbits/sec
 
Guten Abend,

Ich würde gerne einiges bei mir auf 10 Gigabit aufrüsten

Nun gibt es einmal die Überlegung auf 10Gigabit über RJ45 Kupferkabel zu setzen 10GB-T
Oder über SFP+ leider habe ich da wenig Ahnung...
Wesentlich preiswerter wäre über SFP+

Kleine Gegenüberstellung.

Netzwerkkarte:
10GBbase-T 110€ -neu
SFP+ - 30€ Gebraucht allerdings

Switch:
10GBBase-T rund 500€ -Neu
10GB 4X SFP+ ports 250€

Kabel
10GB BAse-T wenige Euros
SFP+ da kenne ich mich noch nicht so aus, aber kosten schon ein paar mehr.

Nun zu meinen Fragen, ich denke ich werde SFP+ nehmen.
Folgende Komponenten hatte ich angedacht:

Netzwerkkarten:
Mellanox ConnectX-2 PCIe x8 NIC 10 Gigabit 10GBe SFP+ Single Port Server Adapter | eBay
Mellanox ConnectX-2 PCIe x8 NIC 10Gigabit 10GBe SFP+ Dual Port Server 518001-001 | eBay
oder als zweier Paket:
10G Netzwerk Kit 2x Mellanox ConnectX 10Gigabit NIC 10GBe 1x 3m SFP+ Cisco Kabel | eBay

Dazu die Frage, habe nicht soo viel gefunden, weiß das einige User diese im einsatz haben bzw. die Mellanox X2 funktionieren diese Problemlos mit 1. Windows 10 64Bit? (Treiber habe ich auf der Mellanox seite keine gefunden) 2. Mit der DS1517+? 3. Mit Windows Server 2016?

Welches Kabel kann ich verwenden? Das beiligende bei dem Paket sollte ja gehen, aber wenn ich 5m oder mehr bräuchte welches wäre da das richtige?
Cisco 5m SFP+ SFP Kabel 10GB 10 Gigabit Twinax Twinaxial Cable SFP-H10GB-CU5M | eBay
cisco SFP-H10GB-ACU10M-C SFP+ KupferTwinax kompatibel Kabel | eBay

Wären beide Kompatibel mit den Mellanox karten?

Das sind ja beides DAC kabel wenn ich mich nicht iree, also über Kupfer und nciht glas? Somit auch flexibler und nicht so empflindlich, stimmt das?
Sind diese Kabel nur für die Direktverbindung zwischen zwei Netzwerkkarten oder kann ich mit einem Kabel von der Netzwerkkarte an einen Switch gehen und von einem Switch an die andere Karte, würde das gehen?

dachte an diesen:
https://geizhals.de/tp-link-t1700g-....html?hloc=at&hloc=de&hloc=pl&hloc=uk&hloc=eu

Klappt das alles, Switch 4X 10Gigabit mit den Cisco Kabeln und den günstigen Mellanox Kabeln?

Würde mich sehr freuen wenn mir jemand helfen kann, der das so im Einsatz hat und optimalerweise genau die von mir verlinkten Produkte mit den angegeben Betriebssystemen laufen hat.

Die 10Gigabit SFP+ Karte von Synology ist ja schon sehr sehr teuer finde ich....

Viele Grüße und vielen Dank im Voraus!
 
Die Cisco-Kabel funktionieren mit den Mellanox-Karten ohne Probleme. Auch lassen sich die ConnectX-2 unter Windows 10 und 2016 betreiben, was man unter anderem im servethehome-Forum lesen kann.
Mit der DS1517+ wird es nicht funktionieren, da die Treiber nicht mit dem OS (DSM) mitgeliefert werden. Intel X520-DA2 wäre da die günstigste Alternative (siehe bucht).
DAC-Kabel nutzen Kupferkabel als Leiter. Funktionieren selbstversändlich an Switchen.
 
Zuletzt bearbeitet:
Die Synology-Karte war einige Zeit sogar recht günstig zu haben: 95 Euro neu. Die hat den Tehuti-Chip. Daher könnte eine ggf andere Tehuti-Karte treiberseitig funktionieren.
 
Guten Mittag,
danke euch für die schnelle Rückmeldung!
Das sind ja gute Nachrichten.
Dann wird es wohl die Mellanox Variante werden.
Habe auch gesehen, dass die Mellanox wohl doch gehen soll in der Synology, mal sehen ob ich das teste, kann ja nichts kaputt gehen, oder ob ich gleich die Intel kaufe.
Ist die Intel denn auch kompatibel mit den Steckern bzw. Kabeln?
Die Intel ist ja auch nicht soo viel teurer.

Habe auch heute ein Video gefunden wo der oben verlinkte Switch drin vor kam, das soll alles kompatibel sein, dass ist wirklich super :)
Ich denke ich werde für den Start mal 2 Karten kaufen.

Schade, das die Synology jetzt wieder so teuer geworden ist :/

Habt ihr Sonst noch tipps?
 
Hallo, möchte in nächster Zeit auch auf 10G gehen, habe mich da auf SFP+ festgelegt.
Hätte da eine Verständnisfrage:
Kann man über DAC zwei unterschiedliche Hersteller DIREKT miteinander verbinden, also z.B. eine Intel X710-D2 und eine Mellanox ConnectX-2?
 
Zuletzt bearbeitet:
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