mysticfoxde
Goto Top

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 …

test-lab nics


… 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):
i350


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):
p210

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):
x540

Ä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):
x710

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):
e810

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.

Content-ID: 669379

Url: https://administrator.de/knowledge/windows-server-2025-nic-performance-per-default-sehr-durchwachsen-669379.html

Ausgedruckt am: 21.12.2024 um 13:12 Uhr

MysticFoxDE
MysticFoxDE 09.11.2024 aktualisiert um 22:12:47 Uhr
Goto Top
Moin Zusammen,

ähm ja, ich wollte ja als nächstes das hier machen ...

Und danach würde ich den Server 2025, energieoptionstechnisch von „Ausbalanciert“ … 🤢🤮 … auf "Hochleistung" stellen und dann schauen wir mal was danach passiert.

... jedoch habe ich mich entschlossen, noch eine kleine andere Messung dazwischenzuschieben.

Und zwar habe ich bei beiden Servern vorhin das BIOS auf Default gesetzt und auch bei den Broadcom P210, deren BIOS ebenfalls und habe danach lediglich den Boot-Mode auf UEFI umgestellt und anschliessend die Messung wiederholt.

Kleiner Spoiler, es wird immer verwirrender. 😬

Na ja, schaut es euch am besten selber an.

By the way, der Murks mit der Paketdifferenz ist weiterhin bei allen Messungen sichtbar, daher werde ich diesen nicht zusätzlich kommentieren. 😔

Jetzt aber zu den Ergebnissen.

I350 <--> I350 (1G):
i350 - bios & os default

Bei der I350 hat sich nicht wirklich viel bewegt.

P210 <--> P210 (10G):
p210 - bios & os default

Die P210 jedoch, läuft nun mit 31,953 MB/s, sprich, nun um ~ 8 MB/s schneller. 😵‍💫
Das verstehe ich ehrlich gesagt (noch) nicht wirklich.

X540 <--> X540 (10G):
x540 - bios & os default

Die X540 läuft nun nur noch mit ~6 MB/s, sprich um ca. 1 MB/s lahmer als bei der vorherigen Messung.

X710 <--> X710 (10G):
x710 - bios & os default

Die X710 ist nun wiederum um ~ 3 MB/s schneller.

E810 <--> E810 (25G):
e810 - bios & os default

Und die E810, läuft nun auch um ~ 3 MB/s schneller.

WTF 😖

Als nächstes werde ich mal das BIOS wieder auf High-Performance trimmen und auch die Energieoptionen des Server 2025 auf Hochleistung schrauben.

Gruss Alex
MysticFoxDE
MysticFoxDE 10.11.2024 um 00:04:21 Uhr
Goto Top
Moin Zusammen,

so, nachdem ich den Server 2025 zu "Höchstleistung" ...

Windows Server 2025 - Energieoptionen per GUIs nicht änderbar

... etwas zwingen musste, habe ich die Messung mit BIOS und OS auf (theoretisch) "Höchstleistung" erneut wiederholt.

I350 <--> I350 (1G):
i350 - bios & os hp

P210 <--> P210 (10G):
p210 - bios & os hp

X540 <--> X540 (10G):
x540 - bios & os hp

X710 <--> X710 (10G):
x710 - bios & os hp

E810 <--> E810 (25G):
e810 - bios & os hp

Ähm ja, ihr seht das richtig, die Performance ist leider durchgängig schlechter geworden. 😬

Sprich, "High Performance", scheint heutzutage nicht mehr wirklich "High Performance" zu sein. 😔😭

Gruss Alex
em-pie
em-pie 10.11.2024 um 10:34:10 Uhr
Goto Top
Moin,

Schon interessant, was da an Durchsatz auf der Strecke bleibtface-confused

Sind das eigentlich die MS-Treiber für die NICs oder die Intel/ BROADCOM-Treiber?
MysticFoxDE
MysticFoxDE 10.11.2024 aktualisiert um 10:39:42 Uhr
Goto Top
Moin Zusammen,

ich habe soeben glaube ich den Grund für die schlechte Performance der X540 gefunden.

ws2025 - x540 - outdated driver

Ja, richtig, der Treiber ist schon etwas älter.

Aber, ich habe auf den Servern nur die aktuellsten Intel Treiber, sprich, "Wired_driver_29.3_x64" installiert und in diesen ist der Treiber für die X540 nicht mehr enthalten. 🙃

Sprich, diesen sehr veraltetet Treiber, hat sich der Server 2025 selber über das Windows-Update gezogen ...

ws2025 - x540 - windows update

... dabei ist dieser nicht mal mehr für Server 2022 freigegeben. 😭 🙊🙈 🤢🤮

Ich sehe schon, auch beim Server 2025 bleibt die Spannung durchaus erhalten. 🙃

Gruss Alex
MysticFoxDE
MysticFoxDE 10.11.2024 aktualisiert um 11:34:35 Uhr
Goto Top
Moin Zusammen,

ich habe soeben auf dem Test-Server 1 das Driver Setup (Wired_driver_29.3_x64) entpackt und obwohl Intel in der Beschreibung für diese Version ...

https://www.intel.de/content/www/de/de/download/706171/intel-network-ada ...

... die X540 nicht explizit als supportete NIC mit angibt, konnte der Windows Server in den entpackten Driver Setup (29.3), dennoch einen Treiber für die X540-T2 finden. 🙃

Bei der Installation dieses Treiber, kam jedoch die folgende Warnmeldung ...

ws2025 - x540 - install 29.3 - warning

... die ich natürlich mit "trotzdem installieren" mal quittiert habe, ist ja auch nur ein Testsystem. 🤪

Und schon war der folgende Treiber für die X540 installiert ...

ws2025 - x540 - install 29.3 - driver version

... also, ein um 4 Jahre jüngerer Treiber. 😁

Dann bin ich auf den zweiten Test-Server gegangen, der NIC-technisch identisch bestückt ist und wollte auf diesem dasselbe auch machen. Doch zuvor wollte ich kurz nachprüfen was auf diesem Server aktuell für ein Treiber läuft und habe dann das folgende zum Sehen bekommen ...

ws2025 - x540 - default - driver version - server2

... sprich, auf dem Server2 läuft die X540-T2, mit noch einem neuerern Treiber, ohne das ich etwas machen musste.

😭 ... das wird ja immer gruseliger. 😔

Gruss Alex


P.S. Intel macht es einem aber auch nicht leicht. 😔

https://www.intel.de/content/www/de/de/download/706171/intel-network-ada ...

In der folgenden Beschreibung für den 29.3er Treiber, die jedoch nur für Server 2022 gilt, ist die X540-T2 nicht gelistet.

Aber, in der folgenden, die jedoch nur für Server 2019 gilt, aber auch Version 29.3 ...

https://www.intel.de/content/www/de/de/download/19372/intel-network-adap ...

... ist die X540-T2 gelistet.

Die Treiber-Setup-EXE, ist jedoch in beiden Fällen absolut identisch. 🙃

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? 🤔
Lochkartenstanzer
Lochkartenstanzer 10.11.2024 aktualisiert um 12:15:04 Uhr
Goto Top
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? 🤔

Weil er es kann. face-smile

lks
150940
150940 10.11.2024 aktualisiert um 12:37:55 Uhr
Goto Top
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.

screenshot
MysticFoxDE
MysticFoxDE 10.11.2024 aktualisiert um 13:57:39 Uhr
Goto Top
Moin @150940,

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.

screenshot

😮 ... denn kannte ich auch noch nicht, danke.

Aber ja, deshalb liebe ich die IT trotzdem, weil man bei dieser selbst als alter 🐇/🦊, ständig noch etwas dazulernen kann. 😁

Was mich jetzt jedoch eher beschäftigt, ist die Frage, warum die X540, unter Server 2025, vor allem ohne Hyper-V, nicht die volle Leistung bringt. 🤔

