Windows 10/11: Grottige Netzwerktransfer-Leistung, hohe Windows 11 CPU-Last – Teil 1

Windows[English]Beim Datentransfer über ein Netzwerk gibt es bei Windows einen erstaunlichen, aber unschönen Effekt. Kopiert man Daten zwischen Maschinen mit Windows 10 und Windows 11 konsumiert Windows 11 das 2 bis 3 Fache an CPU-Leistung als Windows 10. Zudem hängt die Datentransferleistung einer TCP/IP-Verbindung von der Richtung der Datenübertragung ab. Oder in kurz: In Windows 11 gibt es beim Netzwerktransfer ein erhebliches Performance-Problem, wenn Daten empfangen werden. Ein Blog-Leser hat diverse Versuche unternommen und mir die Ergebnisse überlassen. In Teil 1 bereite ich das Thema und skizziere, was bei den Messungen heraus gekommen ist.


Anzeige

Entdeckung bei der TCP-Optimierung

Ich hatte ja kürzlich im Beitrag Optimierung von Microsofts TCP-Murks in Windows 10 und 11 über das Problem der "De-Optimierung" des TCP-Stacks durch Microsoft berichtet und die Möglichkeit, dies durch Anpassung der TCP-Parameter zu optimieren, aufgezeigt. Das kann die Netzwerkleistung durchaus spürbar steigern. Blog-Leser Alexander, aka MysticFoxDE, der für die Optimierung ein Script geschrieben hat, ist am Thema dran geblieben. Dabei ist er bei Tests auf einen weiteren dicken Klopper in Windows 11 beim Datentransfer über ein Netzwerk gestoßen. Er hat mir seine Erkenntnisse zum Wochenende zukommen lassen (danke dafür) und ich versuche diese in zwei Blog-Beiträgen zusammen zu fassen.

Testszenario mit 2 Workstations

Als Testszenario hatte Alexander zwei Hochleistungs-Workstations , eine mit Windows 11 22H2 Enterprise, und eine mit Windows 10 Pro 22H2 (beide auf aktuellem Patchstand) direkt mit einem Patchkabel verbunden. Beide Rechner waren mit einem 10 Gigabit-NIC ausgestattet. Auch die Treiberversionen für die Netzwerkkarte waren identisch.

Vor den Messungen des Netzwerkdurchsatzes zwischen den Workstation mittels PsPing64.exe hat er den TCP-Stack zurückgesetzt, sein TCP-Optimierungs-Script laufen gelassen, Windows neu gestartet und dann gemessen. Das sollte eventuell nicht optimierte TCP-Einstellungen als Ursache ausschließen. Dann ging Alexander dran, die Bandbreiten beim Datentransfer von einer Station zur anderen zu messen.Dabei wurden wechselweise Messungen beim Datentransfer von Windows 11 auf die Windows 10-Workstation und dann von Windows 10 gegen Windows 11 als Server durchgeführt.

Krasse Unterschiede in der Bandbreite

Nachfolgendes Bild zeigt die mittlere Bandbreite bei der Messung der Datentransferleistung vom Windows 11-System (fungiert als PsPing-Client) zur Workstation mit Windows 10 (fungiert als Ps-Ping-Server).

Data transfer Win 11 to Win 1o -> PsPing value
Datentransfer Win 11 zu Win 10 -> PsPing -Wert

Die Bandbreite wird im Mittel mit 1 GB/Sekunden angegeben. Dieser Wert ist laut Alexander in Ordnung und war zu erwarten. Dann hat er die Bandbreite in die andere Richtung gemessen, d.h. die Windows 10 Workstation (PsPing-Client) maß die Datentransferrate am Windows 11 System (PsPing-Server).

Data transfer Win 10 to Win 11 -> PsPing value
Datentransfer Win 10 zu Win 11 -> PsPing -Wert

Die Datentransferrate sank auf 89 MB/s. Alexander hat verschiedene Messungen der TCP-Leistung mit unterschiedlichen Parametern durchgeführt und kam nie über 600 MB/s. Er hat die betreffenden Ergebnisse in diesem Spiceworks-Community-Thread eingestellt. Während der Tests probierter er verschiedene Optimierungen der TCP-Einstellungen und schrieb mir zum finalen Ergebnis:


