Performance SSD testen

Ganz entscheidende Faktoren bei der Perfance eines Rechners sind die Lese- und Schreibzugriffe auf Datenträger. Um die zu testen, braucht es keine Tools, obwohl das auch geht und ich schon mal 2021 genutzt habe. Das geht aber ebenso ziemlich gut mit Bordmitteln des Betriebssystems (etwa mit winsat, was ich auch schon mal genutzt habe) und solche Tests habe ich gerade mal wieder bei meiner Hardware durchgezogen. Bei mir kommt demnächst ein neuer Rechner ins Haus, denn meine bisherige Hardware hat schon ziemlich Zeit auf dem Buckel. Das Matebook ist über 4,5 Jahre, die Workstation bald 8 Jahre und mein Ersatz-Notebook sollte jetzt gut 15 Jahre alt sein. Wie alt mein ThinkCenter ist, kann ich nicht sagen, aber da ich sie vor ein paar Jahren refurbished für unter 40 EUR bekomme habe, sollte sie auch schon ein gesegnetes Alter aufweisen. „Performance SSD testen“ weiterlesen

Den Edge-Trojaner richtig wegbekommen

Nachdem Microsoft bei Windows-Updates im Moment jedes Mal wieder Edge auf dem Rechner ablädt, ist mir vor einiger Zeit der Tipp untergekommen, ihn in der Admin-Powershell im Installationsverzeichnis von Edge einfach den folgenden Befehl zu deinstallieren:

.\setup.exe –uninstall –system-level –verbose-logging –force-uninstall

Dazu kann man noch unter dem versteckten Verzeichnis .AppData alles mit dem Namen „Edge“ o.ä. löschen, damit kein Müll zurückbleibt und mit geeigneten Tools die Registry etc. aufräumen.

Das hatte auf den ersten Blick auch gut funktioniert. Nur ist mir gestern im Taskmanager aufgefallen, dass immer noch versteckte Edge-Prozesse gestartet waren. Selbst wenn ich sie von Hand abgeschossen hatte, waren die kurz darauf wieder da. Das Dreckding ist also nur vordergründig deinstalliert worden und wie ein Trojaner versteckt weiter gelaufen und hat „Dinge“ gemacht. Welche auch immer – notwendig sind sie nicht. Also können sie nur schädlich sein. Das erklärt eventuell auch, warum immer wieder Cookies von Bing bei mir auftauchen, obwohl ich diese Seite niemals angesteuert habe. Also Cookies der Art, die nicht im Browser-Kontext, sondern global auf dem Rechner versteckt werden.

Was jetzt aber wohl hilft Edge wirklich loszuwerden, sind die Gruppenrichtlinien. Bei den Administrativen Vorlagen unter Windows-Komponenten ist Edge zu finden und da muss man alles deaktivieren, wo das Wort „Zulassen“ auftaucht. Das scheint zu funktionieren. Denn danach habe ich im Taskmanager keine Edge-Prozesse mehr gefunden.

Microsoft kann es nicht lassen

Gestern ist wieder ein Windows-Update gelaufen und schon wieder hatte ich Edge auf Kiste. Ganz prominent mit Desktop-Verknüpfung. Es nervt, das Dreckding jedes Mal nach einem Update deinstallieren zu müssen. Aber aus dem Anlass nochmal der Hinweis, wie man den Mist weg bekommt. In der Admin-Powershell im Installationsverzeichnis von Edge einfach den Befehl aufrufen:

.\setup.exe –uninstall –system-level –verbose-logging –force-uninstall

Update Windows 10 aus der Konsole