Mit Hyper-V kann ich es ja noch verstehen, aber ohne kann ich es stand jetzt absolut nicht nachvollziehen. 😔

Ich denke, ich installiere auf den beiden Lab-Server mal Server 2019 und teste mal mit diesem nochmal nach. 😩

Gruss Alex
Vision2015
Vision2015 10.11.2024 um 17:54:09 Uhr
Goto Top
Moin...

auf einem HP Dl380 G10 ähnliches ergebnis mit ner HPE 544 Nic... 40 Gbit/s bzw. 10 Gbit/s leistung ist unterirdisch!

Frank
MysticFoxDE
MysticFoxDE 10.11.2024 um 19:21:29 Uhr
Goto Top
Moin Zusammen,

so die Server sind nun jeweils mit Server 2019 bespielt und auch auf den neusten Stang geupdatet.
Ich habe wie auch beim 2025er, beim 2019er die Firewall deaktiviert und den Defender deinstalliert und auch alle Treiber, bis auf die von den NIC's installiert. Die Treiber habe ich bisher mit Absicht mal per Windows Update saugen lassen.

Und so sieht der Treiberstand nach Aktualisierung durch Windows Update aus ...

ws2019 - default - driver version

... bis auf die Treiber der X710, seinen sich alle anderen zu gleichen.
Und das mit der X710 sehe ich nicht ganz so kritisch, da es auch nicht ganz 1:1 die selben X710 sind.

Anschliessend habe ich dieselbe Messung ausgeführt, wie auch zuvor beim Server 2015, folgend die Ergebnisse.

Ach ja, der Murks mit der Paketdifferenz ist auch schon beim Server 2019 so, ich habe jedoch schon herausgefunden,
welches Feature das zu verantworten hat ... 😁 ... dazu jedoch später.

Und noch was Wichtiges, das BIOS der Server ist auf High-Performance getrimmt, das OS jedoch noch nicht, sprich dieses läuft auf "Ausbalanciert".

I350 <--> I350 (1G):
ws19 - default - i350 - bios hp - os bl - ms driver

Die I350, ist mit ~ 15 MB/s fast genau so schnell, wie auch bei den bisherigen Messungen mit Server 2025.

P210 <--> P210 (10G):
ws19 - default - p210 - bios hp - os bl - ms driver

Und das ist jetzt eine Überraschung, mit etwas mehr als 35 MB/s, liefert die P210 bisher das beste Ergebnis. 🙃

X540 <--> X540 (10G):
ws19 - default - x540 - bios hp - os bl - ms driver

Aber, die X540 läuft nun auch annähernd mit der Leistung, die auch die X710 unter Server 2025 gebracht hat.

Warum also läuft diese NIC unter Server 2025 nur mit 5-6 MB/s? 🤔

X710 <--> X710 (10G):
ws19 - default - x710 - bios hp - os bl - ms driver

Die X710 ist diesemal sogar etwas lahmer als die X540. 🙃

E810 <--> E810 (25G):
ws19 - default - e810 - bios hp - os bl - ms driver

Und die E810, bringt trotz ihrer 25G, nicht mehr als die I350 mit 1G. 😖

Ja, es bleibt spannend.

Ich werde als nächstes nun die aktuellsten Herstellertreiber für die NIC's installieren und auch die Energieoptionen des Server 2019 auch mal auf Hochleistung stellen und anschliessend nochmals messen. 😩

Dazwischen werde ich aber noch was futtern.

Gruss Alex
MysticFoxDE
MysticFoxDE 10.11.2024 um 19:22:01 Uhr
Goto Top
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
Vision2015
Vision2015 10.11.2024 um 19:53:30 Uhr
Goto Top
Moin..
Zitat von @MysticFoxDE:

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?
NTttcp mit deinen werten! alle werte auf max High-performance, standard treiber!


Gruss Alex
Frank
MysticFoxDE
MysticFoxDE 10.11.2024, aktualisiert am 11.11.2024 um 05:59:24 Uhr
Goto Top
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.

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
Vision2015
Vision2015 11.11.2024 um 06:30:21 Uhr
Goto Top
Moin...
Zitat von @MysticFoxDE:

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 face-smile

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
MysticFoxDE
MysticFoxDE 11.11.2024 aktualisiert um 07:29:06 Uhr
Goto Top
Moin Zusammen,

ich habe gestern Abend noch einiges an dem Server 2019 rumgefuchst, sprich, unter anderem RSC, Interrupt-Moderation, sowie Delayed-ACK deaktiviert, RSS optimaler konfiguriert, CUBIC wieder gegen DCTCP getauscht, Sende- und Empfangspuffer der NIC's vergrössert und nun sehen die Ergebnisse etwas anders aus. 😁

I350 <--> I350 (1G):
ws19 - optimized - i350 - bios hp - os up - mf driver

Ja, die Intel I350 schafft nun mit demselben Testmuster einen Durchsatz von ~ 46 MB/s, sprich, das dreifache wie bei den Messungen zuvor. Das ist bisher übrigens das zweitbeste Ergebnis und dass, nur mit 1G.

P210 <--> P210 (10G):
ws19 - optimized - p210 - bios hp - os up - mf driver

Die Broadcom P210 liefert mit fast 32 MB/s nun zwar ein gutes Ergebnis, ist aber langsamer als die I350 mir 1G.

X540 <--> X540 (10G):
ws19 - optimized - x540 - bios hp - os up - mf driver

Tja, und das ist bisher die grösste Überraschung. Denn die Intel X540, die zuvor ja die schlechteste Performance hatte, liefert bei dieser Messung mit etwas über 55 MB/s, nun bisher die beste Performance ab. 🙃

X710 <--> X710 (10G):
ws19 - optimized - x710 - bios hp - os up - mf driver

Die Intel X710 ist mit knapp über 32 MB/s nun ähnlich schnell wie die Broadcom P210.

E810 <--> E810 (25G):
ws19 - optimized - e810 - bios hp - os up - mf driver

Und die Intel E810, liefert mit fast 31 MB/s nun auch eine deutlich bessere Performance, ist aber mit ihren 25G, nun trotzdem die langsamste. 😖

Aus der Messreihe ergeben sich bei mir aktuell die folgenden Fragen.

Warum läuft nun die I350, also eine 1G NIC, schneller als die P210 oder die X710, die beide mit 10G laufen und auch schneller als die E810 mit ihren 25G?
Warum kann die X540 nun 55 MB/s erreichen und die anderen beiden 10G NIC's nicht?
Warum macht Microsoft so einen Murks per Default überhaupt?
Warum folgen die NIC-Hersteller fast blind den Konfigurationsempfehlungen von Microsoft ohne diese selber mal auf Sinnhaftigkeit zu testen?
u.s.w.

Ach ja, Falls sich der eine oder andere fragt "Was läuft schon mit Blöcken von 4K oder gar darunter?".
Na ja, nur so Dinge wie DNS, WINS, DHCP, NTLM, NTP, SNMP, Kerberos, SQL, iSCSI, u.s.w., also eine ganze Menge. 😔

Ich werde nun als nächstes mal eine Gegenmessung mit iPerf machen.

Gruss Alex

P.S.
Bitte auch berücksichtigen, dass sämtliche bisherigen Messungen ohne Hyper-V, sprich ohne jegliche vSwitche und vNIC's gemacht wurden!
Mit Hyper-V sieht die Sache leider noch um einiges düsterer aus, vor allem ohne VMQ oder SR-IOV. 😔
Starmanager
Starmanager 11.11.2024 um 07:28:25 Uhr
Goto Top
Microsoft und die Hersteller wollen sicherstellen, dass wir mit jedem Windows Release einen neuen Server kaufen. Passiert das auch mit Linux so?

Vielen Dank fuer deine wertvolle Zeit um uns vor den Problemen zu warnen.