Anzeige

Vor allem die Geschwindigkeit beim Senden der Daten von der Workstation mit Windows 11 (PsPing-Client) zu der Workstation mit Windows 10 (Ps-Ping-Server) war mit 1GB/s und ganz ohne RSS (Receive Side Scaling) ja absolut OK.

In die andere Richtung, sprich wenn die Windows 10 Workstation (Ps-Ping-Server) Richtung der Windows 11 System (PsPing-Client) Daten geschickt hat, war die Performance zwar mit 500-600 MB/s gut, kam aber nicht an die [Leistung] in die andere Richtung heran.

Weitere Messergebnisse finden sich auf administrator.de in diesem Thread. Ergebnis ist, dass ein als Empfänger dienendes Windows 11-System die Transferleistung über das Netzwerk stark begrenzt, obwohl die TCP-Parameter optimiert wurden.

Unterschiedliche CPU-Last beim Transfer

In einer Ergänzung hat Alexander dann noch einige Worte zur CPU-Auslastung auf den beiden Workstations verloren. Die kurze Aussage:

Ferner habe ich herausgefunden, warum die Daten in die eine Richtung gut fliessen und in die andere nicht ganz so gut.

Und zwar wenn ich nun Daten mit einer Blockgrösse von 4K von der W11 Workstation Richtung der W10 Workstation schicke, dann benötigt die Windows 10 Workstation beim Empfang der Daten bei etwa 828,34 MB/s die gesamte Leistung des ersten Kerns der i7-8700K CPU, die mit 4300 MHz läuft.

Wenn ich nun Daten mit 4K von der Windows 10 Workstation Richtung der Windows 11 Workstation sende, dann verbrät Windows 11 beim Empfang mit ~413,19 MB/s, ebenfalls vollständig die Leistung des ersten Kerns der in ihr steckenden ! i9-9820X !! CPU, der wiederum fix mit 4,4 GHz läuft.

Sprich, das W11 verbrennt beim Empfang von Daten über das Netzwerk, mehr als doppelt so viel CPU-Leistung, als es ein W10 macht. Die haben definitiv ein riesiges Problem im Bereich des NIC Empfangspuffer Handlings. Das hat überhaupt nichts mehr mit Effizienz und oder Green-IT zu tun!

Es gab dann die Vermutung, dass da ein Implementierungsbug vorhanden ist und Alexander schrieb: "Microsoft hat doch erst dem Letzt einen Bug im Puffer-Handling der NIC,s beseitigt. Ich würde nun behaupten, dass die das entweder nicht gründlich gemacht haben oder neue eingebaut haben." Erwies sich aber nach weiteren Tests als Fehlschluss, da die Ursache in einer gänzlich anderen Ecke zu suchen ist. Diese Thema wird dann in Teil 2 behandelt.

Artikelreihe:
Optimierung von Microsofts TCP-Murks in Windows 10 und 11
Windows 10/11: Grottige Netzwerktransfer-Leistung, hohe Windows 11 CPU-Last  – Teil 1
Windows 11: Netzwerktransfer-Leistung und CPU-Last  optimieren – Teil 2


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Netzwerk, Windows, Windows 10 abgelegt und mit , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

