Remote Desktop Services unter 2022 - Erfahrungen?

Office Lizensierung ist schon mal ein Graus: Nach meinem Stand sind die Microsoft 365 Business Premium Lizenzen nur für Windows 2019 als RD-SH frei gegeben, 2022 erfordert eine E3 oder E5 oder ein Office 2022 mit SA - und das sollte auch so bleiben. Microsoft legt hier möglichst viele Steine.

Allgemein habe ich mit 2022 in einer VM eher Probleme, als ob die Dinger einschlafen würden und der erste Klick erst nach mehreren Sekunden ausgeführt wird. Ich kann nicht ganz sagen woran das liegt. 2019 zeigt dieses Verhalten nicht in der selben Umgebung. Laufen tut die RD-SH Rolle auf beiden.

Lizenzen sind abwärts kompatibel, also zumindest mit einer 2022 Datacenter und 2022 RDS CALs kannst du auch erstmal 2019 RD-SH ausrollen und später einfach 2022er als RD-SH mit einbinden.

Nutze schon seit Monaten diverse 2022er per RDP - noch keinen Unterschied zu 2019 bemerkt. Mit Sicherheit nicht auffällig langsam.

Moin @TiTux,


meiner bisherigen Erfahrung nach, läuft RDS unter dem 2022er +- genau so gut oder auch gruselig, wie unter dem 2019er.

Und was die Ruckler angeht ... RSC deaktivieren und RDP von UDP auf TCP umstellen. 😉

Gruss Alex

Moin @TiTux,


ups, was vergessen. Wenn der RAM des TS von dem immer aggressiver werdendem Softwarecaching aufgefressen wurde, dann kann es bei den TS ab Server 2019 auch anfangen zu ruckeln.

Dem Murks kann man aber mit einer zeigesteuerten Aufgabe und RAMMap auch entgegenwirken.

Gruss Alex

Hi,
ich habe derzeit unerklärliche Hänger bei einem 2022 RDS. Ich bin schon kurz davor, hier eine Hilfsanfrage zu stellen. Aber vorher würde ich gerne das mit RSC machen. Was ist RSC und wie kann ich es deaktivieren?

Danke!

https://learn.microsoft.com/de-de/windows-server/networking/technologies ...

Moin Rainer,


wenn man Performance-Probleme, respektive Ruckler bei RDP nur über VPN hat, dann ist der Grund dafür meistens nicht der RDS-Host selbst, sondern eher die VPN- und oder Security-Gateway's dazwischen.


Kommt darauf an wo du es umstellst.
Wenn du am RDP Server hart einstellst, dass dieser nur über TCP erreichbar ist, dann gilt das natürlich für alle Clients.
Alternativ kann man aber auch Clientseitig beim Verbindungsaufbau mitgeben, dass nur diese Verbindung über TCP aufgebaut wird.

Ich bin aber bei RDP generell kein Freund von UDP, vor allem, wenn da auch noch Laufwerks- und Druckerfreigaben mit drüber laufen.


Wenn es überhaupt ein Feature gibt, welches absolut kein Mensch benötigt, dann ist das definitiv RSC.


Du musst lediglich RAMMap zyklisch als Administrator mit dem Zusatzparameter "-Et" ausführen.
Sorry für die kürze, bin gerade echt im Stress.
Später kann ich es eventuell etwas detailierter beschreiben.

Gruss Alex

Moin Rainer,


es mach eben nur BullShit, aber das steht in der Beschreibung so natürlich nicht geschrieben.

Der Originaltext dieser lautet:

"The Disable-NetAdapterRsc cmdlet disables receive segment coalescing (RSC) on a network adapter. If IPv4 or IPv6 are not specified, then both are disabled. RSC takes multiple packets that were received within the same interrupt period and combines the packets into a single large package to be processed by the network stack. This reduces the processing overhead for incoming packets and reduces the number of processor cycles that are used, leading to better scalability."

Was auf deutsch +- das folgende bedeutet ...

"Das Cmdlet Disable-NetAdapterRsc deaktiviert die Empfangssegmentkoaleszenz (RSC) auf einem Netzwerkadapter."
"Wenn IPv4 oder IPv6 nicht angegeben sind, sind beide deaktiviert."
(Ja ich weiss 😵‍💫, steht im englishen Originaltext aber genau so drin. 🙃)