Schoene Gruesse und einen guten Start in die neue Woche.
MysticFoxDE
MysticFoxDE 11.11.2024 um 10:27:24 Uhr
Goto Top
Moin @Starmanager,

Microsoft und die Hersteller wollen sicherstellen, dass wir mit jedem Windows Release einen neuen Server kaufen.

na ja, Microsoft verfolgt schon auch nicht nur technische sondern vor allem auch Kaufmännische Dinge.
Aber, in diesem Fall bin ich mir ziemlich sicher, dass das Problem an der Entwicklung liegt.
Um Genau zu sein an der Kommunikation. Und zwar habe ich das Gefühl, dass und vor allem die MS Entwickler überhaupt keinen Plan mehr davon haben, was für die meisten Windows-Server Admin/Benutzer wirklich wichtig ist und noch noch das Programmieren, was deren Vertrieb oder Marketing für wichtig hält. 😔
Aber, auch untereinander scheinen die sich nicht mehr so wirklich auszutauschen, sprich, MS sprich nur noch bedingt mit Intel oder Broadcom und auch umgekehrt. 😭

Passiert das auch mit Linux so?

Ja, bei dem Pinguin sieht es an vielen Stellen mittlerweile leider nicht viel besser aus. 😔

Vielen Dank fuer deine wertvolle Zeit um uns vor den Problemen zu warnen.

Sehr gerne.
Ich will mir ehrlich gesagt erst gar nicht ausrechnen, was dieser ganze Murks bisher schon an Schaden verursacht hat. 😔

Schoene Gruesse und einen guten Start in die neue Woche.

Ebenso!

Gruss Alex
MysticFoxDE
MysticFoxDE 11.11.2024 aktualisiert um 22:45:34 Uhr
Goto Top
Moin Zusammen,

ich habe zwar geschrieben, dass ich als nächstes eine Messung mit iPerf machen möchte, ich habe mich jedoch noch für eine weitere Runde NTTTCP entschlossen, habe davor jedoch noch ein bisschen nachoptimiert, vor allem was "TCP_NODELAY" angeht, was ja angeblich schon seit Server 2012 nicht mehr implementiert sein sollte. 😔
Und ich habe den NTTTCP auch mal gesagt, dass er doch bitte auch die WINSOCK Puffer verwenden soll, denn das macht er per Default warum auch immer auch nicht. 😬

!! Aber, an dem Testpattern selber, sprich, 4K mit einem Worker und einem oIO, habe ich nichts verändert. !!

Nun sieht das Ergebnis folgend aus und nein, das was jetzt kommt ist KEIN Scherz!

I350 <--> I350 (1G):
ws19 - better optimized - i350 - bios hp - os up - mf driver

Die I350 ist mit 113 MB/s komplett ausgelutscht. 😁

P210 <--> P210 (10G):
ws19 - better optimized - p210 - bios hp - os up - mf driver

Die Broadcom P210 kommt nun auf ~ 540 MB/s.

X540 <--> X540 (10G):
ws19 - better optimized - x540 - bios hp - os up - mf driver

Die X540 beweist mit ~ 578 MB/s, sprich, dem Besten Ergebnis, dass man einen alten Gaul nicht unterschätzen sollte. 🤪

Und theoretisch könnte die auch noch etwas schneller, doch die CPU-Kern, auf dem der NTTTCP die Last generiert ...
ws19 - better optimized - x540 - bios hp - os up - mf driver - messurment
... ist leider schon ausgelutscht. Der eine auf dem die X540 selber läuft, jedoch bei weitem noch nicht und theoretisch könnte die NIC für die Datenverarbeitung auch noch 3 weitere Kerne einbeziehen. 😁

X710 <--> X710 (10G):
ws19 - better optimized - x710 - bios hp - os up - mf driver

Die X710 kommt mit ~ 437 MB/s leider nicht an die P210 und schon gar nicht an die X540 heran und ich habe beim Testen ein sehr komisches Verhalten festgestellt, was ich jedoch aufgrund meines mittlerweile sehr leeren Akkus, heute zumindest nicht mehr durchgehen möchte.
Aber, sie läuft ja schon mal etwas schneller als per Default. 🙃

E810 <--> E810 (25G):
ws19 - better optimized - e810 - bios hp - os up - mf driver

Und die Intel E810, liefert mit fast 425 MB/s leider weniger wie die schlechteste 10G NIC.
Aber, mir ist da Gestern was eingefallen, der Server hat ja nur PCIe 3.0 und die E810 ist eigentlich eine PCIe 4.0 NIC. 😬
Und eigentlich habe ich die ja auch nur in die Server reingesteckt, um zu sehen ob der Hyper-V, mit deren üppigen SR-IOV Ressourcen zurecht kommt und weniger um deren Durchsatz zu testen.
Sprich, bitte deren Ergebnisse nicht zu ernst nehmen!

Aber ja, ich würde mal sagen, das war jetzt noch ein ordentlicher Ruck. 😁
Wenn man natürlich zu den Default Werten vergleicht, dann eher ... 😱😭🤢🤮🤢🤮 u.s.w.

Ach so, ja @redmond-microsoftianer, um es mal mit den Worten der Bavarianer zu sagen.

Himmiherrgottzagramentzefixhallelijamilextamarschschei#sglumpfargets 😔

Gruss Alex
Vision2015
Vision2015 12.11.2024 um 05:27:49 Uhr
Goto Top
Moin...
habe davor jedoch noch ein bisschen nachoptimiert, vor allem was "TCP_NODELAY" angeht, was ja angeblich schon seit Server 2012 nicht mehr implementiert sein sollte. 😔
was genau hast du alles optimiert, und wie?

Frank
MysticFoxDE
MysticFoxDE 12.11.2024 um 07:14:26 Uhr
Goto Top
Moin Frank,

was genau hast du alles optimiert, und wie?

die Kurzfassung. Ich habe gefühlt so gut wie alles, zumindest das was ich bisher gefunden habe, rausgerupft und oder zurück konfiguriert, was die Microsoftians/Netwerkkartenhersteller netzwerktechnisch nach dem Server 2012R2, dazugemurkst haben, stellenweise sogar ab 2008. 😔

Die längere Fassung bekomme ich jetzt aber nicht so schnell auf die Kette, da einige Anpassungen auch Systemspezifisch sind, wie z.B. RSS. Dieses muss z.B. sowohl in Abhängigkeit von der jeweils verwendeten CPU, dem verwendeten PCIe Steckplatzt (korrekte NUMA Zuordnung) und auch der realen Uplink-Geschwindigkeit optimiert werden.

Zum Thema korrekte NUMA Zuordnung, habe ich jedoch schon im April 2020, bei Spiceworks mal den folgenden Post geschrieben ...

https://community.spiceworks.com/t/server-2019-network-performance/72496 ...

... und einige der Anpassungen sind auch schon im folgenden Beitrag enthalten ...

Wie man das Windows 10 und 11 TCP-Handling wieder desuboptimieren kann

... siehe z.B. Skript "DISABLE RSC" & "DISABLE INTERRUPT MODERATION" & "DISABLE ENERGY-EFFICIENT-ETHERNET" & "DISABLE TCPDELAY".

Alles sollte auf einem Server, so wie ich das auch ausdrücklich in dem Beitrag geschrieben habe, aus diesem Skript jedoch nicht ausgeführt werden.

Ich schreibe später/die Tage auf jeden Fall noch mehr Details zu dem was und wie es angepasst oder deaktiviert wurde.

Ich bin mit den Anpassungen fürchte ich auch noch nicht zu 100% durch, vor allem auch was die X710 angeht. 🙃

So, jetzt muss ich aber schnell zum nächsten Termin flitzen.

Gruss Alex
ukulele-7
ukulele-7 12.11.2024 um 09:06:35 Uhr
Goto Top
Ich fürchte, du wirst uns eine Anleitung schreiben müssen. Erklär es mir, als wenn ich 5 wäre face-smile

