[English]Administratoren von Windows Server 2019-Systemen beklagen sich häufiger über eine schlechte Netzwerkperformance. Blog-Leser Alexander verfolgt das Thema und hat mich auf eine mögliche Ursache hingewiesen, die man nur als Skandal bezeichnen kann.
Anzeige
Kleiner Rückblick auf das Netzwerk-Performance-Thema
Im Februar 2020 hatte ich hier im Blog den Beitrag Windows 10 / Server 2019: Langsames Netzwerk– bei Hyper-V-Gästen und Bar-Metal-Clients, in dem ich auf Grund eines Leserhinweises einige Hinweise zu Optimierungen der Performance im Netzwerkbetrieb gegeben habe. Dort meldete sich Blog-Leser Alexander Fuchs mit folgendem Kommentar (danke dafür):
Ich habe mittlerweile noch ein weiteres Problemkind gefunden, welches auf dem 2019er Server vermehrt zu Performanceproblemen führt, der Windows Defender.
Alexander liefert auch gleich eine Lösung mit, indem er vorschlägt, den Windows Defender über die PowerShell auf Windows Server 2019 zu deinstallieren. Ich hatte das im Blog-Beitrag Windows Server 2019 und Defender-Performance-Probleme näher ausgeführt.
Ursache vermutlich gefunden
Jetzt meldete sich Blog-Leser Alexander F. vorige Woche mit den Worten: Ich habe nun endlich herausgefunden, woran die Probleme mit der Netzwerkperformance beim Server 2019 (und älter) nun wirklich lagen. So etwas ist immer gut – aber schauen wir uns an, was Alexander herausgefunden hat. Er hat mich in seiner Mail auf den Spiceworks-Beitrag The real disaster behind the network performance disaster with Server 2019 vom 28. Juli 2020 hingewiesen. Dort diskutiert er das Problem mit der Community und liefert ausführlichere Erklärungen – allerdings in Englisch. Hier ein Auszug:
Hi Friends,
as promised now follows the reason for so much trouble and suffering that we have had the last few days, weeks and years with the network performance of the Microsoft operating systems.
This will come as a surprise to some of you, but Microsoft doesn't have much to do with most of the problems. OK, one thing yes, but I'll get to that later.
But let's start from the beginning. Our journey of knowledge begins in March 2007, at the latest with the birth of Windows Server 2003 SP2.
And so, NDIS 5.20 came into force with these two operating system. Now many are probably wondering what is NDIS and why is the old version 5.20 so important.
„NDIS" stands for „Network Driver Interface Specification"
And with Server 2003 SP2 and NDIS version 5.20, RSS has also found its way into the operating system.
Das Kürzel RSS steht hier für receive side scaling, und das Prinzip ist in diesem Beitrag beschrieben. Im Spiceworks-Beitrag geht der Autor auf NDIS und RSS ein und verlinkt auf weiterführende Artikel. Über die verschiedenen NDIS-Versionen wurden wohl verschiedene Parameter benutzt. Der Parameter *MaxNumRssCpus sollte niemals größer als 32 gesetzt werden. In NDIS 6.30 wurde die Unterstützung für RSSProfile hinzugefügt. Die Werte für die Parameter im RSSProfile für die diversen NDIS-Versionen lässt sich in diesem Microsoft-Dokument nachlesen.
Anzeige
Das bedeutet, dass die RSSProfile-Konfigurationsparameter von den NIC-Herstellern spätestens seit Windows 7 / Server 2008 R2 und NDIS 6.2 spätestens ab Oktober 2009 verwendet und im Treiber konfiguriert werden sollten. Dass scheint aber nach wie vor nicht der Fall zu sein. Die Werte lassen sich in der Registrierung ablegen und konfigurieren.
TCP Offload Engine in Windows seit etwa 3 Jahren deaktiviert
In diesem Post kommt man dann, mit Hilfe von Blog-Leser Karl der Ursache auf die Spur: Die TCP Offload Engine wurde aus den Netzwerkfunktionen entfernt, da 'Legacy Code'. Die Funktionalität wurde in die Stack TCP Engine übertragen. Hier der betreffende Textauszug:
on the topic did you spot this Alex?
TCP Offload EngineRemoving this legacy code. This functionality was previously transitioned to the . For more information, see Why Are We Deprecating Network Performance Features? Windows 1709
https://docs.microsoft.com/en-us/windows/deployment/planning/windows-10-removed-features
Die Erklärung findet sich in diesem Techcommunity-Beitrag aus 2018. Dort werden auch potentielle Nachteile genannt.
- If there is a flaw in the TCP implementation in the network card, for example a security issue, you are potentially looking at a firmware update on the network card, or worse, you may be stuck with it, depending on the card implementation and the vendor's support policy for the network card.
- Under heavy network loads, performance may actually drop, because you're limited to the resources on the network card, which may be a bottleneck relative to a fast operating system stack with fast, available processor cores.
- The cost for all TCP connection offloading is fixed; there's no way for the operating system to optimize specific use cases. The feature assumes that the fixed cost will be offset by the CPU savings, thus there will be an overall improvement in performance. However, improvements in processor performance combined with what real-life TCP workloads look like suggest that, in 2017, ~99% of real-life connections will send enough data for the performance arithmetic to work out.
- The NIC code wasn't necessarily written with TCP in mind; thus, not all TCP features are implemented. For example, the TCP performance enhancement known as Selective Acknowledgement ( RFC 2018 , from 1996 [!!]), can't be used with TCP Chimney.
Alexander hat dann weiter geforscht und seine Erkenntnisse auf administrator.de in diesem Beitrag kompakter zusammen gefasst.
- Die Funktionalität für TCP Offload Engine wurde mit Windows 1709 und Windows Server 2016 aus dem Betriebssystem entfernt.
- Die hardwareseitigen TCP Offload-Features der Netzwerkkarten sind damit überflüssig, da diese betriebssystemseitig (om TCP Stack) nicht mehr unterstützt/angesprochen werden.
Lange Rede kurzer Sinn: Wie es ausschaut, hat Microsoft im Betriebssystem was ausgebaut, was die Hersteller von Netzwerkkarten nicht mitbekommen haben. Und so kommt es zu den Performance-Problemen im Netzwerk von Windows Server 2019.
Anzeige
Heißt also ich sollte generell das Offload auf den Netzwerkkarten deaktivieren? Weil das würde ja dann auch Windows 10 betreffen
Zum Thema Windows Server und Schweinereien im Bezug auf Netzwerkkarten habe ich auch noch einen. Die oft auf Desktop Mainboards integrierten Intel Netzwerkkarten lassen sich nicht unter Windows Server installieren. Für eine Intel I219-V gibt es keinen Treiber den man unter Windows Server installieren kann, es gibt aber einen I219-LM, das ist wohl der gleiche Chip mit anderer PCI-ID. Das habe ich schon unter Windows Server 2012 R2 mit der Intel I217-V beobachtet. Im privaten Gebrauch installiere ich diese Desktopchips daher einfach mit dem Treiber ihres Server Pendants und habe damit noch nie Probleme gehabt. Selbst als Netzwerkkarte im Hyper-V Host und als Teil eines Teams mit mehreren VLANs darauf! Ich gehe daher davon aus, das hier einfach nur verhindert werden soll Server Software auf billiger Desktop Hardware zu nutzen. Ich frage mich nur wer die treibende Kraft dahinter ist.
danke MysticFoxDE, nach abschalten von dem ganzen Offload mist kopiere ich ~13000 Mini Files in 9 Minuten anstatt ~1Std
Nach über 1 Jahr den Fehler gefunden.
danke !!!!!!!!!!!!!!!!!!!!!!!!
Hi, wie wurden die Dateien kopiert? Ich habe hier seit einiger Zeit einen 2019 Server als Workstation im Einsatz.
Ich habe festgestellt das das Kopieren von einem großen Ordner mit dem Explorer eine Katastrophe ist. Ich mache das daher seit einiger Zeit per Robocopy Skript und das läuft so schnell wie man es erwarten würde. In meinem Fall ist der Ordner ca. 70GB groß und es sind 30000 Dateien drin. Unter Windows 8 oder Windows 2012 R2 Server hat das Kopieren dieses Ordners aber auch oft zu Müll geführt weil der Explorer sich zwischen drin verschluckt hat. Lustigerweise ein Windows 7 x64 hatte diese Probleme nie. Das nennt man dann wohl Fortschritt ;)
es ist halt einfach nur krank. wenn ich einen server installiere sollt der von sich aus schon die beste netzwerk performance bieten, spätestens dann wenn rollen oder features für netzwerkdienste installiert werden, sollt windows doch gleich das beste von sich aus setzen.
warum sollt der admin in teils abstrusen regkey herumwursteln nur damit das ding performance bringt. selbiges gilt auch für die treiber, gerade im netzwerkbereich.
Ich habe auch Probleme mit der Network Performance in einer VMWare Umgebung mit Server 2019 Sytemen. Insbesondere die Datenübertragung von Rechnern, die nicht in der Domain sind, auf einen Server (oder umgekehrt) ist absurd langsam.
Hat jemand hier ähnliche Erfahrungen gemacht? Bzw den Workaround hier getestet?
Das dürfte aber vorallem an der Authentifizierung und der Namensauflösung liegen. Meine Erfahrung ist seit Windows 2003 Server und Windows XP, arbeite mit FQDN und freue dich über ein einigermaßen normales Verhalten im Netzwerk. Ansonsten wurde bis vor kurzem sogar unter Windows 10 noch die "gute" alte Netbios over TCPIP Namensauflösung abgefragt!
Die Namensauflösung sollte keine Rolle spielen, ich habe praktisch alle Möglichkeiten durch: FQDN, IP, Servername ohne FQDN etc. Und hier jeweils auch verschiedene Übertragungsarten getestet. Das Ergebnis ist immer gleich ernüchternd.
Der einzige Unterschied, den ich feststellen konnte:
Werden Daten von einem redireteten lokalen Laufwerk ( also bspw. Platte C: auf einem Laptop) innerhalb der RDP-Session kopiert, friert die Session teilweise ein! Darauf kann ich mir nun gar keinen Reim machen.
Ufff das ist aber ein echt ekliger Fehler! Passiert das Einfrieren der Session nur über eine VPN-Verbindung oder auch lokal? Wenn es nur über eine VPN-Verbindung passiert hätte ich noch einen Tipp. Ansonsten wüsste ich nichtmal wo ich schauen sollte.
Definiere lokal. Letztendlich wird immer VPN genutzt, da die Server in einem Rechenzentrum gehostet werden.
Also ich habe jetzt mal mit zwei sehr primitiven Systemen rumgespielt. Beides Windows Server 2019 Standalone Systeme und Intel Gigabit Karten mit aktuellem Treiberstand. Egal ob ich sämtliche Offload Funktionalität ativiere oder deaktiviere da ändert sich nichts. Weder im Verhalten noch der Geschwindigkeit. Aber auch die CPU Auslastung bleibt gleich. Ich tippe die Intel Treiber machen halt alles richtig. Schade ich hätte mich über etwas mehr Sportlichkeit im Netzwerk durchaus gefreut :)
An alle die hier gerade wegen sowas den Windows Server verteufeln, gerade die Offload Funktionen machen auch unter Linux oder BSD durchaus Probleme. Auf meiner pfsense ist das Offloading auch deaktiviert. Ansonsten gibt es genügend andere Punkte um einen Windows Server zu verteufeln ;)
puuuuhhh…. Skandal….
bevor alle, die tatsächlich die oben beschriebenen Probleme nachvollziehen können, ebenfalls auf diesem Skandalzug aufspringen wollen, bitte ich zunächst zu prüfen ob ihre Hardware auch Windows Server 2019 zertifiziert ist (https://www.windowsservercatalog.com/results.aspx?&bCatID=1654&cpID=0&avc=0&ava=130&avt=0&avq=0&OR=1)
wir betreiben über 150 Hardware und VMs mit Windows Server 2019 … und die oben beschriebene Problematik ist bisher definitiv nicht bekannt.
@anon wegen intel gigabit netzwerkkarten und windows server treibern jenseits von 2008 R2 level. das habe ich schon seit jahren beobachtet und irgendwann erstmalig in server 2012 war es glaube ich unglaeubig versucht das intel nic inf treiberpaket zu nutzen aber dann am ende des tages die text inf datei geoeffnet und gesehen dass es keine sections fuer die reinen server systeme gab nur fuer die klassischen clients als win7, win8/8.1 und spaeter win10 usw.
und seit 2012 R2 oder wann sie es eingefuehrt hatten waren ja in der .cat datei (signatur datei) passend zu den recht simplen inf/sys/dll treiberpaketen dann auch die signatur zur inf/text datei mit enthalten, so dass man nicht mal selber die inf dateien modden erweitern editieren konnte, wie das frueher noch so einige leute taten z..b bei usb3 support fuer win7 integration usw faellt mir dazu jetzt spontan ein.
wie dem auch sei, seitdem kaufe ich eigentlich nur noch realtek basierte gigabit ethernet basierte mainboards fuer DIY server geschichten falls das sein muss. mein naechst groesseres problem ist dass man nichtmal brauchbare unterstuetzte grafikkartenchips auf boards erhaelt die kein horrendes geld kosten, oder nicht nur reines xeon zeug sind usw. diese AST basierten vga-only output chipsets gibts scheinbar wohl nur von irgendwelchen grossen namhaften OEMs wie Dell, Lenovo usw in deren server boards bzw komplettserien und pcie AST basierte karten gibts scheinbar wohl garnicht und amd mit AST oder sowas habe ich noch glaube ich garnicht gesehen. bin sowieso ueberhaupt AMD fan wenn schon sein muss.
realtek 2,5gigabit pcie chips habe ich noch garnicht probiert ob deren realtek treiberpakete server-kompatible inf/sys/dlls haben und somit nutzbar sind, waere auch mal interessant.
warum die das alle machen? weil intel gigant ist am markt, weil sie damit ihre "server" chips pushen aus fadenscheinigen gruenden, siehe ihre linux treiber funktionieren auch alle brav mit opensource jedweder chipsatz wofuer es linux treiber gibt funktioniert einfach unter allen moegliche OSS betriebssystem. gibt garkeinen grund warum es ueberhaupt generisch betrachtet sowas wie desktop-networking chipsets gaeben muesste. klar gibt es mehr features in "server"-netzwerkchips wie dma und io virtualisiert und wasweissich fuer spirenzchen, aber die OSS welt zeigt schoen dass man einfach in der software alles mit allem soweit technisch moeglich vereheiraten kann. nur microsoft und die grossen monpolisten wollen sich ihre monopole und erfundenen plattformen und gated communitys und teuer nicht wieder kaputtspielen lassen. waere ja noch schoener wenn einfach hardware mit freundlicher software einfach so laufen wuerde.
Was Realtek angeht bin ich leider gebranntes Kind. Ich habe ein recht weiträumiges Homelab, ;) Hardware die ich kaufe hat immer schon eine geplante Nachfolgenutzung. Heißt vorne kommt ein neues System rein und das älteste fliegt. Meine Firewall war auch schon Virtualisierungshost und Fileserver. Während Realtek Karten unter Windows eigentlich nie ein Problem sind, sieht es da beim Einsatz im Linuxserver oder der BSD-Firewall schon ganz anders aus. Die neuen 2,5Gbit Karten von Realtek müssen wohl auch unter Windows eine ziemliche Katastrophe sein. Das hat mich von der aktuellen Intel Generation auch schonmal komplett abgehalten, denn praktisch alle Boards haben den Realtek Chip verbaut. Aber mit den VGA-Karten spricht du etwas an das mir auch schon länger auf den Senkel geht. Geräte für meine DIY-Server währe sowas nicht schlecht. Klar bei Intel Desktopboards habe ich immer die iGPU mit an Board aber ein Wechsel auf AMD ist für mich so nicht sinnvoll machbar. Ja man könnte dann im Notfall eine VGA-Karte stecken aber darauf habe ich so keine Lust. Ich habe mich daher echt gefreut als es hieß das Intel jetzt eine Standalone Karte rausjagt. Tja ein paar Minuten später war klar die wird nur auf Intel Boards laufen und Ende des Traums :) Ich brauch halt eigentlich nur was das im Notfall ein Bild gibt aber nicht 30 Watt im Idle verbraucht und 400€ kostet.
für vga evtl sowas:
https://www.recabuk.com/manuals/minipcie/EMPV_1201_Datasheet_User_Guide.pdf
?
Sowas wäre nicht mal unspannend aber fast 100€ pro Stück, ist es mir dann auch nicht wert. Dann bleib ich halt erstmal bei Intel und hoffe weiter auf breite Verfügbarkeit von AMD APUs.