Und nun komm das wesentliche ...

"RSC nimmt mehrere Pakete, die innerhalb derselben Unterbrechungsperiode empfangen wurden, und kombiniert die Pakete zu einem einzigen großen Paket, das vom Netzwerkstapel verarbeitet wird. Dies reduziert den Verarbeitungsaufwand für eingehende Pakete und reduziert die Anzahl der verwendeten Prozessorzyklen, was zu einer besseren Skalierbarkeit führt."

Was sich im ersten Augenblick ja auch ganz doll anhört.
Was da jedoch nicht dasteht ist das folgende.

Ja, ohne RSC wird ein Netzwerkpacket quasi sofort verschickt, was einen Interrupt auslöst und damit CPU Zeit kostet.
Und je mehr kleine Pakete verschickt werden umso mehr Interrupts und umso mehr CPU-Last u.s.w.
Daher hat sich überwiegend MS den Trick mit RSC ausgedacht, bei dem zu übermittelnden kleinen Daten-Pakete zunächst im Softwareteil des TCP-Stacks bis zu einer Gesamtgrösse von 64K aufgestockt werden und dann als einzelnes Datenpacket, mit nur einem Interrupt an die Hardware übermittelt werden.
Ja OK, hört sich immer noch positiv an, aber, das aufstocken der Pakete im Softwareteil des TCP-Stacks erzeugt eine nicht zu unterschätzende zusätzliche Verzögerung/Latenz und danach muss das 64K Packet von der Hardware wieder in kleine Häppchen aufgeteilt werden, weil man über das Ethernet, normalerweise nun mal nur ~1500 Bytes pro Packet verschicken kann und das wiederum erzeugt nochmals zusätzliche Latenz und mach die Datenübertragung dadurch extrem träge.

Gruss Alex

Genau genommen stimmt die Aussage so auch nicht ganz.
Den auch ohne RSC, wird die Übermittlung der Netzwerkpakete im Softwareteil des Windows TCP-Stacks, dank eines uralten und heutzutage absolut unnützen Features namens TCP-Delay, Alias "Nagle's Algorithm", per default um bis zu 200ms verzögert. 🤢🤮

Ich habe mir auch grade was zu RSC durch gelesen und muss sagen das ich damit noch nie in wissentlich Probleme hatte. Da auch alle Windows 10 Clients das so nutzen frage ich mich ob ein deaktivieren wirklich sinnvoll ist, also immer, oder eventuell nur manchmal oder gar nicht, solange man keine Probleme hat?

Danke für die Erklärung, werde ich mal testen

Moin Rainer,


ja, das ist korrekt und nicht nur Server, sondern auch Clients.

Wenn du eine Hyper-Pfau (Hyper-V) einsetzt, dann musst du RSC auch auf dessen vSwitch's deaktivieren.

Das geht mit dem folgende Befehl über alle vSwitche ganz einfach.

Denn Befehl kann man übrigens direkt im Produktivbetrieb abfeuern.

Auf den VM oder auch BareMetale Systemen, deaktiviere ich RSC immer folgend

Vorsicht, beim ausführen dieses Befehls. Durch diesen wird die NIC neu gestartet, wodurch alle bestehenden Verbindungen wiederum baden gehen. Sprich, am besten nach Betriebs-Feierabend ausführen.

Beste Grüsse aus BaWü

Alex

Moin @ukulele-7,


und was genau?


Na ja, manchmal fällt es eben nicht gleich auf, dass man mit einer angezogenen Handbremse rumfährt.
Ist mir dem Letzt übrigens auch wieder passiert. 😬🤪


Wenn dein Client eine Intel NIC hat und du darauf einen aktuellen Treiber installiert hast, dann kann dieser ganz sicher kein RSC mehr, weil Intel RSC mittlerweile wieder komplett beerdigt hat.

Beste Grüsse aus BaWü

Alex

Moin @support-m,


hat du die Probleme auch im LAN oder z.B. nur über VPN?

Gruss Alex

Gab es dieses feature schon seit Server 2012? Ist das der Grund dafür dass sich RDP auf Server 2012 so viel responsiver anfühlt als auf Windows 10/11 Clients (mit performanter Hardware) oder hat Microsoft die Clients noch zusätzlich künstlich verlangsamt?