Allerdings interessiert mich eher Virtualisierung. Wobei ich einen Datensicherungsserver mit iSCSI habe...
MysticFoxDE
MysticFoxDE 12.11.2024 um 10:17:15 Uhr
Goto Top
Moin @ukulele-7,

Ich fürchte, du wirst uns eine Anleitung schreiben müssen. Erklär es mir, als wenn ich 5 wäre face-smile

das wird aber fürchte ich nicht wirklich einfach, da viele Einstellungen von der jeweiligen Hardware abhängen und auch von Hersteller zu Hersteller anders benannt werden. 😔😭

Daher verfolge ich momentan parallel auch noch einen anderen Ansatz und zwar MS dazu zu bringen, es gleich per Default besser zu machen. 😁

Das ist jedoch ein sehr mühsamer und sehr steiniger Weg ... 😩 ... aber, es ist meiner Ansicht nach jedoch der richtigere, dann muss auch jeder für sich nicht so viel selber an seinen Systemen herumfummeln. 🙃

Allerdings interessiert mich eher Virtualisierung.

Virtualisierung ... 😱 ... das habe ich mit voller Absicht bisher ausgelassen, denn spätestens ab da, wird dieser jetzt schon sehr komplizierte Jungle, noch viel viel verrückter. 😔

Wobei ich einen Datensicherungsserver mit iSCSI habe...

Oh ja, bei einem reinen Bare-Metale-System, sprich ohne HV und vor allem bei iSCSI, kann man mit den entsprechenden Anpassungen eine ganze Menge herausholen.

Ich versuche in der nächsten Zeit mal ein grobes Optimierungs-Skript auch für den Server zu erstellen, das kann jedoch etwas dauern, da auch meine Ressourcen nicht unendlich sind.

Daher versuche ich auch parallel eher die von MS anzuzapfen, da, mal unabhängig davon, dass die vieles selbst vermurkst haben, definitiv etwas mehr Manpower als wir für sowas übrig haben sollten.

Gruss Alex
ukulele-7
ukulele-7 12.11.2024 um 10:24:05 Uhr
Goto Top
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.
MysticFoxDE
MysticFoxDE 12.11.2024 um 22:28:47 Uhr
Goto Top
Moin @ukulele-7,

Dennoch glaube ich, kann man mit einem Kompendium a la aqui zu einem Thema einen nützlichen Leitfaden zu so einem Thema machen.

wenn ich alles beschreiben würde, was ich schon jetzt über den ganzen Murks zusammengesammelt habe, dann wird es wahrscheinlich ein Horror-Roman mit über 1000 Seiten. Siehe alleine schon das was ich bei Spiceworks geschrieben habe. 😔

Zudem, viele Dinge sind schlichtweg falsch und müssen meiner Ansicht nach ASAP durch Microsoft selbst behoben werden.

Eines der besten Beispiele ist das RSC (Receive Segment Coalescing), welches ich mittlerweile absolut abgrundtief hasse.

Ich habe ja am Anfang dieses Beitrags mitunter auch darüber Gemeckert, dass die Anzahl der von Sender versendeten Pakete, zum Teil sehr gravierend von der Anzahl der vom Empfänger empfangenen Pakete abweicht.
Sprich, irgendwo zwischen der sendenden Applikationsschicht und der empfangenden Applikationsschicht, hat sich ein Mechanismus eingeschlichen, der das originale Übertragungs-/Paketmuster verändert. 😔

Na ja, ich habe mittlerweile den Grund dafür gefunden und dreimal darfst du raten was es war ... jawohl, mal wieder dieses beschissene RSC. 🤮🤮🤮

Ich bin jedoch nicht gleich darauf gekommen, weil eigentlich nur 2 der 5 NIC's die ich zum Testen verwendet habe, RSC hardwaremässig überhaupt unterstützen ...

nics with rsc support

... das anormale Verhalten jedoch auf allen NIC's zu sehen war.

Und auch selbst als ich mit dem folgenden Befehl ...

Get-Netadapter | Disable-NetAdapterRsc -IPv4 -IPv6

... RSC auch auf den Adaptern deaktiviert habe, die es hardwaremässig und auch treibermässig unterstützen, blieb das anormale Verhalten weiterhin bestehen.

Dann habe ich RSC, direkt am TCP-Stack des Betriebssystems deaktiviert, was mit dem folgenden Befehl möglich ist ...

netsh int tcp set global RSC=Disabled

... und schon war das annormale Verhalten so gut wie verschwunden und alle NIC's lieferten anschliessend mehr Leistung. 😔

Also, warum zur Hölle greift RSC schon softwareseitig im TCP-Stack des Betriebssystems, obwohl die NIC's über die der entsprechende Datenverkehr fliessen soll, RSC überhaupt nicht unterstützen, oder dieses im Treiber deaktiviert ist ? 🤔

Oder, warum greift TCP-Delay, obwohl es eigentlich gar nicht mehr implementiert sein sollte.

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. 😔😭

Gruss Alex
Lochkartenstanzer
Lochkartenstanzer 13.11.2024 aktualisiert um 00:37:12 Uhr
Goto Top
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. 😔😭

Agile programming und kleine Terrorzellen Teams, die voneinander abgeschottet sind, nehme ich an. Da wird nur im eigenen Bereich optimiert und entwickelt, ohne den großen Plan zu kennen. face-sad

lks
ukulele-7
ukulele-7 13.11.2024 um 08:45:22 Uhr
Goto Top
Ich weiß ungefähr soviel über RSC was in einem Absatz auf Wikipedia steht aber mal ne ganz blöde Frage: In welchem, gewöhnlichen Szenario profitiert man eigentlich von RSC? Ich meine, wir haben mittlerweile viel mehr viel effizientere CPU Kerne als früher?
MysticFoxDE
MysticFoxDE 13.11.2024 um 09:04:00 Uhr
Goto Top
Moin @Lochkartenstanzer,

Agile programming und kleine Terrorzellen Teams, die voneinander abgeschottet sind, nehme ich an. Da wird nur im eigenen Bereich optimiert und entwickelt, ohne den großen Plan zu kennen. face-sad

ja, +- hast du damit leider nicht unrecht. 😔

Gruss Alex
MysticFoxDE
MysticFoxDE 13.11.2024 aktualisiert um 09:33:41 Uhr
Goto Top
Moin @ukulele-7,

Ich weiß ungefähr soviel über RSC was in einem Absatz auf Wikipedia steht aber mal ne ganz blöde Frage: In welchem, gewöhnlichen Szenario profitiert man eigentlich von RSC?

ich könnte glaube ich mittlerweile eine Doktorarbeit darüber schreiben, ich versuch es aber dennoch mal so einfach wie möglich. 🙃

RSC macht überall da Sinn, wo eine Datenübertragung nicht latenzkritisch ist. Sprich, z.B. beim Streamen von Youtube-Videos, weil diese vom Player normalerweise im Hintergrund zwischengecacht werden, oder z.B. beim saugen von Updates. Für alle anderen Dinge, vor allem für die, wo der Anwender die Rückinfo so schnell wie möglich benötigt, ist RSC einfach nur pures Gift. 😔

Sprich, eigentlich sollte dieses Feature nur mit Bedacht und nur bei bestimmten Anwendungsszenarien aktiviert werden, es ist jedoch sowohl bei Windows, als auch mittlerweile bei den Pinguinen, per Default aktiv und wird auch auf so gut wie jeden Datenverkehr angewendet. 😭🤢🤮

Ich meine, wir haben mittlerweile viel mehr viel effizientere CPU Kerne als früher?

👍👍👍 exakt 👏👏👏

Und der RAM ist deutlichst schneller geworden, auch der PCI-E Bus u.s.w., daher machen viele der Features wie z.B. die Interrupt-Moderation, stand heute auch nicht wirklich viel Sinn. Im Gegenteil, bei der heutigen Hardware verursachen diese Features eher das Gegenteil dessen, was die früher bewirkt haben.