35 Antworten zu Windows 10/11: Grottige Netzwerktransfer-Leistung, hohe Windows 11 CPU-Last – Teil 1

  1. FW sagt:

    Guten Morgen,

    danke für den Beitrag! Hier scheint ja mal wieder etwas gewaltig schiefzugehen. Zwischen Workstations ist es zwar relativ milde schlimm, aber wie sieht DAS im Zusammenspiel Client – Server aus? Wenn man da mit ähnlichen Problemen rechnen darf, dann steht uns Einiges bevor…

    • Günter Born sagt:

      Warte auf Teil 2 – da ist es der gleiche Mist, wenn es um Server 2022 (oder Hyper-V auf diesen Plattformen) geht. Alexander hat da gerade ein System optimiert.

    • Andy sagt:

      Also subjektiv würde ich sagen, dass die Netzwerkperformance in Windows auch in Zusammenspiel von und mit Servern in den letzten Monaten massiv gelitten hat.
      Ich habe hier meine eigenen kleinen Beobachtungen, die mir da bisher Rätsel aufgeben. Teils massive Geschwindigkeitseinbrüche bei (good known) Standardübertragungen. Und zwar nur bei Windows.
      Ich freu mich auf Teil 2.

  2. Henry Barson sagt:

    DCH-Treiber ersetzen! Die machen ohnehin mehr Probleme als ihren Dienst, zumindest bei Netzwerkkarten. Nicht zuletzt fehlt ihnen auch das NDIS-Interface, das so mancher VPN-Client auf Paketfilterbasis nach wie vor benötigt. Danach ging auf den Clients auch bspw. die SMB-Leistung wieder hoch.

  3. 1ST1 sagt:

    Wichtig wäre auch, mit PCs zu messen, die ohne "Optimierungsscript" laufen. Vielleicht sind die durch das Script gesetzten Parameter doch nicht so gut.

    Ich kopiere öfters zwischen Win 10 und 11 hin und her, mal über 1Gbit, mal über WLAN, und dabei spielt die Richtung des Transfers keine Rolle, es ist immer etwa gleich schnell bzw. lahm.

    Außerdem sollte man nicht nur mit psping messen, sondern auch nochmal mit iperf gegenchecken.

    • Günter Born sagt:

      Warte schlicht Teil 2 ab – deine Hinweise sind im Kontext der obigen Problematik gegenstandslos. Alexander hat mit iperf gemessen und das gleiche Bild bekommen. Zitat:

      ich kann dasselbe Problem mit der doppelt so hohen CPU Last beim eingehenden Datenverkehr auch mit iperf3 1:1 nachstellen.

      Ich muss jetzt zum Sport – ich versuche Teil 2 noch heute online zu stellen – war gestern einfach zu kaputt, um da das alles fertig zu stellen (der obige Beitrag ist heute um 4:00 Uhr fertig geworden und online gegangen). An dieser Stelle ein großes Lob an Alexander, er hat sich wirklich viel Mühe gemacht mit den Messungen – und auch Microsoftler in die Diskussion eingebunden. Das hängt also nicht im "luftleeren" Raum.

    • Tom Bongers sagt:

      Das ist das erste, was ich mir beim lesen des Artikel auch gedacht habe.

      Nicht falsch verstehen, ich möchte auf keinen Fall den Inhalt des Artikels anzweifeln. Aber wenn ich gleich am Anfang etwas von einem Optimierungsscript lese, ohne zu erfahren was das Script konkret macht, werde ich erst mal stutzig.

      Optimierung kann auch mal nach hinten losgehen, weshalb zumindest eine Vergleichsmessung auf einem jungfreulichen System ohne "Optimierung" interessant gewesen wäre.

      • Tom Bongers sagt:

        Ich habe mir den Artikel auf administrator.de jetzt mal durchgelesen. Dort sieht man auch die Details zu dem Optimierungssscript.

        In den Kommentaren sieht man auch, dass das Script durchaus einen messbaren Unterschied erzeugt, man sieht aber auch, dass bei einigen das Script bei Onlinespielen dazu führt, dass das Spiel für 5-6 Sekunden einfriert.

        Und man sieht, dass sich das Script z.B. bei Realtek Netzwerkkarten anders verhält als bei Intel Netzwerkkarten.

        Fazit für mich wäre, dass es durchaus Optimierungspotential gibt, das Optimierungsscript aber eben auch für Probleme sorgen kann und ich es deshalb vor allem in Produktivumgebungen nicht einsetzen würde.

        Es ist vermutlich wie immer, Microsoft muss zigtausende, unterschiedliche Konfigurationen berücksichtigen und für Kompatibilität sorgen. Das da dann oftmals ein kleinster gemeinsamer Nenner rauskommt, der durchaus Optimierungspotential hat, dafür ist dieser Artikel ein gutes Beispiel.

      • Günter Born sagt:

        Das Script ist im ersten Artikel erwähnt und verlinkt. Das Optimierungsscript wurde für die finalen Tests herangezogen, weil im Feld grottige Transferraten aufgefallen waren. Ziel des Scripts ist es, die TCP-Einstellungen durch Deaktivieren einiger Funktionen (z.B. RSS) für den Netzwerktransfer zu optimieren.

        Zweitens: Alexander hat da – meinem Eindruck nach – gut eine Woche getestet und analysiert. Als erstes waren wohl Messungen auf einer jungfräulichen Maschine dran. Dann kam das Optimierungsscript, um da TCP-Einstellungsprobleme auszuschließen. Ich habe mir das obige Excerpt aus einem Schwung E-Mails und zig Posts in der Spiceworks-Community sowie auf administrator.de herausgezogen. War schon eine Challenge – und ich wollte nicht die zig Messungen, die Alexander durchgeführt und in den Foren gepostet hat, hier bringen. Nach vielen Tagen, Diskussionen mit Microsoftlern und der Community hat sich dann ja eine Ursache heraus kristallisiert, die auf einem gänzlich anderen Feld liegt.

        Was etwas stört – bitte nicht falsch verstehen, Diskussion ist normalerweise gut – bei dem gesamten Thema TCP-Optimierung oder auch hier geht es mir viel zu schnell auf Nebenkriegsschauplätze, wo am Kern vorbei diskutiert wird. Ich kenne jetzt ja das Gesamtbild – wenn Teil 2 online ist, kann jeder den Test fahren und entscheiden, ob es Sinn macht oder nicht. Alles andere sehr ich als "ermüdend und wenig zielführend" für den Leser – war ja im ersten Artikel zur TCP-Optimierung, den ich am Beitragsende verlinkt habe, ganz extrem der Fall.

        • Tom Bongers sagt:

          Sorry, wusste nicht, dass nicht alle Diskussionen erwünscht sind.

          Ich wollte nur anmerken, dass das Script mit Vorsicht zu genießen ist, weil es verschiedentlich eben zu Problemen führt, wie in dem von dir verlinkten Beitrag zu lesen ist. Dass es Optimierungspotential und vielleicht sogar Bugs in Windows 11 gibt, wollte ich nicht ausschließen.

          Wenn diese Hinweise unerwünscht sind, weil Nebenkriegsschauplatz, bitte ich dies zu entschuldigen.

  4. Chris sagt:

    Da werden Maßeinheiten aber ganz schon durcheinander gewirbelt.

    In einem 1 GB Netzwerk sind rechnerisch maximal 125 MB/s drin, in der Praxis weniger. Die im Artikel angegeben 500-600 MB/s pro Sekunden können also gar nicht erreicht werden, dafür benötigt man ein 10GB Netzwerk und da ist der limitierende Faktor dann die Festplatte sofern man nicht in beiden PCs eine M.2 NVMe SSD drin hat.

    Wahrscheinlich sind weiterführend nicht 500-600 MB/s gemeint sondern Mbit!

    Gruß

    • M.D. sagt:

      In beiden WS steckt ein 10 GBit NIC. Also sind 1 GBytes pro Sekunde durchaus möglich. Und ist der RAM ausreichend groß, kann das System auch mehrere GBytes puffern ohne auf eine HDD/SSD zu schreiben. Von daher ist alles ok.

      • Chris sagt:

        Ah ok mein Fehler,

        hab das 10 GB Netzwerk übersehen, verwirrend ist der erste Test oben bei dem mit 89,07 MB/s nur die Leitung eines 1GB Netzwerkes erreicht wurde.

        Gruß

    • HessischerBub sagt:

      Mit dem Messprogramm wird man kein Dateitransfer von und zu Festplatten messen. Ich nutze netio, ist aber schon sehr alt.

      Muss mir die nächsten Tage mal psping ansehen, vielleicht wird das mein neues Testprogramm.

      Und dann gibt es ja noch das Problem mit der grottigen Performance über SMB bei Windows 11. Um die 30 MB/s sind grottig. Mit xcopy/ropycopy ohne Buffer wird es dann viel viel schneller.

      • MOM20xx sagt:

        tja die Probleme gibts doch mehr oder weniger in jeder Windows Version. Und auch hier wäre der Hersteller in die Pflicht zu nehmen und sollte Defaults liefern, die brauchbar sind. Aber vermutlich alles ob der abwärtskompatibilität gelassen wie es ist und man lebt in Redmond noch immer in 10Mbit/s half duplex LAN zeiten.

    • Günter Born sagt:

      Die MB/s sind genau das, was PSPing64.exe in obigen Screenshots als Maßeinheit auswirft.

  5. 1ST1 sagt:

    Mit iPerf hat man noch einen großen Vorteil. Man kann Win 10 und 11 auch miteinander vergleichen, in dem man eine "neutrale" Linux-Kiste als Gegenstelle mit in den Test rein nimmt. Damit müsste abschätzbar sein, ob jetzt nun Win 10 oder 11 das Problem ist.

    Und bitte mit und ohne Optimierungsscript.

  6. Paul sagt:

    Es gab früher oft Unterschiede ob B die Daten von A "holt" oder A die Daten zu B "schiebt" und wer "schiebt", der Server oder der Client.
    Iirc war es u. U. ungünstig die Daten zu "schieben".
    Vielleicht zu beachten ist auch das mit 10Gbps die Pakete so schnell kommen, daß moderne CPUs endlich wieder etwas mehr ausgelastet werden…
    Besten Dank für das Testen.

    • oli sagt:

      Oder das Optimierungsscript schiebt Lasten, die die Netzwerkkarte abdecken könnte wieder Richtung CPU. Ich hoffe mal, der Tester hat auch die CPU-Lasten unoptimiert gecheckt. Für mich klingt das irgendwie nach Defender bzw. zugehörige Mitigation-Tools (ehemals EMET) oder den neuen tollen "Security-Features" ala TPM, HVCI, VBS. Aber mal gucken, was Teil 2 bringt…

  7. Andy sagt:

    Interessant wäre der Versuch mit einem Windows7-System, ich glaube, daß bei Win10 schon sehr viel versaut wurde. Ich arbeite viel mit Videoschnitt über NAS und habe bei Win7 deutlich schnellere Bearbeitung als unter Win10

  8. Paul sagt:

    Was misst psping überhaupt?
    Setzt es einen TCP-Stream auf oder, wie "ping" vermuten lässt, sendet es einzelne Pakete und misst diese aus?

    Mich wundert das nirgends ein TCP dump zu sehen ist.
    Es wäre vielleicht interessant zu sehen, ob es resends gibt(gibt es auch im LAN), ob der Empfänger die Daten nicht los wird und das Fenster immer kleiner wird etc.

    • Günter Born sagt:

      Paul, Du bist wieder auf einem Nebenkriegsschauplatz unterwegs (zur Frage kann ich die Tage noch einen Artikel schreiben, obwohl in keine TCP-Dumps habe). Aber Teil 2 mit der Auflösung, wo es hakt, ist ja jetzt online – lies einfach mal, was ich da an Erkenntnissen von Alexander zusammen geschrieben habe. Vielleicht gehen einigen Leuten ja (endlich) die Augen auf – wenn nicht, ist es nicht mein Problem.

      • Jeremy sagt:

        >Nebenkriegsschauplatz
        >

        Wird das jetzt zum Totschlagargument? Ist ja fast so schlimm wie ein Trollvorwurf. Wenn man nicht über ein so weites Feld wie den ganzen Netzwerkstack sprechen darf, weil es nicht mehr erwünscht ist wird das recht albern.

        Wenn ich diese Rhetorik jetzt öfters lesen muss bin ich weg. Die Kommentare sind eigentlich der Grund, warum ich gerne hier bin. Da lernt man oft noch etwas dazu was außerhalb des Scopes des Artikels liegt.

        Dann kann man auch hier gleich alles schließen und "Sinnvolle Ergänzungen" wie auf Kuketz benutzen, die erst vom Admin freigeschaltet werden, wenn sie ihm gerecht sind.

        Soll kein Angriff sein. Aber ignorieren eines Beitrags ist manchmal besser als möglicherweise sinnvolle Diskussion schon im Keim zu ersticken. Ich hoffe das war jetzt konstruktiv erklärt ;)

        • Micha sagt:

          Das läuft schon länger so. Kritische Hinterfragungen werden einfach nicht geduldet. Heißt gelöscht oder die Diskussion mit fadenscheinigen Argumenten direkt beendet.

        • Günter Born sagt:

          Ich halte niemanden auf, der gehen will. Aber es ist auffällig, dass einige Leute sich schlicht auf diesen Nebenkriegsschauplätzen verlustieren.

          Beispiel 1: Ich blogge über DSGVO-Konformität von Microsoft 365 – und die Diskussionen mäandern um die Frage, wie alternativlos Office 365 im Grunde ist. Das mag zwar befriedigen, ist im Kontext eines Blog-Beitrags, der sich um DSGVO-Konformität dreht schlicht albern. Und wenn dann noch eine bestimmte Person, die ich mehrfach sperren musste, kommt und seine Worthülsen a la "Office 365 ist konkurrenzlos" in die Kommentare rein kippt, wo ich genau weiß, dass nichts mehr an Substanz kommt, dann sind das Troll-Kommentare, die ich schlicht im Hinblick auf die Kommentar-Hygiene künftig lösche.
          Beispiel 2: Ich schreibe hier "die Auflösung folgt in Teil 2" – und trotzdem fühlen sich einige Leute bemüßigt, da wild zu spekulieren, statt 2 – 3 Stunden abzuwarten.
          Beispiel 3: Der Kommentar von Paul, auf den ich geantwortet habe. Ich wollte Paul nicht angreifen und in anderem Kontext wäre sein Einwurf bzw. die Nachfrage berechtigt gewesen. Aber mal kurz festgehalten: Die Leute stellen im Feld fest, "da hakt es beim Netzwerkdurchsatz, das ist real". Es misst jemand mit PsPing64.exe und findet sein Bauchgefühl bestätigt. Und es gibt eine erhöhte CPU-Last beim Transfer – speziell in Richtung Windows 11. Im Lichte von Teil 2 wird aufgedeckt, dass es am Exploit-Schutz liegt. Und nun kommt Paul und stellt die Frage, was "PsPing64.exe misst". Wenn ich Pech habe – und das wäre nicht das erste Mal, bauen sich dann zig Folgeantworten auf einen solchen Kommentar auf, die nichts zum eigentlichen Thema beitragen.

          Ich empfinde es als wenig zielführend, zumindest, wenn ich es aus Sicht eines Lesers betrachte, der sich zu einem Thema über den Beitrag informiert, dann noch kurz die Kommentare überfliegen will und dann sich durch zig Bekundungen abseits des Themas quälen muss. An manchen Stellen finde ich das dann persönlich auch nur noch als nervend. Daher kommt gelegentlich der Einwand von mir, dass die Kommentatoren sich – im Hinblick auf die Mitleser – vielleicht etwas fokussieren sollten.

          Paul wollte ich damit "keinen vor den Latz knallen", sondern eine Diskussion einfangen (bevor diese ausufert), die mit meinem Wissen auf den berühmten "Nebenkriegsschauplatz" führt, aber niemanden weiter bringt. War nicht "auf die Füße treten" gemeint – aber seit ca. 2 Jahren komme ich ohne Kommentarmoderation leider nicht mehr aus – die goldenden Zeiten davor, wo ich so gut wie nie einen Kommentar bemängeln musste, sind wohl vorbei.

          Schade – aber in diesem Kontext nehme ich mir auch künftig die Freiheit, da schon mal ermahnend dazwischen zu gehen. Die andere Option wäre a) die Kommentierung komplett zu sperren (macht wenig Sinn, da viele Beiträge ja von der Leserschaft und deren Reflektionen leben), oder b) schlicht das Bloggen hier einzustellen. Was ich aber definitiv nicht machen werde: Viel Zeit und Herzblut in den Blog hier reinzustecken, und den Kommentarbereich dann – wie bei einigen Foren von IT-Medien – verhunzen zu lassen. Den richtigen Weg zu finden, wird schwierig – ich werde anecken – aber das geht nicht anders.

          Daher nochmals der Apell an den Good Will der Leserschaft. Es liegt an euch, wie hilfreich der Kommentarbereich für einen Leser, der vorbei kommt, ist – und ob ich da Nonchalance walten lassen kann, weil es diszipliniert läuft – oder irgendwann mal wieder zwischen allen Stühlen sitzend rigoros Kommentare löschen muss, weil sich die Leute unter der Gürtellinie beharken.

          PS: Ich habe mal wieder einen Kommentar von Micha freigeschaltet – was er hier als "unterdrücken kritischer Meinungen" zu verorten glaubt, ist für mich am Ende des Tages schlicht die schlimmsten Auswüchse verhindern. Ist ja nicht Einzelfall, oft gibt es eine Vorgeschichte. Ich sage immer "wenn jemand den Blog so schlimm findet, warum nicht einfach weg bleiben" – aber es juckt die Leute offenbar und treibt zum Zwang, einen Kommentar abgeben zu müssen (egal wie sinnfrei), den ich dann über diverse Filter in Moderation und abschließend, nach Begutachtung, in den digitalen Absys schieben muss. Und um keinen Zweifel aufkommen zu lassen – ich würde Kommentare problemlos freischalten, auch wenn ich persönlich angegangen werde, wenn es Substanz hat – da bin ich schlicht schmerzfrei. Aber Kommentare um des Verunglimpfens will (z.B. so was wie "Du Blogger Arschloch"), oder im Kontext sinnfrei, werden halt direkt gelöscht. Das ist dann die andere Seite des Schreibtischs.

          • Jeremy sagt:

            >a la "Office 365 ist konkurrenzlos"

            Ich finde jede Abosoftware ist Müll und nutze die 2019/2021 offline.

            >trotzdem fühlen sich einige Leute bemüßigt, da wild zu spekulieren, statt 2 – 3 Stunden abzuwarten

            Ist halt von Nachteil wenn man Artikelserien fährt. Medien leben uns das Spekulieren halt vor. Wer hat NS2 gesprengt? Aber das soll hier nicht hin. das wäre mal ein echter "Nebenkriegsschauplatz".

            >Es misst jemand mit PsPing64.exe und findet sein Bauchgefühl bestätigt.

            Die Frage ist ob ein synthetisches Benchmarktool aussagekraft hat. Hat auch nur 1x mal jemand hier 50GB über SMBv3 mit verschlüsselung durch das Netz auf ein NAS gejagt vor und nach der Optimierung? Ist der vorteil Bi-Direktional?

            Ich liebe realistische Metriken. Habe keine Meinung zu dem Tool, aber man arbeitet sich an Alex derzeit ab, da er teils recht hat, aber teils auch manche IT-Konzepte falsch darstellt. Das ignoriere ich bewusst. Da ich ja sagte einfach ignorieren ist sehr elegant. Ich beteilige mich einfach nicht daran.

            Außerdem bin ich Mnimalist. Warum ist es sooo unglaublich schwer zu sagen welche Fixes im Script sind und wie groß der Impact (Wirkung) von welchem Fix ist? Im idealfall würde ich nur 1-2 fixes wählen. Wenn der zweitbeste Fix in mein Use-Case-Szenario besser passt als der beste Fix würde ich sogar abstriche machen.

            Hoffe es ist nachvollziehbar:
            1) reale Benchmarks (SMB)
            2) impact und fixes einzeln aufschlüsseln

            Ob ich web bin oder nicht fällt mir schwer zu entscheiden. Manchmal filter ich auch einfach nur die ganze Kommentarsektion weg, damit ich es nicht mehr lesen muss. Das Klima hier ist geschädigt. Jeder ist schuld. Auch ich mit meinem Missmut das es hier unbequem wird.

            Bleib gesund Günni, dein anderer Kommentar war beunruhigend. Ja die Halswirbel :(

        • Alexander Fuchs sagt:

          Moin Jeremy,
          > "Die Frage ist ob ein synthetisches Benchmarktool aussagekraft hat. Hat auch nur 1x mal jemand hier 50GB über SMBv3 mit verschlüsselung durch das Netz auf ein NAS gejagt vor und nach der Optimierung? Ist der vorteil Bi-Direktional?"

          zum Thema SMBv3 …
          https://administrator.de/forum/remote-desktop-services-unter-2022-erfahrungen-5210303056.html#comment-5254369183
          😉

          Und ja, die Optimierungen wirken sich beidseitig aus.

          Gruss Alex

    • Alexander Fuchs sagt:

      Moin Paul,

      > „Was misst psping überhaupt? Setzt es einen TCP-Stream auf oder, wie "ping" vermuten lässt, sendet es einzelne Pakete und misst diese aus?"

      Es kann so gesehen beides.
      Wenn du mit -b testest, dann erzeugt PsPing einen Stream und mit -i kannst du quasi noch die Parallelität bestimmen.
      Dieser Modus eignet sich hervorragend für Durchsatzmessungen.

      Ohne -b sendet PsPing eher im Einzelpacket Modus und misst die Zeit von Übertragungsbeginn bis zum Eintreffen der Quittierungsmeldung.

      Ich habe früher auch viel mit iPerf gearbeitet. Aber wenn es um Performancedinge bei Microsoft angeht, habe ich es mir abgewöhnt iperf3 zu verwenden, weil ich schlichtweg von den Ausreden der Microsoftians die Schnauze voll hatte, bei denen die ständig behauptet haben, dass die Probleme die ich das sehe, nur die Bugs vom iPerf geschuldet sind.

      Dann habe ich eine Zeitlang mit ntttcp getestet, was übrigens 1:1 dasselbe offenbarte wie iperf und erst vor kurzem bin ich über PsPing gestolpert und fand es gleich von Anfang an gar nicht so übel.

      Alle drei genannten machen aber unter dem Strich, bis auf ein paar kleine Feinheiten, +- dasselbe.

      Beste Grüsse aus BaWü
      Alex

  9. Günter Born sagt:

    So, Teil 2 ist jetzt online, da sind Ross und Reiter genannt, die Spekulationen können daher eingestellt werden. Sorry, Sport ging heute vor, sonst blogge ich nicht mehr lange, sondern verabschiede mich zwangsweise in den Rolli,

    • Cornelia sagt:

      "… in den Rolli" ~= in den Rollstuhl? Das wäre doch sehr bedauerlich.

      Für mehrere Kommentare hier habe/hatte ich übrigens kein Verständnis. Da schon im Titel "Teil 1" steht, hätten einige der kritischen Entgegnungen getrost zurückgehalten werden können.
      Das ist das sprichwörtliche: 'Mit der Türe ins Haus kommen'.

      • Günter Born sagt:

        Zum ersten Satz: Ich versuche das Szenario zu vermeiden – aber die letzten Tage zwiebeln mich Nervenschmerzen und beginnende Spasmen – kann ich nur mit Sport und Physio dagegen halten.

        • Anonymous sagt:

          Ist jetzt völlig offtopic, aber schon mal TENS-Geräte ausprobiert? Wäre einen Versuch wert, ist aber nur etwas für Leute ohne Herzschrittmacher.

          • Günter Born sagt:

            EMS und TENS ist mir ein Begriff (gibt sogar eine Artikelreihe dazu im 50Plus-Blog) – werde ich ggf. auch die Tage wieder einsetzen, in der Hoffnung, da was abfangen zu können. Aber bei neuronalen Problemen muss man schon wissen, wo man die Elektroden ansetzt und welche Frequenzen, Stromstärken und Zyklen man fährt. Bin da leiderprobt, denn mit einem EMS-/TENS-Gerät kann man sich auch in eine Spasmen- oder Schmerzspirale katapultieren – da hilft dann kein Iboprofen & Co., da bei Nervenschmerzen wirkungslos.

            Der Absturz kam jetzt zu schnell und ich weiß nicht, woran es liegt (vielleicht war der Schrank zu schwer, den ich Montag zur Sperrmüllabfuhr auf die Straße gewuchtet habe). Die heutige Physiotherapie hat schon was gebracht. Aber bei Muskelatrophie bleibt nur dran bleiben, die Muskelfasern sind so schneller weg als man kucken kann.

Schreibe einen Kommentar zu Micha Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.