Moin @Frank84,


Ja, siehe ...

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windo ...

Beim 2012er war jedoch quasi RSC V1 implementiert, was von vielen damaligen NIC's noch nicht unterstütz wurde.


auch ...


und das ist leider auch korrekt.

Hier was fürs das verlängerte Wochenende ...

https://community.spiceworks.com/topic/2225989-server-2019-network-perfo ...
https://community.spiceworks.com/topic/2343311-the-windows-horror-story- ...
https://community.spiceworks.com/topic/2344183-the-windows-horror-story- ...
https://community.spiceworks.com/topic/2458316-the-windows-horror-story- ...
https://community.spiceworks.com/topic/2468243-the-windows-horror-story- ...

Gruss Alex

Moin,

habe jetzt mal aus Prinzip nach dem Lesen des Beitrages RSC deaktiviert.
Werde ich jetzt auch mal bei unserem für die IT reservierten RDSH machen.
Mal schauen, ob die 6 Kollegen irgendetwas merken.

Zur eigentlichen Frage:
Wir sind seit Februar 2022 auf RDSH 2022 und haben bislang keine Probleme bzgl. Performance gehabt.
Unsere Auslastung ist aber auch sehr gering und die TS werden nur in seltenen Fällen genutzt.

VG

https://www.theictguy.co.uk/server-2019-hyper-v-slow-network-file-transf ...
https://kb.vmware.com/s/article/2129176
Mich irritiert halt das das wie eine Ursache für ein sehr spezifisches Problem wirkt und ich darüber noch nie in einem anderen Zusammenhang (z.B. Computerspiele aber okay, lese ich auch nicht viel zu ) gestolpert bin. Deiner Aussage entnehme ich das es ohne RSC eine grundsätzliche Performanceverbesserung gibt oder zumindest keine Verschlechterung.

Ich werde das auch mal testen, ich überlege nur noch wie. Derzeit habe ich nur diverse File- und Printserver auf Windows 2022 laufen, da wird das kaum bis gar nicht auffallen. Wenn ich aber DATEV und RD-SH umstelle dann müsste sich das ja bemerkbar machen. Die laufen allerdings noch auf Windows 2012 R2.

Eine GPO gibt's nicht zufällig dafür?

Moin Zusammen,

ich muss den folgenden Part leicht korrigieren, da ich die "Fliessrichtung" der Pakete in der Beschreibung falsch dargestellt habe. 😬



Und zwar werden die eingehenden Datenpakete natürlich nicht im Softwareteil des TCP-Stacks von Windows zu einem grossen Datenpaket "zusammengefasst", sondern in der Hardware. sprich der NIC selbst. Und die gibt dann das bis zu 64K grosse Packet, mit nur einem Interrupt an den Softwareteil des TCP-Stacks von Windows weiter.
Das Ergebnis ist unter dem Strich jedoch dasselbe. Durch das Zusammenfassen der Datenpakete entsteht eine zusätzliche Latenz und diese wiederum zieht je nach Anwendungsfall, zum Teil sehr gravierend die Performance nach unten.

Gruss Alex

Moin @ukulele-7,


die kennen ich, von diesen Artikeln gibt es duzende im Internet ...

https://community.progress.com/s/article/000052793
https://www.sonicwall.com/support/knowledge-base/gvc-degraded-internet-t ...

Und alle kotzen am Ende des Tages über RSC.
Ich habe bisher jedoch noch keinen einzigen Artikel gefunden, wo jemand nachgewiesen einen Vorteil dadurch hatte. 😔


https://www.speedguide.net/articles/gaming-tweaks-5812
https://www.sudden-strike-maps.de/phpBB2/viewtopic.php?t=18382


Ich habe durch das Abschalten von RSC bisher nur Verbesserungen gesehen.


Auch auf den 2012er solltest du nach dem deaktivieren von RSC eine Verbesserung spüren.
Voraussetzung ist jedoch, dass RSC auf diesen vorher betriebsbereit war.

Ob RSC überhaupt auf dem entsprechenden Adaptern läuft, kannst du mit dem folgenden Befehl herauswinde ...