Denn, was bringt einem schon z.B. ein neues SAN/NAS, welches die IO's dank modernster SSD's mit unter 0,01ms abfrühstückt, wenn, sobald diese IO's über das Netzwerk wandern, von Windows oder auch Linux, bis zu 40ms draufgepackt werden und bei TCP-Delay sind es sogar bis zu 200ms. 😭

Gruss Alex

P.S.
Man kann z.B. mit dem Ressorcenmonitor ...
ressourcenmonitor - latenz
... 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. 😉😔
ukulele-7
ukulele-7 13.11.2024 um 10:57:33 Uhr
Goto Top
Ich habe mir mal ein Testszenario überlegt in dem ich mir zwei Windows 2019 RD-SH als VM auf dem selben Host mit RSC und ohne anschaue. Wirkt die Deaktivierung ohne Neustart? Spricht etwas dagegen das mit aktiven RDS Usern ab- oder zuzuschalten?
MysticFoxDE
MysticFoxDE 13.11.2024 aktualisiert um 12:45:55 Uhr
Goto Top
Moin Zusammen,

@microsoft
Mein Puls ist wegen eurem NTTTCP Klump gerade auf über 180! 😡

aber ja, erstmal alles der Ruhe/Reihe nach. 🙃

Ähm, ja aber wie soll ich das jetzt am besten beschreiben.

Also, mein aktuelles NTTTCP Testpattern sieht folgend aus ...

#NTttcp Sender:
NTttcp.exe -s -m 1,22,192.168.10.2 -l 4K -a 1 -n 100 -nic 192.168.10.1 -v -sb -1 -lm

#NTttcp Receiver:
NTttcp.exe -r -m 1,22,192.168.10.2 -n 100 -v -lm -rb -1

... was unter dem Strich das folgende machen sollte und zwar immer nur ein "Datenblock" ("-a 1") mit einer Grösse von 4K ("-l 4K") mit nur einem Worker "(-m 1,22,192.168.10.2)" Richtung des Empfängers senden und zwar bis 100 Blöcke (-n 100) übertragen wurden. Sprich, der NTTTCP sollte hintereinander eigentlich nur 100 4K Blöcke senden und zwischen dem Senden der einzelnen Blöcke jedoch abwarten, bis der zuvor gesendete Block vom Empfänger auch quittiert wurde.

Tja und als ich soeben mit dem Kabel🦈 (WireShark) die Übertragung belausch/mitgeschnitten habe, musste ich mir das folgende ansehen, das ist übrigens auch schon der vollständige Mitschnitt von 100 * 4K Blöcken ...

wireshark - ntttcp

... 😱 ... 😵‍💫😖😵 ... 🙊🙈

Sprich bei Paket Nr. 23 geht es los und zwar mit am Stück 3 Ethernet Paketen mit einer Grösse von !! 4150 Bytes !! und dann kommt noch eins (PNr. 26) mit 1514 Bytes hinterher und danach folgt erst das ACK Paket vom Empfänger (PNr. 27), welches die vier zuvor übermittelten Pakete quittiert, die in Summe eine TCP-Payload von 13748 Bytes (~13,42K) haben.

Also nix mit, immer schön ein Block nach dem anderen senden und dazwischen auf die Rückantwort warten und nein auf den NIC's sind auch keine Jumboframes aktiviert. 😔

Und spätestens ab dem 28 Paket wird es richtig gruselig, denn dieses ist 24874 Bytes gross, das nach dem ACK (PNr. 29) darauf folgende (PNr. 30) hat schon 38014 Bytes, danach kommt das nächste (PNr. 32) mit 49694 Bytes und das darauffolgende (PNr. 34) hat 61374 Bytes, u.s.w. 🙃

Und ja, eigentlich hat bei WireShark ein Ethernet Frame (ohne 🐘-Frames) normalerweise nur eine maximale grösse von 1514 Bytes und wenn der NTTTCP auch keinen Murks machen würde und in dem Fall senderseitig LSO (Large Send Offload) auch nicht dazwischen pfuschen würde, sollte es eigentlich eher so ...
wireshark - iperf
... aussehen.

@microsoft
Ja, das der letzte Screenshot ist von einem Testlauf mit iPerf, der macht das nämlich so wie es sein sollte (LSO manuell deaktiviert). 😉

Verdammt, jetzt muss ich alle Baselines mit iPerf neu erstellen. 🤮🤮🤮

@microsoft
Was soll eigentlich dieser ganze Murks? 🤨😡

Gruss Alex
150940
150940 13.11.2024 aktualisiert um 11:35:47 Uhr
Goto Top
@microsoft
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 😂.
MysticFoxDE
MysticFoxDE 13.11.2024 aktualisiert um 11:52:44 Uhr
Goto Top
Moin @150940,

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 😂.

ich habe schon mindestens einen Übersetzer (MVP) dazwischen geschaltet, der denen das hoffentlich in deren Sprache gut übersetzen kann. 😉🙃

Ausserdem, das meiste was ich geschrieben habe, scheint z.B. Bing weitestgehend korrekt zu übersetzen, selbst mit ...

Himmiherrgottzagramentzefixhallelijamilextamarschschei#sglumpfargets

bing-translate-himmiherrgottzargrament

“Heavenly Lord God, sacrament, damn it, hallelujah, my dear, damn it, shit, junk, get lost!”

... was laut dem Google Übersetzer wiederum das folgende bedeutet ...

google-translate-himmiherrgottzargrament en to de

... hat es nur bedingt Probleme. 🤪


Gruss Alex
Lochkartenstanzer
Lochkartenstanzer 13.11.2024 um 12:54:57 Uhr
Goto Top
Moin,

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
MysticFoxDE
MysticFoxDE 14.11.2024 um 10:18:24 Uhr
Goto Top
Moin @150940,

Du musst denen schon auf Englisch schreiben ...

bitte sehr ...

https://github.com/microsoft/ntttcp/issues/23

... ich fürchte jedoch, dass da nicht wirklich jemand darauf reagieren wird. 😔

Schau dir mal den Verlauf der anderen Cases an. 😭

Na ja, so wie es aussieht verwendet ausser Microsoft selbst, wohl so gut wie niemand sonst NTttcp und daher ist der Fehler bisher auch nicht wirklich aufgefallen. 🙃

Und ich habe NTttcp primär nur deshalb verwendet, weil wie ich schon zuvor geschrieben habe, Microsoft bei Problemen/Supportcases die iPerf Ergebnisse nicht wirklich akzeptiert, sondern mit der Begründung, dass iPerf die Dinge nicht richtig machen würde, auf NTttcp verweist.

Ich finde das so langsam richtig zum 🤮.

Gruss Alex
150940
150940 14.11.2024 aktualisiert um 10:26:53 Uhr
Goto Top
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 😂.
Starmanager
Starmanager 14.11.2024 um 18:31:58 Uhr
Goto Top
Um den Amis etwas klar zu machen werden Bedienungsanleitungen mit Bildern ausgestattet. Vorteil fuer Migranten, die Inder bei MS und Analphabeten. Vielleicht sollten wir uns auf dieses Niveau einlassen um ihnen mit Bildern erklaeren was das Problem mit ihrer perfekten Software ist.
MysticFoxDE
MysticFoxDE 16.11.2024 um 17:42:58 Uhr
Goto Top
Moin @150940,

Selbst das Tool für ihre eigenen Betriebssysteme zu tweaken sind sie zu doof 😂.

glaub mir, insbesondere dieser Punkt bringt mich momentan so richtig zur Weissglut. 😡

Denn ich habe früher immer mit iPerf gemessen. Dann habe ich wegen Performanceproblemen beim Server 2019 mit den entsprechenden Microsoft Entwicklern mehrere Teeams-Meetings gehabt, bei denen unter anderem auch der Matt Olson höchstpersönlich mit dabei war und sobald ich irgendwie mit iPerf um die Ecke gekommen bin, hiess es seitens Microsoft, nein Alex, 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. 😔