Die regelmäßige Aktualisierung von Windows empfinde ich weitgehend als eine Katastrophe. Entweder aktualisiert sich Windows zum unpassenden Zeitpunkt (hatte ich gerade bei einem Kunden, bei dem das erzwungene Update während der Remoteschulung die Teilnehmer ziemlich blockiert hat) oder man deaktiviert das automatische Aktualisieren und dann ist man Out-Of bzw. die Geschichte lässt sich u:u: nicht wieder anschalten oder man sucht sich einen Zeitplan raus, von dem man vermutet, dass die Aktualisierungen nicht irgendwas anderes verhindern. Alles nicht wirklich der Bringer.

Auf meinen drei im Business-Einsatz genutzten Windows-10-Rechnern funktioniert das Windows-Update eigentlich nur auf meiner Workstation ohne großes Eingreifen. Und das auch nicht perfekt.

Auf meinem alten Terra-Notebook kann ich auf wuauserv gar nicht zugreifen. Ich bekomme immer einen Zugriffsfehler, wenn ich den Service starten will. Ich habe schon zig Wege versucht, aber alles ist bisher schief gelaufen (und selbstverständlich habe ich im Administrator-Modus gearbeitet). Auf dem Rechner bin ich mittlerweile mit einem Updates auf einem Stand von Anodazumal :-(. Was mich aber auch nicht extrem beunruhigt, da das Notebook schon mindestens 7 – 8 Jahre auf dem Buckel hat und nur durch ein Schnäppchen einer riesigen Notebook-SSD vor 2 Jahren vom kompletten Ausmustern gerettet wurde. Das Gerät ist wirklich nur noch mein Backup – sowohl als PC als auch Datenbackup vom NAS. Also Backup vom Backup. Dennoch – irgendwie will ich auch da mal ein Update hinbekommen. Ich spiele schon eine ganze Weile in der Powershell und mit net hin und her, aber bisher scheitert alles an den Zugriffsproblemen auf wuauserv.

Noch blöder ist es, dass ich auf meinem aktuellen Huawei-Matebook nur Windows Home mitgeliefert bekommen habe. Eine wirklich armselige Windows-Version (ja – me culpa – ich hätte ja schon auf die Pro-Version umsteigen können, aber bisher hatte ich noch keinen zwingenden Grund gesehen). Da hat man ja so gut wie keine Kontrolle über die Updates. Nicht einmal in den Einstellungen lässt sich der Dialog öffnen (warum auch immer). Ich bin bisher nicht einmal so ganz im Klaren gewesen, ob und welche Updates da installiert waren.

Aber da habe ich jetzt eine sinnvolle Lösung gefunden, um mit NuGet oder in der PowerShell Updates zu dem Zeitpunkt und dem von mir gewünschten Umfang zu erzwingen, wenn ich das will. Da ich die nächsten Wochen ein paar Remote-Schulungen zu C# halten werde, wollte ich vorher sowieso Visual Studio auf den neusten Stand bringen und dabei gleich NuGet ebenso. Und damit kann man dann auch Windows Updates komplett erzwingen. Schön in der Paket Manager-Konsole statt der grafischen, klebrigen Micky-Mouse-Oberfläche der PC Einstellungen. Oder man nutzt eben die PowerShell. Beides natürlich im Administrator-Modus.

Und das geht über die PowerShell so, dass man entweder PSWindowsUpdate oder WindowsUpdateProvider (Install-WUUpdates) verwendet. PSWindowsUpdate soll angeblich gegenüber des von Microsoft bereitgestellten PowerShell-Moduls Install-WUUpdates / Start-WUScan einige Vorteile bringen, aber da bin ich auf Hörensagen angewiesen.
Mit

Get-Command -Module WindowsUpdateProvider

findet man aber erst einmal heraus, welche Windows-Update-Provider auf einem PC verfügbar sind. Damit sieht man dann in etwa so etwas:

PS C:\WINDOWS\system32> Get-Command -Module WindowsUpdateProvider

CommandType Name Version Source
———– —- ——- ——
Function Get-WUAVersion 1.0.0.2 WindowsUpdateProvider
Function Get-WUIsPendingReboot 1.0.0.2 WindowsUpdateProvider
Function Get-WULastInstallationDate 1.0.0.2 WindowsUpdateProvider
Function Get-WULastScanSuccessDate 1.0.0.2 WindowsUpdateProvider
Function Install-WUUpdates 1.0.0.2 WindowsUpdateProvider
Function Start-WUScan 1.0.0.2 WindowsUpdateProvider

Sobald ein ausreichend neuer Build vorhanden ist, kann man dann Updates suchen und installieren (Updates für Windows und andere Microsoft-Produkte):

$Updates = Start-WUScan -SearchCriteria „IsInstalled=0 AND IsHidden=0 AND IsAssigned=1“
Write-Host „Updates gefunden: “ $Updates.Count
Install-WUUpdates -Updates $Updates

Ein anderer Weg führt eben über das PSWindowsUpdate-Modul, das so aus der PowerShell installiert werden kann (oder man nutzt einfach Visual Studio und da dann die Paket-Manger Konsole):

Install-Module -Name PSWindowsUpdate -Force

Danach kann man nach der Version schauen:

Get-Package -Name PSWindowsUpdate

 

Aber das passende NuGet-Version muss dabei vorhanden sein, wobei die auch bei Bedarf nachinstalliert wird. Die Ausgabe wird so etwas sein:

Name Version Source ProviderName
—- ——- —— ————
PSWindowsUpdate 2.2.0.2 https://www.powershellgallery… PowerShellGet

 

Für den nächsten Schritt sollten die Ausführungsrichtlinien für den aktuellen Prozess auf uneingeschränkt gesetzt werden:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Unrestricted -Force

Und dann holt man die verfügbaren Updates so:

Get-WindowsUpdate -MicrosoftUpdate -Verbose

Die Installation von allem ohne weitere Rückfrage geht dann so:

Install-WindowsUpdate -MicrosoftUpdate -AcceptAll -AutoReboot

Soweit habe ich die Sache mit meinem Matebook auch schon erfolgreich durchgespielt und jetzt werde ich mir das Terra-Notebook und auch die Workstation vornehmen und mal sehen, was ich da aktualisieren kann oder auch nicht.

Wenn das alles nicht hilft, werde ich nochmal den folgenden Tipp in der Admin-Konsole versuchen:

net stop wuauserv

net stop bits

cd %systemroot%

ren SoftwareDistribution SoftwareDistribution.bak

net start bits

net start wuauserv

Ich habe zwar wenig Hoffnung, dass die Geschichte insbesondere bei den Zugriffsproblemen auf wuauserv was hilft, aber vielleicht nutzt die Schrittfolge ja jemand anderem oder in einer anderen Konstellation beim Update.

Speed it up – Vol 2

Ich bin verwirrt – ich habe die MTU-Werte bei meinem Linux-Rechner als auch die iMac Mini in Eppstein kontrolliert und beide stehen auf dem ungünstigen Wert von 1.500. Trotzdem ist die Download-Geschwindigkeit deutlich über den Werten, die ich mit meiner Windows-Workstation in Bodenheim erreiche. Bei dem iMac kann ich das auf die bessere Leitungsqualität in Eppstein schieben, aber warum reproduzierbar mein altes Linux-Notebook in Bodenheim einen bessern Datendurchsatz hat als die viel potentere Windows-Workstation am gleichen DSL-Anschluss, bleibt mir ein Rätsel. Aber auch mein relativ neues Huawei-Notebook (mit Abstand der leistungsfähigste PC in meiner Armada von mehr als ein Duzend Rechnern) schafft nur unwesentlich bessere Downloadergebnisse als die Workstation. Auf jeden Fall unter den Werten von dem alten Linux-Notebook – trotz dessen ungünster MTU-Einstellung.

Es bleibt mir eigentlich nur der Rückschluss, dass Windows das Problem ist und sowohl Linux als auch das macOS einfach besser sind. Auch wenn die Tests nach der Anpasung des MTU-Werts in Windows reproduzierbar weniger schlechte Messwerte im Download liefern.

Speed it up

Nachdem meine Speedtests hier in Bodenheim bei der Vorbereitung der Onlineschulungen nächste Woche so grauenvolle Ergebnisse gezeigt haben, bin ich auf die Suche nach den Ursachen gegangen. Denn in Eppstein ging es deutlich besser.

Die Geschwindigkeitsangaben zu DSL im Router sind durch die Bank höher (in etwa das, was ich bei DSL 16.000 erwarten kann) als beim Speedtest und natürlich kann ein Test im Browser nicht die reale DSL-Geschwindigkeit abbilden. Aber wenn ich immer wieder das gleiche Messverfahren anwende, ist das zumindest vergleichbar.

Nun gibt es ein paar Stellschrauben, um die DSL-Geschwindigkeit zu optimieren. Aber ich hatte an denen natürlich schon in der Vergangenheit geschraubt und damit eigentlich alle Parameter gut eingestellt – dachte ich.

Aber als ich eben das 1x den Speedtest mit meinem alten Linux-Notebook durchgeführt hatte und da auch im Büro in Bodenheim halbwegs gute Download-Performance erreicht wurde, habe ich die Tests mehrfach parallel gefahren.

  • Notebook mit Linux – gut
  • Workstation mit Windows 10 – schlecht

Verlässlich. Und meine besten Download-Ergebnisse in Eppstein habe ich mit einem iMac Mini erreicht – also auch sowas wie Linux als OS.

Und dann ist mir endlich eingefallen, an welcher Schraube ich noch drehen kann – an der MTU (Maximum Transfer Unit). Damit wird die maximale Größe von TCP/IP-Paketen festgelegt. Das bei DSL eingesetzte Protokoll PPPoE limitiert sie auf 1492 Bytes. . Ein Router muss deshalb beim Übergang zum Internet die größeren Pakete auf kleinere umsetzen und das kosten Performance.

Aber die Paketgröße bei TCP wird von Windows standardmäßig schlecht (auf 1500) eingestellt. Das macht Linux (und vermutlich macOS auch) m.W. intelligenter, was ich aber nochmal nachsehen muss. Zuerst wollte ich aber die Workstation untersuchen. Also nachgesehen, wie die MTU bei der Workstation ist:

netsh int ipv4 show subinterface

in der Admin-Powershell.

Und in der Tat – auf 1500 gesetzt.

Nun wird in der Praxis entweder 1472 oder 1492 als optimal empfohlen. Also mit 1472 probiert. Bei mir in der Powershell mit dem Adapter Ethernet 2:

netsh interface ipv4 set subinterface „Ethernet 2“ mtu=1472 store=persistent

Speedtest unverändert.

Danach 1492.

Speedtest fast 2 MBit/s mehr im Download. Nachfolgende Tests zwar wieder schlechtere Ergebnisse, aber dennoch im Schnitt flotter als mit MTU 1500.

Die Rechner im lokalen Netzwerk verwenden jedoch standardmäßig eine Paketgröße von 1500 Bytes Einigen DSL-Routern, so auch der Apple Base Station, scheint dies bei SSL-Verbindungen jedoch nicht korrekt zu gelingen.

Auf PCs mit Linux setzt man den MTU-Wert abhängig von der Distribution. Red Hat setzt das beispielsweise ist in der Konfigurationsdatei /etc/sysconfig/network-scripts/ifcfg-device-name über die Zeile MTU=1492. Der device-name lautet bei Rechnern mit einer Ethernet-Schnittstelle in der Regel en0. Allgemein sucht man so:

ifconfig| grep mtu
Und setzen kann man mit nano /etc/network/interfaces.

Unter Mac OS X ist der Shell-Befehl zum Anpassen der MTU sudo ifconfig device-name mtu 1492, was die Eingabe eines Administratorpassworts erfordert.