Dieser spuckt auf meiner Workstation aktuell z.B. das folgende aus ...


Wie du siehst, unterstützen nur zwei NIC's RSC und nur bei einer davon und zwar der MARVEL NIC, ist es vollständig Betriebsbereit und kann somit auch dazwischenspucken.
Der WLAN Adapter könnte RSC theoretisch auch, aber bei diesem ist es schon deaktiviert.
😮 ... Ohh, was sehe ich da ... so wie es aussieht hat Intel wohl vergessen RSC auch bei den W-LAN Adaptern zu beerdigen. 😱 Das muss ich denen mit einem Neujahrsgruss, gleich mal Stecken. 🤪
Und die I219 und die beiden X540 unterstützen RSC bei mir überhaupt nicht und werden daher bei der Eingabe von "Get-NetAdapterRsc" auch nicht gelistet.


Direkt nicht, aber du kannst per GPO ja auch PowerShell ausführen. 😉

Beste Grüsse aus BaWü
Alex

Wenn ich das unter VMware für den gesamten ESXi einstelle, wie genau sieht das dann für das OS in der VM aus, wie ein Adapter der kein RSC unterstützt (also gar nicht gelistet wird)?

Moin @ukulele-7,


wie sich das bei VMware verhält weis ich nicht genau, bin mittlerweile eher auf den Hyper-Pfau spezialisiert.
Wenn du in einer Windows VM nach Eingabe von "Get-NetAdapterRsc" nichts siehts, dann bedeutet das schlichtweg, dass sich in dieser VM keine RSC fähige vNIC befindet.

So weit ich weis, steht RSC bei VMware erst ab einer bestimmten VM Version und nur in Verbindung mit einer VMXNET3 vNIC's zur Verfügung.

By the Way, beim ESXi/Linux/Unix heisst dieses Feature übrigens nicht RSC (Receive Side Coalescing), sondern LRO (Large Receive Offload).

Schau dir das hier mal genauer an ...
https://docs.vmware.com/de/VMware-vSphere/7.0/com.vmware.vsphere.network ...
Da steht genau beschrieben wie man LRO(RSC) beim ESXi konfigurieren/wegkonfigurieren kann.

Beste Grüsse aus BaWü
Alex

Ist bei VmWare wohl in weiser Voraussicht bei v4 und v6 im Default deaktiviert.
Siehe auch hier:
https://kb.vmware.com/s/article/1027511
Bei Debian Linux ebenso.

Moin Zusammen,

heureka, heute Morgen hatte ich im wahrsten Sinne eine Erleuchtung. 😀
Ich verstehe nun sehr genau, warum RSC/LRO so viele Schmerzen bereitet ... es ist jedoch nicht alleine für diese Verantwortlich.

Aber alles der Reihe nach.

Das was ich folgend in einem der oberen Posts fälschlicherweise als Funktionsweise von RSC/LRO beschrieben habe ...


ist eigentlich die Beschreibung für die Funktionsweise von LSO (Large Send Offload), dem quasi Gegenstück von RSC.

Und genau diese beiden offload Funktionen sorgen vor allem im Gemeinsamen Betrieb für ordentlich Ärger, weil deren jeweilige "Segmentzusammenführungen" überhaupt nicht aufeinander abgestimmt sind, sprich asynchron verlaufen. Und diese asynchrone Segmentzusammenführungen zwischen LSO auf der einen Seite (Sender) und RSC auf der anderen Seite (Empfänger) erzeugt nochmals eine ordentliche Latenz, wodurch dann am Ende die Bandbreite vollends in den Keller rauscht.

Sprich, LSO ist so gesehen nicht wirklich kompatibel zu RSC/LRO und ich finde im Internet auch nicht wirklich einen Beweis dafür, dass die Interoperabilität zwischen LSO und RSC/LRO jemals richtig geprüft wurde. 😔

Das erklärt nun auch, warum bei den hunderten Tests die ich in diesem Zusammenhang schon gemacht habe, immer eine Verbesserung, insbesondere bei der Übertragungslatenz sehen konnte, sobald ich entweder LSO und oder RSC/LRO und oder TCO (TCP Checksum Offloading) deaktiviert habe.
Ja TCO spielt hierbei auch einer Rolle, denn sowohl LSO als auch RSC/LRO setzt TCO voraus.
Sprich, wenn man TCO deaktiviert, dann deaktiviert man damit auch automatisch LSO und auch RSC/LRO.