Und genau das habe ich auch gemacht, damit ich mir bei einer erneuten Begegnung nicht schon wieder das gleiche Geheule anhören muss.

Nun muss ich jedoch feststellen, das der NTTTCP nicht wirklich das macht, was man diesem per Parameter vorgibt. 🤮🤮🤮

Gruss Alex
MysticFoxDE
MysticFoxDE 16.11.2024 um 17:51:21 Uhr
Goto Top
Moin @Starmanager,

Um den Amis etwas klar zu machen werden Bedienungsanleitungen mit Bildern ausgestattet.

ich habe denen betreffend der Probleme schon per Mail, Teams diverse Romane geschrieben, natürlich bebildert, habe auch schon diverse Power-Points, Visio's, Excel's und auch schon diverseste Videos erstellt, jedoch habe ich bisher nicht wirklich das Gefühl gehabt, dass auf der anderen Seite etwas angekommen ist. 😔

Mitunter das "geilste" was ich mal von denen zurückbekommen habe war der Spruch mit, "Alex, das ist alles viel zu kompliziert, beschreib das Problem bitte in max. 5 Sätzen". 🙃

Gruss Alex
150940
150940 16.11.2024 aktualisiert um 18:09:37 Uhr
Goto Top
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.
MysticFoxDE
MysticFoxDE 18.11.2024 um 21:10:48 Uhr
Goto Top
Moin @150940,

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.

https://techcommunity.microsoft.com/blog/networkingblog/three-reasons-wh ...
🙃

Diese angeblichen "Fehler" wären doch schon längst aufgefallen.

https://github.com/esnet/iperf/issues

iPerf hat auch Fehler, diese werden jedoch viel ernster genommen, als die von Microsoft bei ihrem NTTTCP. 😔

Muss ich mir den Source-Code von NTTTCP in einer ruhigen Stunde mal etwas reinziehen.

👍👍👍 oh ja, bitte, dazu fällt mir momentan absolut die Zeit.

Gruss Alex
MysticFoxDE
MysticFoxDE 22.11.2024 aktualisiert um 09:42:44 Uhr
Goto Top
Moin Zusammen,

mit ist soeben bei NTTTCP leider ein weiteres gravierendes Fehlverhalten aufgefallen.

Und zwar steht in der NTTTCP Help beim Parameter "-a" das Folgende ...

ntttcp help parameter a

..., sprich, per Default sollte NTTTCP eigentlich immer "-a 2" verwenden.

Was unter dem Strich bedeuten würde, dass man beim Ergebnis zwischen den folgenden Testbedingungen ...

# Sender
NTttcp.exe -s -m 1,22,192.168.10.2 -l 16K -v -t 60 -nic 192.168.10.1
# Receiver
NTttcp.exe -r -m 1,22,192.168.10.2 -v -t 60

... und diesen hier ...

# Sender
NTttcp.exe -s -m 1,22,192.168.10.2 -l 16K -v -t 60 -nic 192.168.10.1 -a 2
# Receiver
NTttcp.exe -r -m 1,22,192.168.10.2 -v -t 60 -a 2

... eigentlich keinen Unterschied sehen dürfte.

Aber ... wenn ich einen Test mit "-a 2" mache, dann bekomme ich das folgende Ergebnis zu sehen ...

ntttcp test with -a 2

... und wenn ich nun denselben Test nur ohne "-a 2" wiederhole, dann bekommen meine 🦊👀 das Folgende zu sehen ...

ntttcp test without -a 2

... sprich ... 😨😖😵‍💫🥴🤢🤮🙊 ... 🙈🙈🙈 ... oder so ähnlich. 😔

Was zur Hölle treiben diese Microsoftianer eigentlich den ganzen Tag? 😡

Gruss Alex
Starmanager
Starmanager 22.11.2024 um 12:20:39 Uhr
Goto Top
Hallo Alex,

die Microsoftler werden wohl mit ihrem Teams Schwierigkeiten bei der Zusammenarbeit haben...
MysticFoxDE
MysticFoxDE 22.11.2024 um 17:41:24 Uhr
Goto Top
Moin @Starmanager,

die Microsoftler werden wohl mit ihrem Teams Schwierigkeiten bei der Zusammenarbeit haben...

die haben meiner Meinung nach eher Probleme mit massiv schwindenden Kompetenzen und auch einer absolut falschen Ausrichtung/Führung, die wiederum direkt auch für das zuvor genannte Problem verantwortlich ist. 😔

Gruss Alex
MysticFoxDE
MysticFoxDE 23.11.2024 um 13:01:58 Uhr
Goto Top
Moin @150940,

Muss ich mir den Source-Code von NTTTCP in einer ruhigen Stunde mal etwas reinziehen.

ich habe mir jetzt doch den Quellcode von NTTTCP mal genauer angesehen.
Ist zwar C was ist nicht ganz so mag, aber die gerade mal ~5.500 Zeilen, sind ja sehr überschaubar. 😀
Schau dir mal genauer an, wie diese Microsoftianer die Anzahl der parallelen Threads bestimmt, von wegen per Default "-a 2". 😔

Ich mache zu diesem Thema nun einen eigenständigen Beitrag, das es diesen hier, nur noch unübersichtlicher macht.

Gruss Alex
150940
150940 23.11.2024 aktualisiert um 13:38:20 Uhr
Goto Top
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...
MysticFoxDE
MysticFoxDE 23.11.2024, aktualisiert am 24.11.2024 um 07:48:34 Uhr
Goto Top
Moin @150940,

Noch keine Zeit dazu gehabt. Aber Async Flag nur True wenn Parameter gesetzt ist, jaaa das riecht nach 🐟 von letztem Jahr.

ich habe mir den Code nun etwas genauer angesehen und der Parameter "-a" bewirkt eigentlich schon das war er sollte, sprich, per Worker/Thread parallel mehrere "TCP-Streams" zu öffnen und wenn man auf der Sender- und Receiver-Seite, per "-sb 0" respektive "-rb 0" die Winsock Pufferung deaktiviert, dann macht NTTTCP auch genau das was ich eigentlich wollte. 🙃

Sobald ich jedoch die Winsock-Pufferung mit aktiviere, und zwar egal ob mit "-sb -1", sprich OS gesteuert, oder auch z.B. mit "-sb 4K" oder anderen Werten selber versuche diese zu steuern, sehe ich im Wireshark nur noch sehr grausame Dinge. 😭

Vor allem wenn ich mir die TCP-Window-Size, bei Verwendung des "-sb" Parameter genauer ansehe, wird es mir ganz ganz 🤢, denn hier macht NTTTCP, nicht wirklich das was es sollte. 😫
Auf der Empfängerseite schein "-rb" wiederum richtig zu greifen.

Gruss Alex
MysticFoxDE
MysticFoxDE 24.11.2024 aktualisiert um 10:45:36 Uhr
Goto Top
Moin Zusammen,

ich bin heute bei einer Recherche über den folgenden Artikel gestolpert ...

https://learn.microsoft.com/de-de/azure/virtual-network/virtual-network- ...

... der mitunter diverse Windows Features, wie LSO, TCP-Fensterskalierung, und deren Auswirkung auf CPU und Durchsatz beschreibt.

Und wenn man diesen Text einfach so von oben nach unten durchliest, dann hört sich das Meiste davon auch schlüssig an ... was es auch ist, wenn man ständig und möglichst am Stück, riesige Datenberge von "New York nach San Francisco" oder "New York nach London" oder "New York nach Sydney" verschieben möchte ohne dabei auch ja zu viel CPU Leistung zu verbrauchen. 🙃

