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.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 669379
Url: https://administrator.de/contentid/669379
Ausgedruckt am: 19.11.2024 um 01:11 Uhr
40 Kommentare
Neuester Kommentar
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
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
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.