Windows Server 2025 - NIC-Performance - Per Default sehr "durchwachsen"
Moin Zusammen,
heute Morgen habe ich auch den zweiten Server unseres Test-Labs mit Server 2025 bespielt.
Beide Server sind BIOS-Seitig schon auf „Best Performance“ getrimmt, OS seitig habe ich jedoch bisher mit Absicht die Default Einstellungen belassen.
Beide Server sind Hardwaretechnisch absolut identisch ausgestattet, die Hardware ist zwar etwas älter (2 x E5-2690 V2 & 384 GB RAM), für das was ich jedoch beabsichtige, ist die noch vollkommen ausreichend.
Zudem sind in jedem Server die folgenden NIC’s verbaut …
… sprich, von 1G bis 25G einiges da. ๐
Die NIC’s der beiden Test-Server sind übrigens direkt mit einem Patchkabel miteinander verbunden, sprich, „Server1 I350-1 <--> Server2 I350-1“, „Server1 X540-1 <--> Server2 X540-1“, u.s.w..
Als nächstes habe ich den NIC’s IP’s verpasst und noch den Defender heruntergeschmissen und auch die Firewall deaktiviert, damit mir diese bei den Tests nicht dazwischen pfuschen. Ansonsten habe ich an den Default Einstellungen, bisher nichts mehr verändert.
Dann habe ich noch kurz die aktuellste NTTTCP Version auf die Server geschmissen und zwar auch mit Absicht, da die Microsoftianer in Redmond, vor allem die in der Entwicklung, iPerf überhaupt nicht leiden können. Und da ich diesen die nachfolgenden Ergebnisse natürlich auch unter die Nase reiben werde, muss ich schon auch das zum Messen nehmen, was die auch möglichst diskussionsarm akzeptieren.
Als nächstes habe ich mit den folgenden Parametern …
NTttcp Sender:
NTttcp Receiver:
… die Netzwerkperformance zwischen den jeweiligen NIC’s getestet.
Und ja, 4K und nur ein Worker mit nur einem oIO ist nicht wirklich viel Last, ich wollte jedoch mit voller Absicht genau das sehen, sprich, wie die NIC’s mit einer geringen Last umgehen, da das für sehr viele Anwendungsfälle auch sehr entscheidend ist.
Ausserdem, wenn eine NIC schon mit wenig Druck eine gute Leistung bringt, dann wird diese mit mehr Druck meistens nicht wirklich schlechter. ๐
So, nun aber zu den etwas wirren Ergebnissen.
I350 <--> I350 (1G):
Was mir bei der Messung schon mal negativ aufgefallen ist, ist nicht mal der Durchsatz von gerade mal 15,518 MB/s, was unter diesen Bedingungen, weder gut noch wirklich schlecht ist, sondern eher die Tatsache, dass der Sender (Server 1) in die Richtung des Receivers (Server 2), 715421 Pakete gesendet hat, beim Receiver sind jedoch nur 477159 angekommen und es gab auch keine Übertragungsfehler. ๐ค
Vom Receiver Richtung Sender wurden wiederum nur 238711 Pakete (ACK & Co.) gesendet, bei Sender sind jedoch 238739 Pakete angekommen. ๐ฌ
Ich habe da schon eine Ahnung was das verursachen könnte, dazu jedoch etwas später.
So, nun zum nächsten Kandidaten der P210 von Broadcom.
P210 <--> P210 (10G):
Hier, sieht der Durchsatz mit 23,724 MB/s schon etwas besser aus als bei der I350, das sollte bei einer 10G NIC im vergleich zu einer 1G NIC, ja eigentlich auch so sein, eigentlich sogar noch um einiges besser. ๐
Aber auch bei dieser Messung muss ich denselben Murks zwischen gesendeten und empfangenen Paketen feststellen, wie auch bei der vorherigen, bei dieser liegt der Faktor sogar bei ~ 3:1 (Sender to Receiver), bei der I350 zuvor war es im Vergleich noch ~1,5:1. ๐ฌ
So und nun zu den Überraschungskinder.
X540 <--> X540 (10G):
Ähm, also nein, ich habe hier nicht ausversehen die Messung mit der I350 also, einer 1G NIC vertauscht, die X540 läuft per Default mit 10G, beim selben Belastungsmuster langsamer als die I350 mit 1G. ๐ญ
Der Murks mit der Paketdifferenz zwischen Sender und Receiver ist auch hier zu sehen.
Und ja, ich habe den Server 2025 noch nicht aktiviert. ๐
X710 <--> X710 (10G):
Und auch die X710, kommt trotz 10G Uplink, nicht an die Leistung der I350, geschweige denn, an die der P210, zumindest per Default. ๐
Und auch hier, selbes Spielchen in Bezug auf die Paketdifferenz.
So und nun kommt der Spitzen-Predator, zumindest was dieses Feld angeht, und zwar die E810, mit 25G Uplink. ๐คช
E810 <--> E810 (25G):
Tja, nur kann sich dieser Spitzen-Predatorchen gerade mal so mit der X710 anlegen, aber nicht mit der P210 (10G) und auch nicht mit der I350(1G). ๐ต๐ซ
Und auch hier, selbes Spielchen, sprich Paketdifferenz.
So, nun habt ihr bestimmt einige Frage, ich auch.
Bevor ich jedoch auf diese eingehe, auch auf meine eigenen, muss ich mal nach meinen Hausdrachen schauen. ๐คช
Und danach würde ich den Server 2025, energieoptionstechnisch von „Ausbalanciert“ … ๐คข๐คฎ … auf "Hochleistung" stellen und dann schauen wir mal was danach passiert.
Gruss Alex
P.S.
Und bevor hier jetzt das Intel-NIC Bashing losgeht. Intel hat damit nicht wirklich etwas zu tun, sondern eher die stellenweise sehr blödsinnigen Default-Vorgaben seitens Microsoft.
heute Morgen habe ich auch den zweiten Server unseres Test-Labs mit Server 2025 bespielt.
Beide Server sind BIOS-Seitig schon auf „Best Performance“ getrimmt, OS seitig habe ich jedoch bisher mit Absicht die Default Einstellungen belassen.
Beide Server sind Hardwaretechnisch absolut identisch ausgestattet, die Hardware ist zwar etwas älter (2 x E5-2690 V2 & 384 GB RAM), für das was ich jedoch beabsichtige, ist die noch vollkommen ausreichend.
Zudem sind in jedem Server die folgenden NIC’s verbaut …
… sprich, von 1G bis 25G einiges da. ๐
Die NIC’s der beiden Test-Server sind übrigens direkt mit einem Patchkabel miteinander verbunden, sprich, „Server1 I350-1 <--> Server2 I350-1“, „Server1 X540-1 <--> Server2 X540-1“, u.s.w..
Als nächstes habe ich den NIC’s IP’s verpasst und noch den Defender heruntergeschmissen und auch die Firewall deaktiviert, damit mir diese bei den Tests nicht dazwischen pfuschen. Ansonsten habe ich an den Default Einstellungen, bisher nichts mehr verändert.
Dann habe ich noch kurz die aktuellste NTTTCP Version auf die Server geschmissen und zwar auch mit Absicht, da die Microsoftianer in Redmond, vor allem die in der Entwicklung, iPerf überhaupt nicht leiden können. Und da ich diesen die nachfolgenden Ergebnisse natürlich auch unter die Nase reiben werde, muss ich schon auch das zum Messen nehmen, was die auch möglichst diskussionsarm akzeptieren.
Als nächstes habe ich mit den folgenden Parametern …
NTttcp Sender:
NTttcp.exe -s -m 1,*,192.168.20.2 -l 4K -a 1 -t 60 -nic 192.168.20.1 -v
NTttcp Receiver:
NTttcp.exe -r -m 1,*,192.168.20.2 -t 60 -v
… die Netzwerkperformance zwischen den jeweiligen NIC’s getestet.
Und ja, 4K und nur ein Worker mit nur einem oIO ist nicht wirklich viel Last, ich wollte jedoch mit voller Absicht genau das sehen, sprich, wie die NIC’s mit einer geringen Last umgehen, da das für sehr viele Anwendungsfälle auch sehr entscheidend ist.
Ausserdem, wenn eine NIC schon mit wenig Druck eine gute Leistung bringt, dann wird diese mit mehr Druck meistens nicht wirklich schlechter. ๐
So, nun aber zu den etwas wirren Ergebnissen.
I350 <--> I350 (1G):
Was mir bei der Messung schon mal negativ aufgefallen ist, ist nicht mal der Durchsatz von gerade mal 15,518 MB/s, was unter diesen Bedingungen, weder gut noch wirklich schlecht ist, sondern eher die Tatsache, dass der Sender (Server 1) in die Richtung des Receivers (Server 2), 715421 Pakete gesendet hat, beim Receiver sind jedoch nur 477159 angekommen und es gab auch keine Übertragungsfehler. ๐ค
Vom Receiver Richtung Sender wurden wiederum nur 238711 Pakete (ACK & Co.) gesendet, bei Sender sind jedoch 238739 Pakete angekommen. ๐ฌ
Ich habe da schon eine Ahnung was das verursachen könnte, dazu jedoch etwas später.
So, nun zum nächsten Kandidaten der P210 von Broadcom.
P210 <--> P210 (10G):
Hier, sieht der Durchsatz mit 23,724 MB/s schon etwas besser aus als bei der I350, das sollte bei einer 10G NIC im vergleich zu einer 1G NIC, ja eigentlich auch so sein, eigentlich sogar noch um einiges besser. ๐
Aber auch bei dieser Messung muss ich denselben Murks zwischen gesendeten und empfangenen Paketen feststellen, wie auch bei der vorherigen, bei dieser liegt der Faktor sogar bei ~ 3:1 (Sender to Receiver), bei der I350 zuvor war es im Vergleich noch ~1,5:1. ๐ฌ
So und nun zu den Überraschungskinder.
X540 <--> X540 (10G):
Ähm, also nein, ich habe hier nicht ausversehen die Messung mit der I350 also, einer 1G NIC vertauscht, die X540 läuft per Default mit 10G, beim selben Belastungsmuster langsamer als die I350 mit 1G. ๐ญ
Der Murks mit der Paketdifferenz zwischen Sender und Receiver ist auch hier zu sehen.
Und ja, ich habe den Server 2025 noch nicht aktiviert. ๐
X710 <--> X710 (10G):
Und auch die X710, kommt trotz 10G Uplink, nicht an die Leistung der I350, geschweige denn, an die der P210, zumindest per Default. ๐
Und auch hier, selbes Spielchen in Bezug auf die Paketdifferenz.
So und nun kommt der Spitzen-Predator, zumindest was dieses Feld angeht, und zwar die E810, mit 25G Uplink. ๐คช
E810 <--> E810 (25G):
Tja, nur kann sich dieser Spitzen-Predatorchen gerade mal so mit der X710 anlegen, aber nicht mit der P210 (10G) und auch nicht mit der I350(1G). ๐ต๐ซ
Und auch hier, selbes Spielchen, sprich Paketdifferenz.
So, nun habt ihr bestimmt einige Frage, ich auch.
Bevor ich jedoch auf diese eingehe, auch auf meine eigenen, muss ich mal nach meinen Hausdrachen schauen. ๐คช
Und danach würde ich den Server 2025, energieoptionstechnisch von „Ausbalanciert“ … ๐คข๐คฎ … auf "Hochleistung" stellen und dann schauen wir mal was danach passiert.
Gruss Alex
P.S.
Und bevor hier jetzt das Intel-NIC Bashing losgeht. Intel hat damit nicht wirklich etwas zu tun, sondern eher die stellenweise sehr blödsinnigen Default-Vorgaben seitens Microsoft.
Please also mark the comments that contributed to the solution of the article
Content-ID: 669379
Url: https://administrator.de/contentid/669379
Printed on: December 7, 2024 at 17:12 o'clock
55 Comments
Latest comment
Zitat von @MysticFoxDE:
Sprich, die X540-T2, ist eigentlich nur bis Server 2019 offiziell supportet. ๐ฌ
Warum also installiert der Server 2025 für diese NIC und auch noch über Windows Update, denn überhaupt einen Treiber? ๐ค
Sprich, die X540-T2, ist eigentlich nur bis Server 2019 offiziell supportet. ๐ฌ
Warum also installiert der Server 2025 für diese NIC und auch noch über Windows Update, denn überhaupt einen Treiber? ๐ค
Weil er es kann.
lks
Warum also installiert der Server 2025 für diese NIC und auch noch über Windows Update, denn überhaupt einen Treiber?
Was man nach einer Installation Winblows gefälligst am besten gleich abgewöhnen sollte sonst wirst du immer wieder plötzlich überrascht wenn Windows selbst meint mal wieder Treiber updaten zu wollen die man eigentlich gar nicht haben will oder mittlerweile olle Kamelle sind. Passiert sonst nicht selten das Winblows bereits explizit manuell installierte Treiber wieder durch die im Windows Update ersetzt.
Moin..
Gruss Alex
Frank
Zitat von @MysticFoxDE:
Moin @Vision2015,
wie hast du gemessen?
NTttcp mit deinen werten! alle werte auf max High-performance, standard treiber!Moin @Vision2015,
auf einem HP Dl380 G10 ähnliches ergebnis mit ner HPE 544 Nic... 40 Gbit/s bzw. 10 Gbit/s leistung ist unterirdisch!
wie hast du gemessen?
Gruss Alex
Moin...
das war mir schon klar
Wenn du den maximalen Durchsatz ermitteln möchtest, dann solltest du die Parameter folgend setzen, ...
... sprich, mehr Worker, mehr oIOs und auch grössere Blöcke.
Gruss Alex
Frank
Zitat von @MysticFoxDE:
Moin @Vision2015,
dieses Pattern (falls du dasselbe benutzt hast) ist aber nicht wirklich dafür gedacht den maximalen Durchsatz zu Ermitteln, es prüft eher Richtung Transaktionsperformance/Transaktionslatenz.
Moin @Vision2015,
NTttcp mit deinen werten! alle werte auf max High-performance, standard treiber!
dieses Pattern (falls du dasselbe benutzt hast) ist aber nicht wirklich dafür gedacht den maximalen Durchsatz zu Ermitteln, es prüft eher Richtung Transaktionsperformance/Transaktionslatenz.
das war mir schon klar
Wenn du den maximalen Durchsatz ermitteln möchtest, dann solltest du die Parameter folgend setzen, ...
#NTttcp Sender:
NTttcp.exe -s -m 4,*,192.168.50.2 -l 64K -a 8 -t 60 -nic 192.168.50.1 -v
#NTttcp Receiver:
NTttcp.exe -r -m 4,*,192.168.50.2 -a 8 -v -t 60
... sprich, mehr Worker, mehr oIOs und auch grössere Blöcke.
Gruss Alex
Frank
Ja ich weiß, die Zeit rennt. Ich bekomme immer neue Sachen auf den Tisch und gewisse Dinge einfach nicht fertig. Ich wollte hier auch schon die ein oder andere Anleitung schreiben aber irgendwie komme ich mit meiner eigenen Doku schon auf keinen zufriedenstellenden Stand...
Dennoch glaube ich, kann man mit einem Kompendium a la aqui zu einem Thema einen nützlichen Leitfaden zu so einem Thema machen.
Dennoch glaube ich, kann man mit einem Kompendium a la aqui zu einem Thema einen nützlichen Leitfaden zu so einem Thema machen.
Zitat von @MysticFoxDE:
Ganz ehrlich, je tiefer ich mich in die entsprechende Materie reinfresse umso weniger verstehe das, was in der Praxis damit getrieben wird. Denn viele der immer mehr werdenden Features die mittlerweile per Default im OS oder auch Hardwareseitig aktiviert sind, machen in den meisten Anwendungsfällen überhaupt keinen Sinn und manchmal beissen die sich sogar gegenseitig. ๐๐ญ
Ganz ehrlich, je tiefer ich mich in die entsprechende Materie reinfresse umso weniger verstehe das, was in der Praxis damit getrieben wird. Denn viele der immer mehr werdenden Features die mittlerweile per Default im OS oder auch Hardwareseitig aktiviert sind, machen in den meisten Anwendungsfällen überhaupt keinen Sinn und manchmal beissen die sich sogar gegenseitig. ๐๐ญ
Agile programming und kleine
lks
@microsoft
Was soll eigentlich dieser ganze Murks? ๐คจ๐ก
Was soll eigentlich dieser ganze Murks? ๐คจ๐ก
Du musst denen schon auf Englisch schreiben, die Trumpianer überm Teich sind zu doof Übersetzer zu verwenden, weil mit zwei AK47 im Anschlag fällt das logische Denken nicht gerade leicht ๐.
Moin,
Das mit dem Übersetzen ist eigentlich auch hinfällig, denn
aus https://www.thenationalliteracyinstitute.com/post/literacy-statistics-20 ... via https://blog.fefe.de/?ts=99cde53d
Die können bald nicht mal lesen.
lks
Das mit dem Übersetzen ist eigentlich auch hinfällig, denn
Illiteracy has become such a serious problem in our country that 130 million adults are now unable to read a simple story to their children
aus https://www.thenationalliteracyinstitute.com/post/literacy-statistics-20 ... via https://blog.fefe.de/?ts=99cde53d
Die können bald nicht mal lesen.
lks
sondern mit der Begründung, dass iPerf die Dinge nicht richtig machen würde, auf NTttcp verweist.
MS lebt in einem Universum mit anderen physikalischen und technischen Gesetzen ๐.Selbst das Tool für ihre eigenen Betriebssysteme zu tweaken sind sie zu doof ๐.
damit kannst du uns jetzt aber nicht kommen, den iPerf hat so viele Fehler, nimm lieber NTTTCP, der macht das viel besser und ist auch viel genauer. ๐
Komisch nur das die ganze Welt es benutzt und das die Fehler noch keinem aufgefallen sind, ist ja OpenSource. Kann ich ehrlich gesagt nicht glauben. Diese angeblichen "Fehler" wären doch schon längst aufgefallen. Muss ich mir den Source-Code von NTTTCP in einer ruhigen Stunde mal etwas reinziehen.
Noch keine Zeit dazu gehabt. Aber Async Flag nur True wenn Parameter gesetzt ist, jaaa das riecht nach ๐ von letztem Jahr.
Gott sein Dank habe ich mit dem Haufen nichts mehr am Hut, insofern keine große Intention deren Schrott zu auch noch zu debuggen, das habe ich schon vieeeel zu lange machen müssen. Wir sind seit 6 Monaten MS frei. Free as hell, und das rockt...
Gott sein Dank habe ich mit dem Haufen nichts mehr am Hut, insofern keine große Intention deren Schrott zu auch noch zu debuggen, das habe ich schon vieeeel zu lange machen müssen. Wir sind seit 6 Monaten MS frei. Free as hell, und das rockt...
Zitat von @MysticFoxDE:
P.S.
Man kann z.B. mit dem Ressorcenmonitor ...
... sehr einfach erkennen wenn RSC zuschlägt.
Sprich schau mal einfach selber bei dir nach, wie viele interne TCP Sessions mit einer Latenz von 40ms oder mehr laufen. ๐๐
P.S.
Man kann z.B. mit dem Ressorcenmonitor ...
... sehr einfach erkennen wenn RSC zuschlägt.
Sprich schau mal einfach selber bei dir nach, wie viele interne TCP Sessions mit einer Latenz von 40ms oder mehr laufen. ๐๐
Ich habe aktuell zwei RD-SH als VM auf dem selben ESXi laufen. In einer VM habe ich RSC abgeschaltet (nichts weiter, nur RSC). Ich beobachte die Ressourcenmonitore nur, es gibt keine wirkliche statistische Auswertung. Daneben beobachtet eine Userin das Anwendungsverhalten. Der ganze Test ist also erstmal rein subjektiv ausgelegt - ich will wissen, ob man einen Unterschied wahr nehmen kann.
Rein subjektiv würde ich definitiv mit nein antworten. Ich sehe nirgendwo etwas wo ich ernsthaft sagen kann, es gäbe einen Unterschied.
Ich habe durchaus ein paar Eindrücke gewonnen. Meine wichtigen Fachanwendungen, also mit lokaler Datenbank-Kommunikation, liegen bei Latenzen von <10, meist sogar <5 ms durchgehend, alle. Es gibt da nur wenig Schwankungen, ich glaube, da ist einfach nicht viel
Latenzen von >20 habe ich nur bei zwei Anwendungen: Edge und Office. Edge ist irgendwo "klar", bei Office ist das eher schockierend weil außer OneNote/Sharepoint alles lokal ist. Dennoch ist immer wieder Outlook und oft sogar Word ganz oben dabei wenn es um Nach-Hause-Verbindungen geht und das mit sehr hohen Latenzen ~50-200 ms. Ich sage jetzt mal so, bei einem guten Anwendungsdesign sollte die Latenz zu einem Lizenz- oder Metrik-System keine Rolle spielen, sollte... Es sind i.d.R. 10-15 Prozesse bei einer Latenz >20 ms, auf beiden Systemen in gleicher Weise.
Ich denke nach wie vor, das RSC auf RD-SH eigentlich besser nicht laufen sollte, ein guter Kandidat das grundsätzlich abzuschalten. Ich schließe nur erstmal daraus, das RSC in meiner Umgebung einfach praktisch keine Auswirkungen hat.
Ich denke ich werde mir nach Weihnachten mal dein komplettes Optimierungsscript rein ziehen und das auf einem virtuellen RD-SH umsetzen.
Zitat von @MysticFoxDE:
wenn du nur auf dem RD-SH das RSC deaktiviert hast, dann wirst du auf dem selben Server in dessen Ressourcenmonitore auch keine Verbesserung sehen, da die Verzögerungen die du hier bei den TCP Sessions siehst,
ja nicht von diesem Server selbst kommen, sondern von dem Gegenüber.
Guter Punkt, habe ich nicht in Betracht gezogen. Die Latenz müsste sich aber ein wenig verbessern weil ja auch Daten an den Gegenüber raus gehen und die sollten dann ja schneller verarbeitet werden, korrekt?wenn du nur auf dem RD-SH das RSC deaktiviert hast, dann wirst du auf dem selben Server in dessen Ressourcenmonitore auch keine Verbesserung sehen, da die Verzögerungen die du hier bei den TCP Sessions siehst,
ja nicht von diesem Server selbst kommen, sondern von dem Gegenüber.
Sprich, wenn du bei einer bestimmten Anwendung hohe Latenzen siehst, dann deaktiviere mal bitte das RSC auf dem System mit der entsprechenden Remoteadresse.
Das teste ich mal mit Exchange und eventuell DATEV. Am Wochenende gibts vermutlich eh Updates.Aber, wenn du auf dem entsprechenden Server bist, dann schau auch bitte gleich im Ressourcenmonitor nach, wie hoch die Datenträgerlatenz auf diesem ist ...
... wenn du hier schon sehr hohe Latenzen siehst, dann kommt dein Latenzproblem wahrscheinlich primär nicht vom Netzwerk, sondern eher vom Storage.
Ich denke ich werde mir nach Weihnachten mal dein komplettes Optimierungsscript rein ziehen und das auf einem virtuellen RD-SH umsetzen.
๐ฌ ... das ist nicht gut, da dieses nicht für Server gedacht ist, sondern nur für Clients mit NIC's <= 2,5 GBit.
Und selbst bei den Clients, darf man z.B. RSS nicht bei jeder NIC abschalten, sondern sollte es eher richtig konfigurieren. Ich habe mein Script aber noch nicht entsprechend angepasst, weil es auch nicht ohne ist rauszufinden, bei welcher NIC man RSS besser ein oder ausschalten sollte. ๐
Wenn du Lust hast, dann kann ich mal die Tage ein ๐๏ธ auf dein System werfen und dir dann etwas gezielter ein paar Tipps geben.
Lust ja, Zeit vielleicht Ich komme gerne noch darauf zurück, dann aber nicht über Weihnachten Series: DIE WINDOWS SERVER 2025 STORY
Windows Server 2025 - RDMA - Folge 02 - Der Intel-BIOS-Wirrgarten (german)Windows Server 2025 - RDMA - Folge 01 - Der Anfang des Grauens (german)6Windows Server 2025 - Energieoptionen per GUIs nicht änderbar (german)10Windows Server 2025 - NIC-Performance - Per Default sehr "durchwachsen" (german)55Windows Server 2025 - HARDWAREANFORDERUNGEN - Ich habe da einige Fragen (german)44