Was Microsoft hier aber nicht explizit erwähnt, ist die Tatsache, dass durch die erwähnten "TCP-Optimierungen", die per Default übrigens bei jedem Windows mittlerweile aktiv auf so gut wie jeden Datenverkehr angewendet werden, insbesondere die über ein LAN laufende Transaktionen (TCP Übertragungen die schnellstmöglich quittiert werden sollten), zum Teil sehr massiv ausgebremst werden und ich spreche hier nicht von 2-5%, sondern eher von einer Verlangsamung um Faktoren. 😔

Siehe auch ...

microsoft tcp window size & lso & rsc high latenzy 2

... und falls jetzt irgend ein Linux-Jünger, mit irgend einem spitzen Spruch kommen möchte ...

microsoft tcp window size & lso & rsc high latenzy 3

... wir sitzen diesbezüglich leider im selben bescheidenen Boot. 😔😭

Dann habe ich BING noch das Folgende gefragt ...

microsoft tcp window size & lso & rsc high latenzy 5

... dann noch etwas direkter ...

microsoft tcp window size & lso & rsc high latenzy 4

... und natürlich haben diese Änderungen nichts mit der Abdrängung Richtung Azure und Co. zu tun, sondern nur mit der Tatsache, dass die meisten Anwender fast nur noch hochlatente WAN Verbindungen aufbauen, sprich, Cloud-Dienste wie Azure nutzen möchten und daher vollkommen auf deren lokale Performance pfeifen. 🙃

Gruss Alex
MysticFoxDE
MysticFoxDE 24.11.2024, aktualisiert am 25.11.2024 um 08:00:52 Uhr
Goto Top
Moin Zusammen,

also ich weiss ja nicht wie es euch bei solchen Antworten geht ...
microsoft tcp window size & lso & rsc high latenzy 6
... ich habe momentan jedoch ein sehr starkes Bedürfnis, dieser BING AI mal eine ordentliche Backpfeife alla Archie ...

https://www.youtube.com/watch?v=ZTeXs99q_2g

... zu geben. 😡

Gruss Alex

P.S. da heute ja auch Sonntag ist ... es ging noch ein paar Runden weiter. 😁
microsoft tcp window size & lso & rsc high latenzy 7

microsoft tcp window size & lso & rsc high latenzy 8

Hmm, was hat nun eigentlich Geholfen, etwa die Archie Ohrfeige durch die andere AI oder doch die Androhung mit der Kastration der eigenen Reaktionsfähigkeit? 🤔🙃
MysticFoxDE
MysticFoxDE 24.11.2024 um 11:35:22 Uhr
Goto Top
Moin Zusammen,

und spätestens über diese Antwort ...

microsoft tcp window size & lso & rsc high latenzy 9

... sollte jeder für sich mal ganz in Ruhe nachdenken. 😔

Gruss Alex
MysticFoxDE
MysticFoxDE 25.11.2024 aktualisiert um 12:21:02 Uhr
Goto Top
Moin Zusammen,

folgend ein kleiner Zwischenstand.

Nach dem kleinen Desaster mit NTTTCP bin ich gerade dabei zu prüfen, ob ich nicht mit einem anderen Werkzeug von Microsoft und zwar ...

https://learn.microsoft.com/de-de/sysinternals/downloads/psping

... auch das Nachmessen kann, was ich eigentlich möchte und es sieht gar nicht so schlecht aus.

Denn wie ihr der Beschreibung von PsPing entnehmen könnt, kann man damit ebenfalls die Bandbreite als auch die Latenz bei bestimmten Belastungsmustern ermitteln.

Und der erste Blick mit Wireshark, bestätigt bisher auch, dass PsPing genau das macht was ich zuvor eingestellt habe . 😁

Ich habe aufgrund von Zeitmangel bisher noch keine vollständige Testserie mit PsPing machen können, die ersten Testmessungen sehen jedoch sehr brauchbar aus.

Testparameter Ps-Ping ...

# Client (Sender)
psping64 -4 -b -l 4k -n 60s -i 1 -w 0 192.168.40.2:5000

# Server (Receiver)
psping64 -4 -s 192.168.40.2:5000

... sprich, selbes wie auch zuvor bei NTTTCP, ein Worker mit einem oIO einer Blockgrösse von 4K über 60 Sekunden.

Die folgende Messung habe ich mit den beiden Testserver (WS25) zwischen deren X722er NIC's gemacht.

ws25 - psping - x722 - default

Im Schnitt erreichte PsPing bei dieser Messung zwischen den X722er einen Durchsatz von 12,07 MB/s mit einer durchschnittlichen Latenz von 0,32 ms.

Zu diesem Zeitpunkt waren die NIC's treibertechnisch komplett auf Default gestellt und der TCP-Stack des Windows war ebenfalls komplett auf Default.

Dann habe ich an den X722er lediglich LSO und die Interrupt Moderation deaktiviert und auch im TCP-Stack OS-Seitig RSC deaktiviert und schon sag das Ergebnis folgend aus, ...

ws25 - psping - x722 - no lso & im

... sprich, ein Durchschnittlicher Durchsatz von 25,93 MB/s bei einer durchschnittlichen Latenz von 0,17ms. 😔

Dabei steht RSC, zumindest treibertechnisch bei keiner Intel NIC beim Server 2025 zur Verfügung, zumindest nicht in den von mir aktuell verwendeten V29.3 Treiber.

ws25 - intel nics - no rsc

Anscheinend fruchtet des Support-Ticket, welches ich bezüglich RSC bei Intel zu Zeiten von Server 2019 mal aufgemacht habe und worauf Intel den RSC Support aus sämtlichen nachfolgenden Treibern dann herausgeschmissen hat, wohl immer noch. 🙃

Ich werde nun noch ein paar weitere Tests mit PsPing machen und wenn sich diese Ergebnisse auch positiv bestätigen, dann werde ich damit als erstes eine neue Default-Baseline für WS25 aber auch WS19 machen.
Kann aber ein paar Tage dauern, da Land unter.

Gruss Alex
ukulele-7
ukulele-7 27.11.2024 aktualisiert um 09:45:20 Uhr
Goto Top
Zitat von @MysticFoxDE:

P.S.
Man kann z.B. mit dem Ressorcenmonitor ...
ressourcenmonitor - latenz
... 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 face-smile

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.
MysticFoxDE
MysticFoxDE 27.11.2024 um 19:38:18 Uhr
Goto Top
Moin @ukulele-7,

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.

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.

Aber, wenn du auf dem entsprechenden Server bist, dann schau auch bitte gleich im Ressourcenmonitor nach, wie hoch die Datenträgerlatenz auf diesem ist ...

ressourcenmonitor - datentrÄger latenz

... wenn du hier schon sehr hohe Latenzen siehst, dann kommt dein Latenzproblem wahrscheinlich primär nicht vom Netzwerk, sondern eher vom Storage.

Alle unserer Kunden habe AllFlash SAN's, die > 99% der IO/s in unter einer Millisekunde abfrühstücken, die neueren sogar weit unter 0,1ms und auch CPU technisch sind die entsprechenden HV-Nodes fast nur mit hochgeachteten Prozessoren versehen, daher sind bei diesen Latenzzeiten im zweistelligen Bereich schon etwas sehr ungewöhnliches.
So bin ich diesem Problem ja auch auf die schliche gekommen, weil wir immer schnellere SAN's bei den Kunden hingestellt haben, die Anwender davon aber nicht wirklich viel gespürt haben.
Na ja, es bringt ja auch nicht wirklich etwas, einen IO storagetechnisch von 1ms auf 0,01ms zu verbessern, wenn, sobald dieser über das Netzwerk wandern, durch RSC, LSO & Co, bis zu 40ms oder gar mehr, draufgepackt werden. 😔😭

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.

👍👍👍, sehr gutes Vorgehen.
Denn am Ende des Tages muss es der User auch wirklich merken.