So, jetzt muss ich das Ganze hirnlich selbst noch vollends sauber zu Ende verdauen und dann werde ich hoffentlich in der Lage sein, dieses doch sehr komplexe Thema mit einfachen Worten und vor allem ohne daraus wieder einen riesigen Roman zu machen, etwas besser beschreiben zu können.

Beste Grüsse aus BaWü
Alex

Vielleicht wäre das ein guter Wissensbeitrag, wir sind ja hier schon ganz weit weg vom eigentlichen Thema

In unseren Windows 2012 R2 und 2022 VMs auf ESXi mit VMXNET3 ist RSC jedenfalls derzeit aktiv, auch per default.

Moin Zusammen,
wenn man die ganzen Featurebeschreibungen, insbesondere von Microsoft, betreffend RSS, RSC, LSO & Co. KG durchliest, dann möchte man meinen, dass diese pauschal sehr nützlich sind.

Das stimmt in der Realität, jedoch meistens leider weder vorne noch hinten.

Folgend die Ergebnisse eines kleinen Tests den ich gerade gemacht habe.

Als Testplattform dienen zwei Powerwokstations, die jeweils mit einer Marvell 10G NIC bestückt sind.
Als SMB-Client dient Workstation-A, die mit einer i9-9820X CPU und 128GB RAM bestückt ist.
Als SMB-Server dient Workstation-B, in der ein i9-12900K und 64GB RAM drinstecken. Zudem habe ich in die Workstation-B noch eine Optane-SSD verbaut, damit auch garantiert ist, dass mir das „Storage“ bei diesem Test nicht auch noch dazwischen zickt.
Auf Workstation A ist Windows 11 Enterprise 22H2 und auf Workstation-B ein Windows 11 Pro for Workstations 22H2 installiert. Sprich, beide haben den aktuellsten MS-Kernel, der übrigens >99% dem vom Server 2022 entspricht.
Beide Workstations sind zudem BIOS seitig und auch OS seitig bereits schon ordentlich performanceoptimiert und auch SMB technisch laufen diese nicht mehr auf default.

Die Einstellungen der NIC’s und des TCP-Stacks sind bei den folgenden Tests, zumindest vorerst auf default.
Und genau um den pauschalen Nutzen dieser NIC-Einstellungen/Feautures geht es mir bei diesem Post ja auch.

Den ersten Test habe ich mit diskspd direkt auf der Workstation-B mit den folgenden Parametern gemacht.


Mit diesem Testpatern belaste ich die hinter „D:“ liegende Optane-SSD mit 4 parallelen Threads, von denen jeder sequentiell 4k grosse Blöcke von einer 20GB grossen Datei, zu 50% liest und zu 50% schreibt. Das entsprich einem Haufen kleiner Schreib-Lese-Transaktionen, die jeweils einzeln quittiert werden müssen.

Dieses Testpattern ist übrigens nicht auf Maximaldurchsatz ausgelegt, sondern erzeugt wie gesagt nur eine bestimmte Last.

Und da die oben angesprochenen Features, laut ihren Schöpfern ja pauschal nur Verbesserungen bringen, müsste das ja auch für mein überschaubares Testpatern zutreffen.

Nun aber zu dem ersten Ergebnis.

Wie ihr sehen könnt, liefert die Optane unter diesem Testpatern in der Workstation-B, ohne SMB, TCP & Co dazwischen, in Summe 860,70 MB/s, bei einer durchschnittlichen Latenz von 0,017ms.

Merkt euch hierbei bitte insbesondere die Latenzen, die sind im weiter Verlauf mitunter das Wichtigste. 😉
Die Maximallatenz beim Lesen lag bei diesem Test übrigens bei 3,452ms und beim Schreiben bei 3,382ms.

Kommen wir nun zu dem zweiten Test.

Diesen habe ich nun von der Worstation-A (172.16.230.1) mit den folgenden Parametern gegen die Workstation-B (172.16.230.2) gestartet.


Im Grunde ist das dieselbe Belastung wie vorher, nur das diese nun über das Netzwerk erzeugt wird, sprich, wir nun IP, TCP, SMB & Co noch dazwischen haben.

