33
NETIO - Performancefragen
Servus zusammen,
Engpässen im Netzwerk auf der Spur bin ich heute mit NETIO am testen gewesen.
Sehr enttäuschend, oder ?
Blech: Server 2016 installierte Hyper-V-Rolle hat u.a. eine Mellanox-X2 SFP+, Xeon 2620v3, 64GB RAM
NAS QNAP TS-563 hat eine QNAP-10GBE-SFP+-Karte
Verbunden sind beide per Kabel, kein Switch dazwischen.
Vom Server auf das NAS: (Warum empfängt er deutlich mehr, als er senden kann?)
Server auf die IP der lokalen Mellanox:
Eine VM, die auf dem gleichen Blech läuft:
Ein Test mit der 1GBE-Verbindung zeigt normale Werte:
Kann mir jemand erklären, wieso da so unterschiedliche Werte dabei rauskommen ?
Treiber der NICs sind auf dem aktuellsten Stand.
Grüße, Henere
Engpässen im Netzwerk auf der Spur bin ich heute mit NETIO am testen gewesen.
Sehr enttäuschend, oder ?
Blech: Server 2016 installierte Hyper-V-Rolle hat u.a. eine Mellanox-X2 SFP+, Xeon 2620v3, 64GB RAM
NAS QNAP TS-563 hat eine QNAP-10GBE-SFP+-Karte
Verbunden sind beide per Kabel, kein Switch dazwischen.
Vom Server auf das NAS: (Warum empfängt er deutlich mehr, als er senden kann?)
Packet size 1k bytes: 333.54 MByte/s Tx, 651.31 MByte/s Rx.
Packet size 2k bytes: 390.64 MByte/s Tx, 739.66 MByte/s Rx.
Packet size 4k bytes: 431.80 MByte/s Tx, 750.56 MByte/s Rx.
Packet size 8k bytes: 461.40 MByte/s Tx, 742.01 MByte/s Rx.
Packet size 16k bytes: 481.40 MByte/s Tx, 758.96 MByte/s Rx.
Packet size 32k bytes: 487.41 MByte/s Tx, 753.96 MByte/s Rx.
Done.Server auf die IP der lokalen Mellanox:
Packet size 1k bytes: 179.47 MByte/s Tx, 182.01 MByte/s Rx.
Packet size 2k bytes: 228.46 MByte/s Tx, 218.68 MByte/s Rx.
Packet size 4k bytes: 326.75 MByte/s Tx, 311.61 MByte/s Rx.
Packet size 8k bytes: 466.41 MByte/s Tx, 448.16 MByte/s Rx.
Packet size 16k bytes: 588.76 MByte/s Tx, 585.88 MByte/s Rx.
Packet size 32k bytes: 784.32 MByte/s Tx, 755.45 MByte/s Rx.
Done.Eine VM, die auf dem gleichen Blech läuft:
Packet size 1k bytes: 274.70 MByte/s Tx, 251.06 MByte/s Rx.
Packet size 2k bytes: 299.51 MByte/s Tx, 241.84 MByte/s Rx.
Packet size 4k bytes: 392.68 MByte/s Tx, 335.01 MByte/s Rx.
Packet size 8k bytes: 350.72 MByte/s Tx, 526.53 MByte/s Rx.
Packet size 16k bytes: 375.85 MByte/s Tx, 588.62 MByte/s Rx.
Packet size 32k bytes: 402.49 MByte/s Tx, 633.03 MByte/s Rx.
Done.Ein Test mit der 1GBE-Verbindung zeigt normale Werte:
Receiving from client, packet size 1k ... 109.43 MByte/s
Sending to client, packet size 1k ... 99.48 MByte/s
Receiving from client, packet size 2k ... 109.97 MByte/s
Sending to client, packet size 2k ... 110.44 MByte/s
Receiving from client, packet size 4k ... 111.53 MByte/s
Sending to client, packet size 4k ... 112.43 MByte/s
Receiving from client, packet size 8k ... 111.60 MByte/s
Sending to client, packet size 8k ... 112.19 MByte/s
Receiving from client, packet size 16k ... 111.79 MByte/s
Sending to client, packet size 16k ... 112.45 MByte/s
Receiving from client, packet size 32k ... 112.12 MByte/s
Sending to client, packet size 32k ... 112.88 MByte/s
Done.
TCP server listening.Kann mir jemand erklären, wieso da so unterschiedliche Werte dabei rauskommen ?
Treiber der NICs sind auf dem aktuellsten Stand.
Grüße, Henere
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 385290
Url: https://administrator.de/forum/netio-performancefragen-385290.html
Ausgedruckt am: 19.04.2025 um 16:04 Uhr
33 Kommentare
Neuester Kommentar
Moin,
zumindest das erste ist ggf. einfach: Je nach deinem Systemaufbau. Mein NAS hat z.B. eine SSD als Cache -> damit kann die natürlich gut was empfangen. Beim Lesen ist der Cache aber natürlich nutzlos wenn es unterschiedliche Dateien sind -> dann bin ich auf die (langsameren) Disks angewiesen. Im dümmsten Fall (je nach Test-Zeitraum) schiesst hier sogar die SSD noch quer - ich mache den Lesetest aber gleichzeitig ist der SSD-Cache noch am zurückschreiben.
Von daher ist das halt abhängig von deiner Umgebung, kann aber durchaus normal sein.
Dasselbe gilt bei deinen lokalen Tests: Deine Festplatten müssen ja jetzt lesen und schreiben gleichzeitig -> da es zwar x VMs gibt aber eben (vermutlich) nur ein Storage-System. Im dümmsten Fall ist das sogar per 10 GBit angebunden - und damit misst du dann eben wieder eigentlich nur die Performance deines NAS-Systems.
zumindest das erste ist ggf. einfach: Je nach deinem Systemaufbau. Mein NAS hat z.B. eine SSD als Cache -> damit kann die natürlich gut was empfangen. Beim Lesen ist der Cache aber natürlich nutzlos wenn es unterschiedliche Dateien sind -> dann bin ich auf die (langsameren) Disks angewiesen. Im dümmsten Fall (je nach Test-Zeitraum) schiesst hier sogar die SSD noch quer - ich mache den Lesetest aber gleichzeitig ist der SSD-Cache noch am zurückschreiben.
Von daher ist das halt abhängig von deiner Umgebung, kann aber durchaus normal sein.
Dasselbe gilt bei deinen lokalen Tests: Deine Festplatten müssen ja jetzt lesen und schreiben gleichzeitig -> da es zwar x VMs gibt aber eben (vermutlich) nur ein Storage-System. Im dümmsten Fall ist das sogar per 10 GBit angebunden - und damit misst du dann eben wieder eigentlich nur die Performance deines NAS-Systems.
Das ist die Auswertung von NETIO. Da ist m.W. nach keinerlei HDD / Storage im Spiel.
Zitat von @maretz:
Moin,
zumindest das erste ist ggf. einfach: Je nach deinem Systemaufbau. Mein NAS hat z.B. eine SSD als Cache -> damit kann die natürlich gut was empfangen. Beim Lesen ist der Cache aber natürlich nutzlos wenn es unterschiedliche Dateien sind -> dann bin ich auf die (langsameren) Disks angewiesen. Im dümmsten Fall (je nach Test-Zeitraum) schiesst hier sogar die SSD noch quer - ich mache den Lesetest aber gleichzeitig ist der SSD-Cache noch am zurückschreiben.
Moin,
zumindest das erste ist ggf. einfach: Je nach deinem Systemaufbau. Mein NAS hat z.B. eine SSD als Cache -> damit kann die natürlich gut was empfangen. Beim Lesen ist der Cache aber natürlich nutzlos wenn es unterschiedliche Dateien sind -> dann bin ich auf die (langsameren) Disks angewiesen. Im dümmsten Fall (je nach Test-Zeitraum) schiesst hier sogar die SSD noch quer - ich mache den Lesetest aber gleichzeitig ist der SSD-Cache noch am zurückschreiben.
Netio mißt den Netzwerkdurchsatz, nicht den Durchsatz zum Massenspeicher. Von daher ist diese Erklrärung unzutreffend.
> Von daher ist das halt abhängig von deiner Umgebung, kann aber durchaus normal sein.
Das gilt immer, daß es von der lokalen Umgebung ist.
lks
Zitat von @Henere:
Das ist die Auswertung von NETIO. Da ist m.W. nach keinerlei HDD / Storage im Spiel.
Das ist die Auswertung von NETIO. Da ist m.W. nach keinerlei HDD / Storage im Spiel.
hast Du direkt ohne weitere geräte im Netz gemessen, also die jeweligen Geräte direkt miteinander ohne switch verbunden oder war Deine ganze Infrastruktur gleichzeitig aktiv?
lks
PS:
Ich tippe mal, daß die betroffene Kiste trotz GBit-Interface nicht die "Infrastruktur" hinter dem Interface hat, auch tatsächlich die Geschwindigkeit zu verarbeiten. z.B. Engpaß zwischen PCI-Bus und Netzwerkcip.
Oder etwas ist in Deiner Infrastruktur, daß die Werte beeinflußt. ißt mal direkt ohn eweiter Infrastruktur zwischendrin.
Hallo,
Mal geschaut wie z.B. RSS (Receive Side Scaling) und andere Parameter eingestellt sein müssen damit du in beiden Richtungen deine Theoretischen 1250 MByte/s auch nur annähernd erreichen kannst? Dein gemessener Wert von Packet size 32k bytes: 784.32 MByte/s Tx, 755.45 MByte/s Rx. sind grad mal an die 80% dran. Bei GBit/s NICS gab es auch mal das Problem das eine Seite des Transfers nur ungefaähr die hälfte von dem konnte was in der anderen Richtung möglich war. RSS und diverse andere Parameter mussten je nach OS angepasst werden, manchmal half nur eine andere NIC.
Gruß,
Peter
Mal geschaut wie z.B. RSS (Receive Side Scaling) und andere Parameter eingestellt sein müssen damit du in beiden Richtungen deine Theoretischen 1250 MByte/s auch nur annähernd erreichen kannst? Dein gemessener Wert von Packet size 32k bytes: 784.32 MByte/s Tx, 755.45 MByte/s Rx. sind grad mal an die 80% dran. Bei GBit/s NICS gab es auch mal das Problem das eine Seite des Transfers nur ungefaähr die hälfte von dem konnte was in der anderen Richtung möglich war. RSS und diverse andere Parameter mussten je nach OS angepasst werden, manchmal half nur eine andere NIC.
Gruß,
Peter
Zitat von @Lochkartenstanzer:
hast Du direkt ohne weitere geräte im Netz gemessen, also die jeweligen Geräte direkt miteinander ohne switch verbunden oder war Deine ganze Infrastruktur gleichzeitig aktiv?
hast Du direkt ohne weitere geräte im Netz gemessen, also die jeweligen Geräte direkt miteinander ohne switch verbunden oder war Deine ganze Infrastruktur gleichzeitig aktiv?
Das NAS hängt ohne Switch am SFP+ Kabel was zur Mellanox im Server geht.
lks
PS:
Ich tippe mal, daß die betroffene Kiste trotz GBit-Interface nicht die "Infrastruktur" hinter dem Interface hat, auch tatsächlich die Geschwindigkeit zu verarbeiten. z.B. Engpaß zwischen PCI-Bus und Netzwerkcip.
PS:
Ich tippe mal, daß die betroffene Kiste trotz GBit-Interface nicht die "Infrastruktur" hinter dem Interface hat, auch tatsächlich die Geschwindigkeit zu verarbeiten. z.B. Engpaß zwischen PCI-Bus und Netzwerkcip.
Der Mellanox steckt auf einem PCIe3.0 x8.
Oder etwas ist in Deiner Infrastruktur, daß die Werte beeinflußt. Miß mal direkt ohne weitere Infrastruktur zwischendrin.
Da war nix weiter dazwischen. Ist bei Localhost auch schwer da nen Switch rein zu bringen.
Gleiches bei dem NETIO auf die eigene IP.Henere
Zitat von @Pjordorf:
Hallo,
Mal geschaut wie z.B. RSS (Receive Side Scaling) und andere Parameter eingestellt sein müssen damit du in beiden Richtungen deine Theoretischen 1250 MByte/s auch nur annähernd erreichen kannst? Dein gemessener Wert von Packet size 32k bytes: 784.32 MByte/s Tx, 755.45 MByte/s Rx. sind grad mal an die 80% dran. Bei GBit/s NICS gab es auch mal das Problem das eine Seite des Transfers nur ungefaähr die hälfte von dem konnte was in der anderen Richtung möglich war. RSS und diverse andere Parameter mussten je nach OS angepasst werden, manchmal half nur eine andere NIC.
Gruß,
Peter
Hallo,
Mal geschaut wie z.B. RSS (Receive Side Scaling) und andere Parameter eingestellt sein müssen damit du in beiden Richtungen deine Theoretischen 1250 MByte/s auch nur annähernd erreichen kannst? Dein gemessener Wert von Packet size 32k bytes: 784.32 MByte/s Tx, 755.45 MByte/s Rx. sind grad mal an die 80% dran. Bei GBit/s NICS gab es auch mal das Problem das eine Seite des Transfers nur ungefaähr die hälfte von dem konnte was in der anderen Richtung möglich war. RSS und diverse andere Parameter mussten je nach OS angepasst werden, manchmal half nur eine andere NIC.
Gruß,
Peter
Auf seitens des QNAP kann ich nicht wirklich was an der NIC einstellen. Auf der Windowsseite ist alles auf Standard. Eingestellt habe ich da noch nix, war bisher mit der Performance zufrieden für meine private Spielwiese.
Bin ja auch zufrieden mit den durchschnittlichen 500MByte/s die das Windows Backup aufs NAS feuert. Aber mich haben die Werte einfach verwundert.
Kaffee rüberschieb,
Henere
Hallo,
Das ist uns allen Klar.
Ich wäre es bei einer 10 GBit/s Verbindung nicht Und wenn du mal nach Receive Side Scaling Mellanox suchst...
Gruß,
Peter
Das ist uns allen Klar.
Auf der Windowsseite ist alles auf Standard.
Haben wir uns auch so vorgestellt.Bin ja auch zufrieden mit den durchschnittlichen 500MByte/s die das Windows Backup aufs NAS feuert. Aber mich haben die Werte einfach verwundert.
Warum dann diesen Fred, wenn du mit deinen erzielten Werten von ca. 500 MByte/s zufrieden bist? Entweder ist es ein Problem für dich oder nicht. Wenn nicht dann Schreib doch dazu das du keinen Informationsaustausch wünscht da du ja mit den Werten zufrieden bist. Ich wäre es bei einer 10 GBit/s Verbindung nicht Und wenn du mal nach Receive Side Scaling Mellanox suchst...Kaffee rüberschieb,
Leerer Kaffebecher zurückschieb Gruß,
Peter
Nur mal nebenbei gefragt:
Hast du auf dem Switch und den beteiligten NICs Jumbo Framing aktiviert ??
Generell sollte man das eigentlich bei 1G und besonders bei den höheren Geschwindigkeiten machen.
Das sollte dann eigentlich den Durchsatz bei 10G nochmal deutlich erhöhen.
Du siehst ja das der Durchsatz bei kleineren Paketen deutlich schlechter ist was auf eine schlechtere Performance bei der L2 Fragmentierung schliessen lässt.
Jumbo Frames sind hier Pflicht.
Beispiel Cisco SG Switch:
Hast du auf dem Switch und den beteiligten NICs Jumbo Framing aktiviert ??
Generell sollte man das eigentlich bei 1G und besonders bei den höheren Geschwindigkeiten machen.
Das sollte dann eigentlich den Durchsatz bei 10G nochmal deutlich erhöhen.
Du siehst ja das der Durchsatz bei kleineren Paketen deutlich schlechter ist was auf eine schlechtere Performance bei der L2 Fragmentierung schliessen lässt.
Jumbo Frames sind hier Pflicht.
Beispiel Cisco SG Switch:
Sorry Peter, wenn ich noch aus einer Zeit komme wo man auf dem 8x7-Segment Display des Ein-Platinen-;Mikro-Computers ne Art Pong programmiert hat und sich mit "Bitte warten" nicht zufrieden gibt ? Jemand der während das Backups auf den ResMon des NAS schaut und eben sieht, dass es noch nicht röchtelt ? Dass CPU und HDDs (5x x300 4TB im Raid5) sich langweilen ? Dass die NIC zwischendurch noch Witze erzählt weil sie eben auch nur idelt und mal ein Paket gelangweilt weiterschubst....
Dass im Backup auch die Quelle erstmal das GB/s hergeben muss ist mir klar, das schafft mein Storage Space noch nicht. Daher war ich mit den 500MB/s zufrieden. Doch nun bei dem Gedanken daran noch mehr Geld zu Hause für mein Hobby zu versenken (SSD fürs NAS, Noch 1-2 M2s, andere NIC) wüsste ich gerne erstmal für mich an welchem Stellrad noch zu schrauben ist, dass zumindest NETIO die NIC mal zum glühen bringt.
Megapott doppeltschwarzdunkelwiedieHölle zurückschieb.
Henner
Dass im Backup auch die Quelle erstmal das GB/s hergeben muss ist mir klar, das schafft mein Storage Space noch nicht. Daher war ich mit den 500MB/s zufrieden. Doch nun bei dem Gedanken daran noch mehr Geld zu Hause für mein Hobby zu versenken (SSD fürs NAS, Noch 1-2 M2s, andere NIC) wüsste ich gerne erstmal für mich an welchem Stellrad noch zu schrauben ist, dass zumindest NETIO die NIC mal zum glühen bringt.
Megapott doppeltschwarzdunkelwiedieHölle zurückschieb.
Henner
dass es noch nicht röchtelt ?
Was ist den röchteln ??Dein Stellrad ist das Jumbo Framing !
Zitat von @aqui:
Nur mal nebenbei gefragt:
Hast du auf dem Switch und den beteiligten NICs Jumbo Framing aktiviert ??
Generell sollte man das eigentlich bei 1G und besonders bei den höheren Geschwindigkeiten machen.
Das sollte dann eigentlich den Durchsatz bei 10G nochmal deutlich erhöhen.
Du siehst ja das der Durchsatz bei kleineren Paketen deutlich schlechter ist was auf eine schlechtere Performance bei der L2 Fragmentierung schliessen lässt.
Jumbo Frames sind hier Pflicht.
Beispiel Cisco SG Switch:
Nur mal nebenbei gefragt:
Hast du auf dem Switch und den beteiligten NICs Jumbo Framing aktiviert ??
Generell sollte man das eigentlich bei 1G und besonders bei den höheren Geschwindigkeiten machen.
Das sollte dann eigentlich den Durchsatz bei 10G nochmal deutlich erhöhen.
Du siehst ja das der Durchsatz bei kleineren Paketen deutlich schlechter ist was auf eine schlechtere Performance bei der L2 Fragmentierung schliessen lässt.
Jumbo Frames sind hier Pflicht.
Beispiel Cisco SG Switch:
Hallo Aqui. Da ist kein Switch beteiligt. Ausser der Hyper-V Switch. Bei der 10GBe Verbindung steckt das Kabel 1:1 von NIC zu NIC.
Zitat von @aqui:
Dein Stellrad ist das Jumbo Framing !
dass es noch nicht röchtelt ?
Was ist den röchteln ??Dein Stellrad ist das Jumbo Framing !
Röchelt. Sorry nach durchgemachter Bastelnacht für das T zuviel. Bekommst nen Kaffee für das "Tee"
Also im NAS mal auf 9000 (Max) stellen, und auf der Mellanox das dann händisch auch auf 9000 ? Oder sind andere Werte sinnvoller ?
Regel Nummer 1 !!!
Never run a touching system.
Ich hab auf dem NAS auf 9000 umgestellt. Das gleiche dann bei der Mellanox im Server.
Erfolg: Das NAS kann ich weder über das Admin-Iinterface, noch über die 10GBe Verbindung ansprechen. Kein SSH mehr, keine Web-Gui.
Ich mach Schluss für diese Wachphase.
Wünsche allen angeschlossenen Mauschubsern und Tastaturakrobaten eine streßfreie Woche.
Melde mich später wieder
Never run a touching system.
Ich hab auf dem NAS auf 9000 umgestellt. Das gleiche dann bei der Mellanox im Server.
Erfolg: Das NAS kann ich weder über das Admin-Iinterface, noch über die 10GBe Verbindung ansprechen. Kein SSH mehr, keine Web-Gui.
Ich mach Schluss für diese Wachphase.
Wünsche allen angeschlossenen Mauschubsern und Tastaturakrobaten eine streßfreie Woche.
Melde mich später wieder
Was für ein Kabel ist denn das? Standard DAC? Oder LWL ?
Ich hab auf dem NAS auf 9000 umgestellt. Das gleiche dann bei der Mellanox im Server.
Nicht alle MTU Größen sind supportet !!Das ist auch bei Switchen durchaus unterschiedlich und nicht beliebig !!
Du musst also genau in die Treiber Spezifikationen sehen bei Server und Clients bzw. NICs was die beiu Jumbo Framing als maximale MTU supporten.
Idealerweise haben Hersteller nur einen dummen Schalter Jumbo an oder aus was das entsprechend setzt.
Musst du aber die MTU bei Jumbo Support spezifisch setzen dann gilt immer die Vorgabe des Herstellers !
Mit DAC oder LWL Kabel hat das übrigens nichts zu tun. Das ist Layer 1 und spielt keine Rolle.
Ich hab auf seitens des QNAP nur 1500, 4074, 7418 und 9000 (siehe Screenshot oben).
Switch spielt keine Rolle, da einfach keiner in der Leitung hängt. Zumindest nicht zwischen NAS und Server.
Die 10GBe-Karte ist von QNAP supported (direkt bei QNAP gekauft) für das TS-563.
Mellanox-X2 gibt es auch noch Treiber für 2016. Da kann ich die MTU per Num-Pad eintippen.
Ich habe jetzt alle Varianten durch. Sobald ich auf der QNAP etwas anderes als die 1500 einstelle hängt sich das Teil Netzwerkseitig auf und ich komme nicht mehr dran, jeun SSH, kein HTTPS. Auf keiner der beiden angeschlossenen NICs.
192.168.200.20 => nur Admin-Zugriff (SSH/HTTPS)
192.168.201.2 => nur iSCSI.
Es hilft dann nur ausschalten, mit gezogenem 10GBe-Kabel neustart, Wert auf 1500 zurück und dann kann ich das Kabel erst wieder einstecken.
Mich wundert der Riesenunterschied im Senden und Empfangen. Der Server mit der 2620v3 sollte doch in der Lage sein, per PCIe 3.0 x8 die vollen 1GByte/s zu bringen. Während das QNAP mit dem schwachen AMD-Gürkchen da doch benachteiligt sein sollte.
Oder liege ich da gedanklich falsch ?
Grüße, Henere
Switch spielt keine Rolle, da einfach keiner in der Leitung hängt. Zumindest nicht zwischen NAS und Server.
Die 10GBe-Karte ist von QNAP supported (direkt bei QNAP gekauft) für das TS-563.
Mellanox-X2 gibt es auch noch Treiber für 2016. Da kann ich die MTU per Num-Pad eintippen.
Ich habe jetzt alle Varianten durch. Sobald ich auf der QNAP etwas anderes als die 1500 einstelle hängt sich das Teil Netzwerkseitig auf und ich komme nicht mehr dran, jeun SSH, kein HTTPS. Auf keiner der beiden angeschlossenen NICs.
192.168.200.20 => nur Admin-Zugriff (SSH/HTTPS)
192.168.201.2 => nur iSCSI.
Es hilft dann nur ausschalten, mit gezogenem 10GBe-Kabel neustart, Wert auf 1500 zurück und dann kann ich das Kabel erst wieder einstecken.
Mich wundert der Riesenunterschied im Senden und Empfangen. Der Server mit der 2620v3 sollte doch in der Lage sein, per PCIe 3.0 x8 die vollen 1GByte/s zu bringen. Während das QNAP mit dem schwachen AMD-Gürkchen da doch benachteiligt sein sollte.
Oder liege ich da gedanklich falsch ?
Grüße, Henere
Dann nimm mal nicht die Maximalwerte sondern einen drunter.
Setz den QNAP auf 7418 und gebe die MTU für den Mellanox mit dem identischen Wert ein !
Viele Geräte akzeptieren eine MTU Änderung nur mit einem Reboot !! Hast du das QNAP auch mal rebootet.
Sollte es immer noch blockieren ist das de facto ein Bug.
Die MTU sagt ja nur das auch 7k Frames akzeptiert werden ohne Fragmentierung. Für einen SSH oder Web Zugriff spielt die MTU keine Rolle.
Also entweder Bug oder du musst rebooten damit die MTU Einstellung aktiv wird.
Nur mal doof nachgefragt: Ist das ein 10g Base T Anschluss ??
Wenn ja ist sowas für Storage / NAS und Server immer kontraproduktiv, denn bei 10G Base T hat man nie eine Garantie auf 10G. Das ist immer ein Autonegotiating je nach Kabel Qualität. Ein Knick oder schlechter Stecker und es kommen nur noch 8G an oder entsprechend weniger.
Das ist ein großes Manko von 10G Base T. Deshalb wird es in seriösen netzwerken niemals für Server und Storage verwendet. Besser sind hier immer SFP+ Ports und DAC / Twinax Kabel die immer 10G garantieren. Oder eben LWL.
Möglich das du also in diese Falle rennst. Normal wirkt sich das aber erst bei Längen jenseits der 5-10m aus. Bei kürzeren Patch Strippen eher selten.
Setz den QNAP auf 7418 und gebe die MTU für den Mellanox mit dem identischen Wert ein !
QNAP etwas anderes als die 1500 einstelle hängt sich das Teil Netzwerkseitig auf und ich komme nicht mehr dran
Auch wenn du das Kabel ziehst um so eine Renegotiation zu erzwingen.Viele Geräte akzeptieren eine MTU Änderung nur mit einem Reboot !! Hast du das QNAP auch mal rebootet.
Sollte es immer noch blockieren ist das de facto ein Bug.
Die MTU sagt ja nur das auch 7k Frames akzeptiert werden ohne Fragmentierung. Für einen SSH oder Web Zugriff spielt die MTU keine Rolle.
Also entweder Bug oder du musst rebooten damit die MTU Einstellung aktiv wird.
Oder liege ich da gedanklich falsch ?
Nein, liegst du nicht. Die Werte sind in der Tat jämmerlich für 10GNur mal doof nachgefragt: Ist das ein 10g Base T Anschluss ??
Wenn ja ist sowas für Storage / NAS und Server immer kontraproduktiv, denn bei 10G Base T hat man nie eine Garantie auf 10G. Das ist immer ein Autonegotiating je nach Kabel Qualität. Ein Knick oder schlechter Stecker und es kommen nur noch 8G an oder entsprechend weniger.
Das ist ein großes Manko von 10G Base T. Deshalb wird es in seriösen netzwerken niemals für Server und Storage verwendet. Besser sind hier immer SFP+ Ports und DAC / Twinax Kabel die immer 10G garantieren. Oder eben LWL.
Möglich das du also in diese Falle rennst. Normal wirkt sich das aber erst bei Längen jenseits der 5-10m aus. Bei kürzeren Patch Strippen eher selten.
Servus Aqui, danke dass Du dir die Zeit nimmst.
ich habe es jetzt nochmal probiert.
MTU auf beiden Seiten auf 9000. QNAP gleich rebootet. Windows Server auch Rebootet.
Es ist immer noch ein SFP+ Kabel (Größe wie RJ45 aber langer Einschub in NIC)
Es wird noch trauriger:
Wenn ich wieder den Nerv hab, versuche ich noch die anderen MTU-Größen. Viel Unterschied sehe ich nicht zwischen 1500 und 9000. Sind ja eh nur die ACK-Pakete die dann weniger werden.
Kann das sein, dass die Mellanox ein Problem hat ? Wenn ja, wie finde ich es raus (hab gerade keine 2te greifbar)
Grüße, Henere
ich habe es jetzt nochmal probiert.
MTU auf beiden Seiten auf 9000. QNAP gleich rebootet. Windows Server auch Rebootet.
Es ist immer noch ein SFP+ Kabel (Größe wie RJ45 aber langer Einschub in NIC)
Es wird noch trauriger:
Windows 2016 auf localhost:
Packet size 1k bytes: 146.74 MByte/s Tx, 153.26 MByte/s Rx.
Packet size 2k bytes: 187.73 MByte/s Tx, 192.46 MByte/s Rx.
Packet size 4k bytes: 289.44 MByte/s Tx, 293.45 MByte/s Rx.
Packet size 8k bytes: 428.69 MByte/s Tx, 459.51 MByte/s Rx.
Packet size 16k bytes: 567.61 MByte/s Tx, 600.02 MByte/s Rx.
Packet size 32k bytes: 746.02 MByte/s Tx, 761.19 MByte/s Rx.
Done.Windows 2016 auf eigene IP der Mellanox:
Packet size 1k bytes: 151.37 MByte/s Tx, 151.70 MByte/s Rx.
Packet size 2k bytes: 203.39 MByte/s Tx, 183.27 MByte/s Rx.
Packet size 4k bytes: 299.59 MByte/s Tx, 299.33 MByte/s Rx.
Packet size 8k bytes: 462.55 MByte/s Tx, 452.90 MByte/s Rx.
Packet size 16k bytes: 594.78 MByte/s Tx, 586.10 MByte/s Rx.
Packet size 32k bytes: 752.02 MByte/s Tx, 732.61 MByte/s Rx.
Done.Windows 2016 aufs NAS:
Packet size 1k bytes: 419.86 MByte/s Tx, 653.68 MByte/s Rx.
Packet size 2k bytes: 492.30 MByte/s Tx, 664.03 MByte/s Rx.
Packet size 4k bytes: 516.20 MByte/s Tx, 657.98 MByte/s Rx.
Packet size 8k bytes: 525.01 MByte/s Tx, 659.65 MByte/s Rx.
Packet size 16k bytes: 539.88 MByte/s Tx, 665.35 MByte/s Rx.
Packet size 32k bytes: 549.91 MByte/s Tx, 663.68 MByte/s Rx.
Done.Server 2016 aus NAS mit netio -b 9000 -t 192.168.201.2
Packet size 9000 bytes: 515.32 MByte/s Tx, 658.54 MByte/s Rx.
Done.NAS aufs NAS (localhost) ... und so hätte ich das alles erwartet !
Packet size 1k bytes: 828.31 MByte/s Tx, 820.61 MByte/s Rx.
Packet size 2k bytes: 1.251 GByte/s Tx, 1.230 GByte/s Rx.
Packet size 4k bytes: 1.735 GByte/s Tx, 1.672 GByte/s Rx.
Packet size 8k bytes: 1.912 GByte/s Tx, 1.932 GByte/s Rx.
Packet size 16k bytes: 1.856 GByte/s Tx, 1.814 GByte/s Rx.NAS auf eigene IP
Packet size 1k bytes: 778.01 MByte/s Tx, 824.13 MByte/s Rx.
Packet size 2k bytes: 1.209 GByte/s Tx, 1.217 GByte/s Rx.
Packet size 4k bytes: 1.691 GByte/s Tx, 1.672 GByte/s Rx.
Packet size 8k bytes: 1.945 GByte/s Tx, 1.933 GByte/s Rx.
Packet size 16k bytes: 1.862 GByte/s Tx, 1.801 GByte/s Rx.
Packet size 32k bytes: 1.915 GByte/s Tx, 1.876 GByte/s Rx.Wenn ich wieder den Nerv hab, versuche ich noch die anderen MTU-Größen. Viel Unterschied sehe ich nicht zwischen 1500 und 9000. Sind ja eh nur die ACK-Pakete die dann weniger werden.
Kann das sein, dass die Mellanox ein Problem hat ? Wenn ja, wie finde ich es raus (hab gerade keine 2te greifbar)
Grüße, Henere
Ja, NAS NAS und NAS IP sind halbwegs realistische Zahlen wie es sein sollte.
Da ist der böse Buhman der Winblows Server. Interessant ist das bei kleinen Paketen die Performance massiv einbricht.
Sowas weisst in erster Line auf sehr schwachbrüstige NIC Netzwerk Hardware hin. Klar, denn bei kleineren Paketen muss das Silizium erheblich mehr ackern.
Allerdings steht Mellanox nicht gerade für sowas wie Realtek usw. eher das genaue Gegenteil.
Eine Switch Infrastruktur war da ja nicht mehr zwischen wie du sagst, richtig ? Dann kann man das als Fehlerquelle schon mal sicher ausschliessen.
Da bleibt ja dann eigentlich nur die NIC bzw. die Server HW.
Was du mal machen kannst ist UDP zu nehmen statt TCP !!
Gibt es da einen gravierenden Unterschied im Durchsatz ??
Da ist der böse Buhman der Winblows Server. Interessant ist das bei kleinen Paketen die Performance massiv einbricht.
Sowas weisst in erster Line auf sehr schwachbrüstige NIC Netzwerk Hardware hin. Klar, denn bei kleineren Paketen muss das Silizium erheblich mehr ackern.
Allerdings steht Mellanox nicht gerade für sowas wie Realtek usw. eher das genaue Gegenteil.
Eine Switch Infrastruktur war da ja nicht mehr zwischen wie du sagst, richtig ? Dann kann man das als Fehlerquelle schon mal sicher ausschliessen.
Da bleibt ja dann eigentlich nur die NIC bzw. die Server HW.
Was du mal machen kannst ist UDP zu nehmen statt TCP !!
Gibt es da einen gravierenden Unterschied im Durchsatz ??
Darum hab ich damals die Mellanox für teures Geld gekauft....
Frage: Ist ein SFP+ Kabel 1:1 belegt ? Dann würde ich es mal rumdrehen, nicht dass einige Adern was weg haben. Was dem widerspricht, ist aber die Leistung auf dem SRV zum localhost. Da ist ja kein Kabel beteiligt.
Bei UDP wird es noch krasser:
Mag er wohl irgendwie nicht:
Frage: Ist ein SFP+ Kabel 1:1 belegt ? Dann würde ich es mal rumdrehen, nicht dass einige Adern was weg haben. Was dem widerspricht, ist aber die Leistung auf dem SRV zum localhost. Da ist ja kein Kabel beteiligt.
Bei UDP wird es noch krasser:
Server zum NAS:
UDP connection established.
Packet size 1k bytes: 154.73 MByte/s (0%) Tx, 145.81 MByte/s (0%) Rx.
Packet size 2k bytes: 322.38 MByte/s (0%) Tx, 285.96 MByte/s (0%) Rx.
Packet size 4k bytes: 435.90 MByte/s (7%) Tx, 375.04 MByte/s (2%) Rx.
Packet size 8k bytes: 31.88 MByte/s (0%) Tx, 537.96 MByte/s (2%) Rx.
Packet size 16k bytes: 61.79 MByte/s (0%) Tx, 0 Byte/s (100%) Rx.
Packet size 32k bytes: 121.56 MByte/s (0%) Tx, 0 Byte/s (100%) Rx.
Done.Mag er wohl irgendwie nicht:
Server Localhost UDP:
NETIO - Network Throughput Benchmark, Version 1.32
(C) 1997-2012 Kai Uwe Rommel
bind(DGRAM): error code 10048
Hallo,
Hast du soetwas https://en.wikipedia.org/wiki/Twinaxial_cabling#SFP+_Direct-Attach_Coppe ...
Gruß,
Peter
Hast du soetwas https://en.wikipedia.org/wiki/Twinaxial_cabling#SFP+_Direct-Attach_Coppe ...
Mag er wohl irgendwie nicht:
Keine Ahnung was du eingetippelt hast. Mach mal ein Netio /?Gruß,
Peter
Hallo,
Und ich dachte immer das 8 Bits ein Byte sind. Wenn also seinen SFP+ geschichte macx 10 GBit/s kann, wie kommen dann z.B. diese Werte zusammen?
Das wären ja dann 15296 GBit/s TX , 15488 GBit/s RX, auch wenn 7 Bits ein Byte sein sollten kommen immer noch über 13000 GBit/s zusammen? Bin etwas irritiert.
Gruß,
Peter
Und ich dachte immer das 8 Bits ein Byte sind. Wenn also seinen SFP+ geschichte macx 10 GBit/s kann, wie kommen dann z.B. diese Werte zusammen?
Packet size 8k bytes: 1.912 GByte/s Tx, 1.932 GByte/s Rx.
Gruß,
Peter
Zitat von @Pjordorf:
Hallo,
Hast du soetwas https://en.wikipedia.org/wiki/Twinaxial_cabling#SFP+_Direct-Attach_Coppe ...
Hallo,
Hast du soetwas https://en.wikipedia.org/wiki/Twinaxial_cabling#SFP+_Direct-Attach_Coppe ...
Sieht so aus:
Mag er wohl irgendwie nicht:
Keine Ahnung was du eingetippelt hast. Mach mal ein Netio /?Gruß,
Peter
Das gleicht wie vorher, nur mit -u statt -t
Grüße, Henere
Hallo,
Also ein Twinax DAC kabel mit SFP+ Modulen dran.
Und wie willst du dort Adern tauschen? Sind zwar nur 2 drin, aber....
Dann klappt es auch
Gruß,
Peter
Also ein Twinax DAC kabel mit SFP+ Modulen dran.
Und wie willst du dort Adern tauschen? Sind zwar nur 2 drin, aber....
Das gleicht wie vorher, nur mit -u statt -t
Und hier weiss keiner was du vorhast oder tust. Also mal lesen http://www.nwlab.net/art/netio/netio.htmlDann klappt es auch
Gruß,
Peter
Entschuldige, aber hälst Du mich für zu doof, ein NETIO -S bzw ein NETIO -T/-U ip-adresse zu starten ?
Es war auf Aquis Frage, ob das mit UDP genauso läuft. Daher -u (UDP) anstatt -t (TCP).
Und da kam die Fehlermeldung wie gepostet.
Ich will keine Adern tauschen, ich wollte die Kabelenden (jedes Kabel hat 2, wie Du weißt) aus dem NAS und Server rausziehen und das aus dem NAS in den Server stecken. Und das nun freie Ende aus dem Server dann ins NAS.
Es gibt Kabel im Hifi-Bereich, die sind sogar beschriftet mit Source und Destination. (Auch wenn man das als Elektriker nicht nachvollziehen kann)
Hiermit wollte ich ausschließen, dass evtl einzelne Adern einen Defekt haben. Macht aber nur Sinn, wenn nicht 1:1 belegt.
Grüße, Henere
Es war auf Aquis Frage, ob das mit UDP genauso läuft. Daher -u (UDP) anstatt -t (TCP).
Und da kam die Fehlermeldung wie gepostet.
Ich will keine Adern tauschen, ich wollte die Kabelenden (jedes Kabel hat 2, wie Du weißt) aus dem NAS und Server rausziehen und das aus dem NAS in den Server stecken. Und das nun freie Ende aus dem Server dann ins NAS.
Es gibt Kabel im Hifi-Bereich, die sind sogar beschriftet mit Source und Destination. (Auch wenn man das als Elektriker nicht nachvollziehen kann)
Hiermit wollte ich ausschließen, dass evtl einzelne Adern einen Defekt haben. Macht aber nur Sinn, wenn nicht 1:1 belegt.
Grüße, Henere
Hallo,
ansonsten ist es Kosmetik (und dazu muss man noch nicht mal Elektriker sein)
Gruß,
Peter
Zitat von @Henere:
Entschuldige, aber hälst Du mich für zu doof, ein NETIO -S bzw ein NETIO -T/-U ip-adresse zu starten ?
Du schreibst hier das etwas nicht funktioniert wenn du es eintippelst, aber nicht was du eingetippelt hast.Entschuldige, aber hälst Du mich für zu doof, ein NETIO -S bzw ein NETIO -T/-U ip-adresse zu starten ?
Und da kam die Fehlermeldung wie gepostet.
Dann machst du etwas falsch, aber das weisst du ja schon.Es gibt Kabel im Hifi-Bereich, die sind sogar beschriftet mit Source und Destination. (Auch wenn man das als Elektriker nicht nachvollziehen kann)
Wenn in den Stecker/Buchsen keine Elektronik verbaut ist hilft es einen Laien die richtig anzustöpseln ansonsten ist es Kosmetik (und dazu muss man noch nicht mal Elektriker sein)Hiermit wollte ich ausschließen, dass evtl einzelne Adern einen Defekt haben. Macht aber nur Sinn, wenn nicht 1:1 belegt.
Nein die sind nicht 1:1 sondern sind getauscht damit nicht ein Sender auf Sender ensteht, aber du kannst selbstverständlich die SFP+ Module (mit den angebunden DAC) gegeeinander tauschen. Wird allerdngs an deinen NetIO Werten nichts ändern.Gruß,
Peter
Hi, ich dachte das geht aus der 1. Zeile hervor in der steht "Server Localhost UDP".
So wie alle anderen Messungen auch beschriftet waren.
Ich hatte auf dem Server ein netio -s gestartet. In einer weiteren CMD dann "netio -u localhost". Dann kam die merkwürdige Fehlermeldung. Mit -t localhost geht es ja auch.
Ich war jetzt auch auf der Suche, ob Mellanox da noch einen neueren Treiber hat, aber ich werde da nicht fündig.
Aktuell auf dem Server: vom 10.04.2016 Version 5.11.51148.0
Vielleicht findet ja jemand was Neueres ? Mellanox-X2
Grüße, Henere
So wie alle anderen Messungen auch beschriftet waren.
Ich hatte auf dem Server ein netio -s gestartet. In einer weiteren CMD dann "netio -u localhost". Dann kam die merkwürdige Fehlermeldung. Mit -t localhost geht es ja auch.
Ich war jetzt auch auf der Suche, ob Mellanox da noch einen neueren Treiber hat, aber ich werde da nicht fündig.
Aktuell auf dem Server: vom 10.04.2016 Version 5.11.51148.0
Vielleicht findet ja jemand was Neueres ? Mellanox-X2
Grüße, Henere
Hallo,
Deine Beschriftung ist aber nicht der Aufruf gewesen, daher die Irritation.
NETIO - Network Throughput Benchmark, Version 1.32
(C) 1997-2012 Kai Uwe Rommel
TCP connection established.
Packet size 1k bytes: 67.25 MByte/s Tx, 66.53 MByte/s Rx.
Packet size 2k bytes: 105.37 MByte/s Tx, 104.86 MByte/s Rx.
Packet size 4k bytes: 169.24 MByte/s Tx, 168.67 MByte/s Rx.
Packet size 8k bytes: 261.62 MByte/s Tx, 260.52 MByte/s Rx.
Packet size 16k bytes: 344.72 MByte/s Tx, 354.27 MByte/s Rx.
Packet size 32k bytes: 368.29 MByte/s Tx, 386.29 MByte/s Rx.
Done.Das wäre dann eine 3 MBit/s Verbindung, oder? Und mit -u gibt es den gleichen Fehler wie bei dir. Die tatsächliche NIC Hardware wird hier vollkommen umgangen.
Und das kommt bei deaktivierter NICBau also deine NiIC mal aus dann wird es etwas schneller
Gruß,
Peter
Deine Beschriftung ist aber nicht der Aufruf gewesen, daher die Irritation.
Dann kam die merkwürdige Fehlermeldung. Mit -t localhost geht es ja auch.
Das dürfte bei jedem kommen. Frage mal beim Entwickler an ob er das so vorgesehen hat. Auf ein ca. 10 Jahre altem Laptop Core2Duo T5550 4 GB RAM kommt dann meine 100 MBit/s echte Netzwerkkarte (Intel Chip) auf <code< type=plain>E:\Netio>netio_132 -t localhostNETIO - Network Throughput Benchmark, Version 1.32
(C) 1997-2012 Kai Uwe Rommel
TCP connection established.
Packet size 1k bytes: 67.25 MByte/s Tx, 66.53 MByte/s Rx.
Packet size 2k bytes: 105.37 MByte/s Tx, 104.86 MByte/s Rx.
Packet size 4k bytes: 169.24 MByte/s Tx, 168.67 MByte/s Rx.
Packet size 8k bytes: 261.62 MByte/s Tx, 260.52 MByte/s Rx.
Packet size 16k bytes: 344.72 MByte/s Tx, 354.27 MByte/s Rx.
Packet size 32k bytes: 368.29 MByte/s Tx, 386.29 MByte/s Rx.
Done.Das wäre dann eine 3 MBit/s Verbindung, oder? Und mit -u gibt es den gleichen Fehler wie bei dir. Die tatsächliche NIC Hardware wird hier vollkommen umgangen.
Und das kommt bei deaktivierter NIC
E:\Netio>netio_132 -t localhost
NETIO - Network Throughput Benchmark, Version 1.32
(C) 1997-2012 Kai Uwe Rommel
TCP connection established.
Packet size 1k bytes: 67.41 MByte/s Tx, 67.11 MByte/s Rx.
Packet size 2k bytes: 105.80 MByte/s Tx, 105.73 MByte/s Rx.
Packet size 4k bytes: 169.83 MByte/s Tx, 169.37 MByte/s Rx.
Packet size 8k bytes: 261.38 MByte/s Tx, 254.34 MByte/s Rx.
Packet size 16k bytes: 351.40 MByte/s Tx, 352.44 MByte/s Rx.
Packet size 32k bytes: 453.15 MByte/s Tx, 452.55 MByte/s Rx.
Done.Gruß,
Peter
Darum hab ich damals die Mellanox für teures Geld gekauft....
Mellanox ist ja nun auch nicht gerade innovativ oder bekannt in Sachen Ethernet. Da sind die eher Niche Player unter ferner liefen.Die verstehen was von InfiniBand aber nix wirklich von Ethernet.
Mit einer Intel oder Broadcom Chipset wärst du da sicher besser beraten gewesen...
Frage: Ist ein SFP+ Kabel 1:1 belegt ?
Das ist Blödsinn und gibt es bei Twinax nicht wie bei Cat Kabel !https://en.wikipedia.org/wiki/Twinaxial_cabling#SFP+_Direct-Attach_Coppe ...
Ok.. also sind die Messungen mit NETIO hinfällig.
Wobei.. bei einer reinen 1GBe Verbindung passen die Werte
Wahrscheinlich kommt die Software nicht nach Datenpakete auf der NIC zu generieren. Oder was auch immer.
Hast Du eine Empfehlung für einen Privathaushalt für eine SFP+ fähige Karte ?
Hab gerade erst wieder 1k€ in 2 NVMes und 2 4TB HDDs gesteckt um mein Storagespace performanter zu machen.
Der WAF geht da gerade gen Null
Wobei.. bei einer reinen 1GBe Verbindung passen die Werte
Wahrscheinlich kommt die Software nicht nach Datenpakete auf der NIC zu generieren. Oder was auch immer.
Hast Du eine Empfehlung für einen Privathaushalt für eine SFP+ fähige Karte ?
Hab gerade erst wieder 1k€ in 2 NVMes und 2 4TB HDDs gesteckt um mein Storagespace performanter zu machen.
Der WAF geht da gerade gen Null
also sind die Messungen mit NETIO hinfällig.
Nein, wie kommst du darauf ?Nur wenn du sie via localhost misst, denn dann umgehst du ja den Adapter und seinen Treiber.
Ein netter Kollege hier aus dem Forum hat mir eine gebrauchte 10GBe SFP+ Karte angeboten. Sobald diese hier ist, teste ich dann mal mit der.
Da ich heute Abend das StorageSpace noch erweitern will und die M2 Adapter durch einen 4x M2-Adapter ersetzt werden, hab ich dann noch nen PCIe3.0 x16 Slot frei. Ich stecke dann mal um und schau ob sich da was an den Werten ändert.
Wobei die Mellanox-X2 laut Datenblatt mit einem 4x auskommen soll und derzeit in einem x8 steckt.
Danke erstmal und Schönes Wochenende .
Da ich heute Abend das StorageSpace noch erweitern will und die M2 Adapter durch einen 4x M2-Adapter ersetzt werden, hab ich dann noch nen PCIe3.0 x16 Slot frei. Ich stecke dann mal um und schau ob sich da was an den Werten ändert.
Wobei die Mellanox-X2 laut Datenblatt mit einem 4x auskommen soll und derzeit in einem x8 steckt.
Danke erstmal und Schönes Wochenende .