Rein subjektiv würde ich definitiv mit nein antworten. Ich sehe nirgendwo etwas wo ich ernsthaft sagen kann, es gäbe einen Unterschied.

RSC ist ja auch nur eine von vielen möglichen Handbremsen, die mittlerweile im Windows aber auch den Pinguinen per Default aktiv ist. 😔

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 face-smile

Unterschätze die Sache bitte nicht. Bei unseren Kunden würde ich bei diesen werten bereits schon Alarm schlagen, da dies auf ein Problem hindeuten würde. Aber wie oben geschrieben, man muss zuerst die Quelle dafür sauber herausfuchsen, denn sehr oft kommen die hohen Anwendungslatenzen auch vom Storage und oder auch der Anwendung selbst oder von irgendwelchen zu bissigen Schutzmasnahmen.

Latenzen von >20 habe ich nur bei zwei Anwendungen: Edge und Office. Edge ist irgendwo "klar"

Ja, das irgendwelche Webserver die rund um den Globus stehen nicht mit <= 1ms antworten, sollte man schon mitberücksichtigen.

bei Office ist das eher schockierend weil außer OneNote/Sharepoint alles lokal ist.

Mach mal das RSC auf dem Exchange aus, aber auch hier, schau auch bei diesem mit auf die Datenträgerlatenz und auch CPU Auslastung, denn wenn beides zu hoch, dann muss man zuerst hier ansetzen. 😉

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.

Eigentlich sollten so gut wie alle Microsoft-Online-Dienste mit unter 50ms erreichbar sein.

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.

Gruss Alex
ukulele-7
ukulele-7 28.11.2024 um 13:56:05 Uhr
Goto Top
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?

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 ...

ressourcenmonitor - datentrÄger latenz

... wenn du hier schon sehr hohe Latenzen siehst, dann kommt dein Latenzproblem wahrscheinlich primär nicht vom Netzwerk, sondern eher vom Storage.
Hm ja auch das werde ich mir in Ruhe anschauen. Leider habe ich kein AllFlash und das wird auch erstmal so bleiben ;-/
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. 😔
Hm okay du hattest das mal vor ein oder zwei Jahren in einem Thread gepostet und in Teilen für Server empfohlen. Leider habe ich den Link nicht mehr, war vermutlich in einem anderen Thread...
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 face-smile Ich komme gerne noch darauf zurück, dann aber nicht über Weihnachten face-smile
MysticFoxDE
MysticFoxDE 29.11.2024 aktualisiert um 07:58:27 Uhr
Goto Top
Moin @ukulele-7,

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?

durch das Ausschalten von RSC (Receive Side Scaling) am Empfänger, schaltest du lediglich die Verzögerung der ACK's, sprich, der Übertragungsquitierung aus. Wenn du an die senderseitigen Übertragungsverzögerer herangehen möchtest, dann musst du eher Dinge wie LSO und oder "Interupt Moderation" deaktivieren. Das Letztere greift/verzögert übrigens auch empfangsseitig.

Aber, auch ein falsch konfiguriertes RSS, was übrigens per Default immer der Fall ist, kann zu Verzögerungen führen und zwar sowohl sender- als auch empfangsseitig, weil RSC (Receive Side Scaling) entgegen der Benennung nicht nur empfangsseitig sonder auch senderseitig skaliert, sprich im Grunde auch "Send Side Scaling" macht. 🙃

Und ja, die Welt dieser Microsoftianer ist immer schwerrer nachzuvollziehen, sprich, wird immer undurchsichtiger, was glaube ich, seitens Microsoft auch so gewollt ist. 😔

Das teste ich mal mit Exchange und eventuell DATEV. Am Wochenende gibts vermutlich eh Updates.

Du hast glaube ich ja VMware als Unterbau, wie schnell sind denn die vSwitche der ESXi angebunden, >=10G oder mit 1G?

Hm ja auch das werde ich mir in Ruhe anschauen. Leider habe ich kein AllFlash und das wird auch erstmal so bleiben ;-/

Aber ohne All-Flash sind hohe Latenzen fast garantiert, da selbst bei einem SSD gecachtem System, der first IO meist von den HDD's abgekratz wird und der Cache erst ab den second IO greift. 😬

Hm okay du hattest das mal vor ein oder zwei Jahren in einem Thread gepostet und in Teilen für Server empfohlen. Leider habe ich den Link nicht mehr, war vermutlich in einem anderen Thread...

Ich habe zu dem Thema schon sehr viel gepostet und bei dem einen oder anderen habe ich mich manchmal auch etwas vertan, weil ich viele Dinge schlichtweg per "Try and Error" herausfinden muss, da diese nicht wirklich gut oder gar nicht dokumentiert sind. 😭
(Siehe meinen kommenden Beitrag ... kleiner Spoiler ... Thema RDMA)

Lust ja, Zeit vielleicht face-smile Ich komme gerne noch darauf zurück, dann aber nicht über Weihnachten face-smile

Angebot steht und wenn du es erst im neuen Jahr abruffen möchtest umso besser, da ich aktuell auch dank dieser Microsoftians, etwas Land unter bin. 😔

Gruss Alex
ukulele-7
ukulele-7 02.12.2024 um 16:31:08 Uhr
Goto Top
- VMware ESXi, 8.0.2
- Intel(R) Ethernet Controller X710 for 10GbE SFP+
- Switch HPE 5406 zl2
- NetApp E2824
- iSCSI

Ich muss gestehen, ich hab im dedizierten iSCSI nicht mal Jumbo Frames an. Da gab es damals bei der Einführung der SAN eine "Merkwürdigkeit" und ich hab es "erstmal" ohne laufen lassen...
MysticFoxDE
MysticFoxDE 09.12.2024 um 10:02:48 Uhr
Goto Top
Moin @ukulele-7,

- Intel(R) Ethernet Controller X710 for 10GbE SFP+
- Switch HPE 5406 zl2
- NetApp E2824
- iSCSI

ich fürchte ich sehe schon das Problem und zwar die NetApp und auch noch über iSCSI. 😬

Ähm, ich denke wenn du im vCenter mal auf die Latenzen von den Datenträgern/LUN's schaust, wirst du wahrscheinlich irgendwas im zwei oder gar dreistelligem ms bereich sehen.

Wenn ja, dann liegt performancetechnisch auch hier primär der Hund begraben.

Gruss Alex
ukulele-7
ukulele-7 09.12.2024 um 10:39:26 Uhr
Goto Top
Ja, das ist so.
exportiert
Das meine SAN keine Top Notch Performance liefert, ist mir durchaus bewusst face-smile Ich möchte halt nur vermeiden, das Windows es schlimmer macht, als es sein müsste. Die SAN hat bis Anfang 2026 Support, solange wird sie ihren Dienst tun. Gegen Ende wird es dann sicherlich erstmal eine Diskussion geben, ob wir nicht "lieber in die Cloud gehen" oder in ein Hosting. Aus meiner Sicht lieber nicht.
MysticFoxDE
MysticFoxDE 11.12.2024 aktualisiert um 08:03:44 Uhr
Goto Top
Moin @ukulele-7,

Ja, das ist so.
exportiert

das habe ich mir schon fast gedacht. 😔

Hier zum Vergleich die Latenzen eines AllFlash SAN's (Infortrend DS4000U) eines unserer Kunden, ...

ds4000u - latenz

..., das sind im Schnitt gerade mal ~ 0,2ms/IO bei über 130 VM's.

Gegen Ende wird es dann sicherlich erstmal eine Diskussion geben, ob wir nicht "lieber in die Cloud gehen" oder in ein Hosting. Aus meiner Sicht lieber nicht.

Mach vor der Entscheidung einfach einen Test mit einem guten AllFlash-SAN und dann auch unbedingt einen gegen die Cloud und wenn eurer GL die Anwendungsperformance auch wichtig ist, dann sollte die Entscheidung recht einfach/eindeutig ausfallen. 😉

Gruss Alex