Und nun sieht das Ergebnis folgend aus.

Jup, über das Netzwerk ist nun von der ursprünglichen Performance nur noch ~1/10 übrig geblieben. 😭

Schaut euch nun mal genauer die Latenzen an, die Durchschnittlatenz ist nun bei 0,184ms, das ist 10 Mal schlechter als beim lokalen Test. Das bedeutet wiederum, dass durch SMB und TCP & Co KG, in diesem Fall eine zusätzliche Latenz von ~0,166ms erzeugt wird. Im Vergleich zu dem vorherigen lokalen Test, entspricht das einem Latenzoverhead von ~90%! 😱

Ja, OK, dass SMB und die Übertragung über das Netzwerk (TCP-IP) eine Zusatzlast erzeugt und das dadurch automatisch die Latenz nach oben steigt ist mir schon bewusst, aber doch nicht gleich so viel. Das was da per default bei Windows stellenweise geschieht ist einfach nur Horror. Vor allem wenn ich die Maximallatenzen anschaue, die beim Lesen auf bis zu 200,259 ms und beim Schreiben auf 167,63 ms klettern können. 🤢🤮

Aber ja, alles der Reihe nach, fangen wir mal an das Unkraut zu rupfen. 🤪

Als nächstes habe ich auf den Marvell NIC’s der beiden Workstations lediglich das RSC deaktiviert und habe danach denselben Test wie zuvor, mit dem folgenden Ergebnis laufen lassen.


Wie ihr sehen könnt, hats sich alleine durch das abschalten von RSC, die Latenz von 0,184ms auf 0,162ms, sprich, um 0,022ms verbessert. Und dadurch hat sich automatisch auch der Durchsatz von 84,89 MB/s auf 96,43 MB/s verbessert. 😁

Und auch die Maximallatenzen sind deutlich niedriger/besser geworden.

Dann rupfen wir mal weiter. Als nächstes habe ich LSO auf beiden Seiten, mit dem folgenden Ergebnis deaktiviert.


Ja, OK, mit einer um 0,004ms besseren Durchschnittlatenz sieht es im ersten Augenblick nicht danach aus, als ob LSO wirklich viel Overhead erzeugen würde, aber schaut euch mal die Werte der Maximallatenzen genauer an. 😉

So, als nächstes fliegt RSS raus.


Und schwupps ist ohne RSS die Durchschnittlatenz nochmals um 0,023ms besser geworden.
Die Maximallatenz beim Schreiben/Senden ist auch nochmals deutlich besser geworden.

Zwischenbillanz:
Alleine RSS, RSC und LSO zusammen, haben schon 0,049ms der zusätzlichen Durchschnittlatenz ausgemacht. 😔
So viel zum Thema, pauschale Leistungsverbesserungsversprechen durch den Hersteller/Erfinder. 🤮🤮🤮

Jetzt mache ich aber mal eine Pause und rupfe danach das Feature-Unkraut eventuell noch etwas weiter raus. 🤪

Beste Grüsse aus BaWü
Alex

Moin @ukulele-7,


ja, mache ich später wahrscheinlich auch noch.


Na ja, nicht so ganz, die meisten Schmerzen mit den oben angesprochenen Dingen hatte ich insbesondere bei Terminalservern.


Dann lass in deiner Umgebung von VM zu VM mal denselben diskspd Test laufen und schau was dabei herauskommt. 😉
Vergleichswerte sind in diesem Beitrag ja nun zu Genüge vorhanden.

Beste Grüsse aus BaWü
Alex

Ich schätze deine intensive Arbeit zum Thema sehr, vor allem weil mir selbst die Zeit fehlt . Eventuell lasse ich das meinen Co Admin machen und deinen neuesten Beiträge werde ich mir auch noch in Ruhe anschauen aber vermutlich erst in einer Woche.

Moin Zusammen,

folgend ein kleiner Zwischenstand.

Ich habe noch Flow Control rausgerupft, das hatte jedoch so gut wie keine Veränderung herbeigeführt.

