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/contentid/669379

Ausgedruckt am: 19.11.2024 um 01:11 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
catrell
catrell 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 @catrell,

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
catrell
catrell 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 @catrell,

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 @catrell,

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
catrell
catrell 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 @catrell,

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
catrell
catrell 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 @catrell,

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