Dann wollte ich als nächstes die DelayedACK’s anpassen und bin dabei über dieses Problem gestossen.
Hilfe, mein Windows 11 stuft sämtlichen Datenverehr als Internetdatenverehr ein
Sprich, wegen dieser weiteren Bevormundung seitens Microsoft, kann ich das Verhalten der DelayedACK’s und auch einiger andere performancerelevante Dinge, bei den aktuellen Windows Client Versionen, absolut nicht mehr anpassen. 🤮🤮🤮

@microsoft
Was soll das?
Wird Windows nun zu etwas so zwischen Chrom-OS und iOS, sprich, zwischen kann so gut wie nichts und absolute Bevormundung?

Beste Grüsse
Alex

Hi,
ja, die Hänger passieren auch im LAN. Es scheint ein"Anzeigefehler" zu sein, denn es friert im Grunde die Anzeige ein, die Eingaben werden aber weiter übertragen. Nach bs zu 30 Sekunden später werden die ganzen Eingaben dann "nachgeholt", also der Text wird plötzlich geschrieben, die Fenster werden plötzlich geöffnet (weil man die Programme unten in der Taskleiste geöffnet hat um zu schauen, ob der "Rest" noch geht...man kennt das ja).
Das Probelm tritt sowohl im LAN, als auch über VPN, also auch schon jedem beliebigen Client immer mal wieder auf (Von Windows 7 bis 11 war alles dabei) und das auch noch Userunabhängig.
Das Verrückteste bei der ganzen Sache ist, dass es seit Inbetriebnahme mehrere Monate problemlos funktioniert hat und seit etwa Oktober tritt das Verhalten auf. Ich habe auch schon sämtliche Windows Updates seitdem deinstalliert, ich bekomme es nicht gelöst.

Ich habe schon alles mögliche probiert. Ich hoffe nun eben, dass mit der Deaktivierung von RSC die Probleme verschwinden.

Danke übrigens für deine Benchmark Tests, sehr interessant. Ich freue mich auf den Wissensbeitrag

MfG

Moin Rainer,


ja, RSC solltest du IMMER deaktivieren, weil es in den meisten Fällen zwischen etwas und extremst ausbremsen tut.
Ferner solle man RSC auch niemals parallel mit Interrupt Moderation benutzen, weil diese beiden Features +- ähnliches tun und sich deswegen auch gerne gegenseitig beissen. Beides, sowohl Interrupt Moderation als auch RSC, hat meiner Erfahrung nach bei performancekritischen und vor allem latenzkritischen Abläufen, jedoch absolut nichts verloren.

Bei VMware musst du RSC ebenfalls bei einer VM, sowohl von innen als auch von aussen deaktivieren.
Siehe auch ....

https://kb.vmware.com/s/article/2129176
https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-networking/GUID-51 ...


Und RSS am besten auch, das bringt meiner bisherigen Erfragung nach, auf einem RDS-Sessionhost nicht wirklich einen Vorteil, zumindest nicht bei Hyper-V.

Beste Grüsse aus BaWü
Alex

Moin Rainer,


👍👍👍 exakt 😁

Gruss Alex

Moin Rainer,


hast du RSC bei deinen ESXi schon deaktiviert?
Wenn ja, was ist das Ergebnis?


Beste Grüsse aus BaWü
Alex

Hallo Leute,

Da habt ihr ein sehr spannendes Thema... ich habe auch gerade User Beschwerden am Tisch das unter den 2022er Servern die Performance schlecht ist.

Ich werde das mit dem RSC deaktivieren einmal testen.

Der Respekt geht raus @MysticFoxDE ... Wahnsinn was du hier für Infos raus haust. Die sind Gold wert. Danke

LG Jojo

Noch eine kleine Anekdote dazu....

Ich hatte vor 6 Monaten bei einem Windows Server 2019 (Dell / Hyper V / 10 Gbit) das Problem das mir eine Netzwerkkarte im Sekundentakt ausgefallen ist. Neustart vom Server hat es für ein paar Tage behoben.

Der Server war ganz neu und auch der Neustart sprach gegen einen Hardwaredefekt. Aber ich habe die Karte trotzem tauschen lassen => Hat nichts gebracht

Firmware Update Switch, Firmware Updates am Server => Hat nichts gebracht

Deaktivieren von VMQ als Verzweiflungsversuch => Funktioniert. Seit dem keine Probleme mehr