Synology VMM | Windows VM mit starker CPU Auslastung durch “System interrupts”

Ich muss hier einen Fall von Layer-8 Ignoranz schildern – mit etwas Vorgeschichte.

Alles Cloud …

Vor vier Monaten erzählte mir ein Freund, dass er eine Praxis übernehmen würde – mit einer Softwarelösung, die zu 100% in der Cloud läuft. „Wir brauchen nur ein paar Tablets und Internet, da kannst du mir vielleicht helfen?“ Wo fängt man da an …

  1. Es gab PCs, Baujahr 2018 oder 2019 – so genau wusste das niemand. Man hielt sie für „relativ neu“. OK – relativ. Und mit <Panikmodus>Festplatten</Panikmodus>
  2. Ein neues, dreidimensionales Röntgengerät musste her. Die Daten sollten direkt in die Cloud gespeichert werden – allerdings braucht es dazwischen ein „Laufwerk“ als Cloud-Cache
  3. Dazu kamen diverse Konnektoren – wofür auch immer

Die Informationen sickerten nach und nach durch. Ein vollständiges Bild hatten wir erst 14 Tage vor der Wiedereröffnung der Praxis.

Where the rubber meets the road …

Für Punkt 1 konnte ich mit etwas Überzeugungsarbeit ein Synology-NAS (RS822+) ins Spiel bringen. Dank Synology Directory Server gab es eine kleine Domäne, über die sich die PCs (nun mit SSDs ausgestattet) verwalten ließen.

Mit maximalem RAM ausgestattet, liefen darauf zwei bis drei kleine VMs. Der AMD Ryzen 1500B ist zwar kein Kraftpaket, aber für kleine Aufgaben reicht’s. Die Bereitstellung der VMs übernahm der Synology Virtual Machine Manager (VMM), also QEMU/KVM so mehr oder weniger.

Zwei Windows-VMs wurden eingerichtet:

  • Eine mit 4 vCPUs, 16 GB RAM und 2 TB Speicher für den Cloud-Cache (Punkt 2).
  • Eine weitere mit 10 GB RAM für einen Healthconnector.

Nach einigen Optimierungen liefen die VMs stabil und flott – auch dank SSD-Cache im NAS.

Punkt 3: Die Konnektoren

Der erste Konnektor ließ sich problemlos installieren. Kein Thema. Dann kam der RISE-Konnektor – und wie so oft: ein Dienstleister, der sich als besonders „resistent“ erwies.

Natürlich, der Dienstleister ist immer der andere … Winking smile

Die „Anforderung“, in der virtuellen Windows-VM (QEMU/KVM-basiert) das „Hyper-V Networking“ zu installieren, war für mich nicht nachvollziehbar. Angeblich sei das für WireGuard-VPN nötig?! Das Eventlog zeigte jedenfalls mehr als nur „Hyper-V Networking“ – vielleicht hatte er sich jemand verklickt.

image

Mir ist kein explizites „Hyper-V Networking“ bekannt. Windows bietet auf dem Client die folgenden Features an:

Vor dem Reboot sah der Taskmanager noch wie folgt aus …

image

Die Konsequenzen waren aber dem Reboot zu sehen und verheerend.

image

Der Screenshot zeigt nicht das gesamte Ausmaß des Desasters, die virtuellen CPUs liefen über weite Strecken auf 100% und ein Arbeiten war nicht mehr möglich. Weder RDP-Sitzungen noch TeamViewer funktionierten. Auch mehr vCPUs halfen nicht wesentlich.

Ich konnte die Last auf etwa 40 % drücken – aber die VM blieb träge. Sehr träge.

image

Sobald die Hyper-V-Rolle innerhalb des Windows 11-Gastsystems installiert ist, beginnt sich die virtuelle Maschine selbst wie ein Hyper-V-Host zu verhalten (oder versucht es zumindest). Dies verändert die Art und Weise, wie Windows mit der zugrunde liegenden Hardware und der Virtualisierungsschicht interagiert und führt häufig zu:

  • Konflikten bei verschachtelter Virtualisierung: Hyper-V innerhalb einer VM (Nested Virtualization) kann mit den eigenen Virtualisierungsmechanismen von QEMU/KVM interferieren.
  • Problemen bei der Interrupt-Verarbeitung: Das System kann auf andere Taktquellen oder Interrupt-Modelle umschalten (z. B. hyperv_clocksource_tsc_page vs. tsc), was zu übermäßigen System-Interrupts und einer verschlechterten Leistung führen kann
  • Verändertes Timer- und Polling-Verhalten: Hyper-V kann beeinflussen, wie das Gastbetriebssystem Leerlaufzustände und Interrupts behandelt – insbesondere, wenn Funktionen wie halt_poll nicht abgestimmt sind

Ein zeitaufwändig erstellter Dump des Systemprozesses (PID 4) zeigte massenhaft IRPs – ein weiteres Indiz für Probleme durch Hypervisor-Verschachtelung.

image

Hyper-V musste also wieder runter

Final blieb nur die Möglichkeit Hyper-V zu entfernen, was dem Dienstleister nicht wirklich gefallen hat. Die Lösung war die Installation des RISE-Konnektors auf einen der PCs in der Praxis, wobei hier auf das Hinzufügen der Hyper-V Rolle verzichtet wurde?!Wir fragen nicht und nehmen die Alternative mal einfach so hin Sick smile

Die beiden folgenden PowerShell Aufrufe zeigten halfen das System dann anschließend zu korrigieren und in einen nutzbaren Zustand zu versetzen:

# Anzeigen aller aktivierten (enabled) Features in Windows 11
Get-WindowsOptionalFeature -Online | Where-Object {$_.State -eq "Enabled"}
# Deaktivieren der Hyper-V Rolle + manuellem Reboot hinterher
Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All

Nach dem Neustart lief der RISE-Konnektor mit ~10 % Systemlast. Der Dienstleister war da schon am nächsten PC – und ich hatte ehrlich gesagt keine Lust mehr. Hauptsache, die VM lief wieder.

So, genügend Angry smile – einfach aufpassen und schauen, was “Fachkräfte” auf den Systemen so installieren und sich die Systemanforderungen im Vorfeld schriftlich per Mail besorgen.

Enjoy it, b!

Synology NAS | Replikation von Shares funktioniert nach Update vom 08.10.2025 nicht mehr

Mahlzeit zusammen, den Beitrag will ich heute ein Stück weit anders aufziehen. Gestern habe ich auf zwei NAS-Systemen ein Update einer Reihe von Paketen gemacht, einige unter anderem auch die Snapshot Replication, trugen den Verweis der Kompatibilität zur neuen Version 7.3 des DSM.

Das Problem

Nach dem Update der Pakete befindet sich die Replikation in folgendem Zustand.

image

Das Einrichten neuer Replikas schlägt mit einer nicht mehr endenden wollenden Replikation fehl.

Erste Lösungsversuche

Nach einigem Suchen, habe ich mich entschlossen einen Support-Case zu öffnen und hier war bis jetzt die Aussage, dass ich ein Upgrade des DSM auf die 7.3 versuchen soll. Zumindest auf den Synology RS1619xs+ wird die 7.3 nicht direkt angeboten sondern muss aus dem Support-Bereich geladen werden.

Hier der Download auf der Supportseite von Synology:

https://www.synology.com/de-de/support/download/RS1619xs+?version=7.2#system

Konkret wird es um ein Upgrade von 7.2.272806 auf 7.3-81180 gehen.

image

Heute Abend / Nacht will ich das Upgrade wagen …. stay tuned und …

Update 10.10.2025

Das manuelle Upgrade des DSM auf die Version 7.3-81180 wahr erfolgreich. Allerdings gab es auch hier zwei Punkte zu beachten.

  1. Die Snapshot Replication meldete einen “… ongoing Task”
  2. Eine Reihe von Anwendungen mussten nach dem Update auf 7.3 manuell aktualisiert werden
    – Active Backup * (Alle Active Backup Anwendungen wie Active Backup for Business und Active Backup for Microsoft 365 …)
    – PHP von 7.x auf 8.2

Punkt 1 habe ich mit einem reboot in den Griff bekommen:

Untitled-a

# Erzwingt einen Neustart ohne Synchronisierung oder Umount des Dateisystems. Dies sollte nur verwendet werden, wenn das System nicht mehr reagiert..
sudo reboot -f

Die VMs hatte ich davor natürlich heruntergefahren. Gerade im Bezug auf den Replikationsdienst lohnt sich vor dem Hammer mit oben (reboot -f) ein Beenden des eigentlichen Prozesses.

image

# Wenn der Prozess nicht auf SIGTERM reagiert, kann er mit dem Signal SIGKILL zwangsweise beendet werden
kill -9 pid

Punkt 2 war ebenfalls unproblematisch

Download der folgenden Pakete von Synology und manuelle Installation:

  • ActiveBackup-Office365-x86_64-2.6.1-14212.spk
  • ActiveBackup-x86_64-3.1.0-24948.spk
  • PHP8.2-x86_64-8.2.28-0107.spk

Ich habe die manuelle Installation durchgeführt (ohne die alten Pakete davor zu löschen).

Läuft Winking smile wieder …

Untitled-b

Zur Replikation noch drei Dinge die mir aufgefallen sind.

  1. Die auf “Replication Stopped” stehenden Replikas konnten manuell, nachdem beide NAS-Systeme auf DSM 7.3 aktualisiert waren, gestartet werden
  2. Neue Replikas konnte ebenfalls ohne Problem erstellt werden
  3. Nicht manuell gestartete Replikas wurden gemäß dem Zeitplan aktiviert und ausgeführt

Enjoy it, b!

Synology NAS | „there is an ongoing replication…“

Die Synology SnapShot Replication dient zur Replikation von Freigaben (Ordnern) auf ein anderes Synology-NAS. Einmal eingerichtet, funktioniert diese sehr zuverlässig – mit einer Ausnahme.

Das Problem ist, wenn es zu einer Änderung der IP-Adressen kommt

Angenommen, an einem der zahlreichen Adapter einer RS822+ wird eine Konfiguration geändert, wodurch eine weitere IP-Adresse im DNS registriert wird.
Danach wird die Replikation mit dem FQDN anstatt einer IP-Adresse eingerichtet.

Unbenannt-1

Solange beide IP-Adressen funktional und erreichbar sind, ist das kein Problem. Fällt aber eine der beiden wieder weg, bleibt sie erst einmal im DNS vorhanden und wird gemäß dem Round-Robin-Mechanismus im DNS (RFC 1749) bei Abfragen zurück geliefert. Da das NAS über diese Adresse aber nicht mehr erreichbar ist, kommt die Replikation ins Stocken und schlägt fehl. Was bei einem versuchten Neustart zu der in der Überschrift gezeigten Meldung (there is an ongoing replication …) führt und diesen verhindert.

Manchmal dauert es Stunden, bis sich die Replikation wieder erholt (unter der Voraussetzung, dass der nicht mehr vorhandene DNS-Eintrag gelöscht wurde) und solange kann das NAS kann auch nicht ohne Weiteres rebootet werden.

Ein Neustart über die Weboberfläche des DSM schlägt mit der Meldung „There is an ongoing replication task …“ fehl.

Ein Neustart des NAS über SSH, nicht optimal aber möglich

Eine Lösung, wenn man nicht warten will, ist der Neustart des NAS über eine SSH-Session. Dazu muss SSH aber aktiviert werden …

Control Panel / Connectivity / Terminal & SNMP

Unbenannt-2

… und natürlich auf Apply (rechts unten) klicken, damit die Änderungen übernommen werden.
Damit ist der Zugang zum NAS per SSH aktiviert und ein „erzwungener“ Neustart mit einem Benutzer, der die entsprechenden Rechte hat, möglich.

image

Bevor man das NAS nun „abschießt“, ist es ratsam, manuell Prozesse soweit wie möglich zu stoppen. Das heißt, virtuelle Maschinen herunterzufahren eventuelle Container zu stoppen und so weiter.

Hier die entsprechenden Befehle und Möglichkeiten:

# Anmeldung
ssh admin_username@nas_ip_address

# Wechsel mit sudo in den Root-Modus (optional)
sudo -i

Für den Shutdown / Reboot gibt es die folgenden Optionen:

# Beendet Dienste vor dem Neustart ordnungsgemäß, funktioniert aber bei einer hängenden Snapshot-Replikation nicht.
sudo reboot

# Startet sofort neu, wobei einige Abschaltroutinen übersprungen werden. Hat meistens bei der Snapshot-Replikation funktioniert.
sudo shutdown -r now

# Erzwingt einen Neustart ohne Synchronisierung oder Umount des Dateisystems. Dies sollte nur verwendet werden, wenn das System nicht mehr reagiert..
sudo reboot -f

# Dadurch werden alle Shutdown-Skripte umgangen und das System wird sofort neu gestartet. Letzte Instanz 🙂
echo 1 | sudo tee /proc/sys/kernel/sysrq
echo b | sudo tee /proc/sysrq-trigger

Enjoy it, b!

Supermicro X11SSL-F | Windows Server 2022

Für das Supermicro-Motherboard X11SSL-F endet mit Windows Server 2019 der Support des Herstellers und auch der verbaute RAID-Controller (LSI MegaRAID SAS 9271-4I) hat schon einige Jahre hinter sich.

Dennoch war die Aufgabe, den Server mit Windows Server 2022 zu installieren. Da der Server bereits mit Windows Server 2019 (Hyper-V Server 2019) lief und ein Inplace-Upgrade von Microsoft unterstützt wird, lag diese Vorgehensweise nahe. Das Abenteuer endete oder begann – je nachdem, wie man es sehen will – mit einem BSOD.

74rwmoxe_ON1_Cloud

Leider wurde kein Dump geschrieben, da ich aber genau diese Hardware 2024 mit Hyper-V Server 2019 installiert hatte und damals der Treiber aus dem Betriebssystem verwendet wurde, kam mir der Verdacht das möglicher Weise der Treiber das Problem verursacht. Der storport.sys deutet ja in die Richtung der Platten.

Im Verlauf der Fehleranalyse haben sich zwei Wege für die Installation von Windows Server 2022 herauskristallisiert:

  • Inplace-Upgrade von Hyper-V Server 2019 auf Windows Server 2022 mit einem zuvor aktualisiertem Treiber für den LSI 9271-4I
  • Neuinstallation von Windows Server 2022 und Bereitstellung des Treibers für den LSI 9271-4I während der Installation

Für beide Abläufe ist der aktuellste Treiber (MR Windows Driver 6.14-6.714.05.00) notwendig, der sich hier zum Download findet.

https://docs.broadcom.com/docs/MR_WINDOWS_DRIVER_6.14-6.714.05.00-WHQL.zip

Inplace-Upgrade

Bevor das Inplace-Upgrade gestartet wird, muss zwingend der Treiber aktualisiert werden. Läuft man auf der Core-Version eines Windows Servers, so geht das am einfachsten über das Server Core App Compatibility Feature on Demand (FoD), welches nach der Installation den Device-Manager mitbringt, oder mit pnputil.exe.

# Installation der Windows Server Core App Compatibility (online)
Add-WindowsCapability -Online -Name ServerCore.AppCompatibility~~~~0.0.1.0

# Alternativ mit pnputil.exe
pnputil.exe -i -a oemdriver.inf

Zusätzlich, da dies direkt vom Betriebssystem ausgemacht werden kann,habe ich noch das BIOS des Rechners mit SUM und auch die Firmware des BMC aktualisiert.

Jetzt das Setup über eine ISO-Datei oder besser einen USB-Stick starten.

Neuinstallation

Die Neuinstallation, verläuft wie gewohnt! Nur das der Server die Volumes des LSI 9271-4I schon sieht, hier wird nun trotzdem der neue Treiber über Load driver geladen.

image

Wenn die Installation von einem USB-Stick erfolgt, kann man den Treiber gleich in entpackter Form mit drauflegen.

Für beide Wege, gibt dieser Artikel entsprechende Hinweise wenn im Device-Manager nicht erkannte Treiber vorhanden sind.

Enjoy it, b!

Synology Directory Server | Zertifikat abgelaufen

Wenn im Synology DSM das Zertifikat für den Synology Directory Server (SDS) abgelaufen ist, gibt es die Möglichkeit dieses Online wieder zu verlängern. Dazu sind die folgenden Schritte notwendig:

  1. Der Vorgang muss auf jedem Synology Directory Server (also auf jedem NAS) explizit durchgeführt werden (in diesem Netzwerk sind zwei davon vorhanden)
  2. Der DNS muss “korrekt” konfiguriert sein, was einfach bedeutet das mit dem NAS eine Verbindung in das Internet möglich ist und externe Domains aufgelöst werden
  3. Das DSM muss von außen über Port 80 (HTTP) erreichbar sein. Dazu muss auf dem Router eine Weiterleitung von Port 80 extern auf die <NAS-IP>:80 intern eingestellt werden. Danach ist diese Regel sofort wieder zu deaktivieren!

Im Detail sieht das wie folgt aus:

image

  • Issued by: domain.tld | Beispiel home.local
  • Subject Alternative Name: domain-controller.domain.tld | Beispiel mausi.home.local

Hier die Regel im Router, in diesem Fall ein Mikrotik:

image

Das hätte man auch ein wenig anders realisieren können, aber für die zwei Minuten funktioniert es sehr gut.

Nun wird im DSM unter Security / Certificate das Zertifikat ausgewählt und mit Action / Renew certificate das Renewal angestoßen.

image

Zur Sicherheit gibt das DSM nochmals einen Hinweis auf die notwendige DNS / Firewall-Konfiguration.

image

Mit  Renew Certificate dauert der Vorgang nur wenige Sekunden und es ist lediglich erforderlich, die Seite erneut zu laden.

image

Jetzt wieder Port 80 auf dem Router schließen und wir sind fertig.

Enjoy it, b!

Lenovo L470 | Entladung des Akkus im ausgeschalteten Zustand :-(

Wenn ich in der Forensik tätig werden muss, nehme ich gerne ein Laptop mit Linux als Arbeitsgerät. In infizierten Windows-Netzwerken – vor allem, wenn ich direkt beim Kunden ins Netzwerk muss – bietet dieses Betriebssystem deutlich weniger Angriffsvektoren. Das bedeutet allerdings nicht, dass Linux nicht angreifbar ist (das wäre aber eine andere Geschichte).

Darum soll es hier aber gar nicht gehen. Kürzlich wurde ein Upgrade fällig und ich konnte ein Lenovo L470 erstehen, das nicht mehr Windows 11 tauglich ist. Mit 32 GB RAM, einer 1TB-SSD und einem Intel-I7-Prozessor ist es ein mehr als üppiges Arbeitsgerät. Einzig der dicke Akku mit 44Wh störte mich. Da er schon alt war und einiges an Kapazität verloren hatte, dachte ich an einen Austausch gegen ein 24Wh No-Name-Äquivalent.

Alter Akku raus und neuer Akku rein und fertig, dachte ich!

Nach einem Tag war das Laptop leer und wollte eine Korrektur der BIOS-Einstellungen. Zunächst hatte ich natürlich den neuen Akku in Verdacht. Nachdem ich jedoch die CMOS-Batterie ausgetauscht und einen Akku eines anderen No-Name-Herstellers verwendet hatte, zeigte sich, dass der Akku in Ordnung war. Auch mit dem anderen Akku war das L490 nach einem Tag leer … doch warum?

Vor der Installation von Linux hatte ich das BIOS zurückgesetzt und die aktuelle Firmware installiert. Nach ein paar Tagen habe ich den Akku gewechselt.

Da das mehrfache Wechseln der Akkus keine Lösung brachte, bin ich auf einen Artikel von Lenovo gestoßen:

Die Batterie kann entladen werden, wenn das System ausgeschaltet oder im Energiesparmodus ist – ThinkPad, ideapad – Lenovo Support DE

BIOS

Dazu muss im BIOS die folgende Option auf “Disabled” gesetzt werden:

Charge in Battery Mode = [Disabled]

Jetzt hält der Akku und verliert so gut wie keine Kapazität im ausgeschalteten Zustand.

Enjoy it, b!

Windows 11 | Kernelisoierung

Wenn in Windows 11 aufgrund eines inkompatiblen Treibers die Speicherintegrität nicht aktiviert werden kann, kann der entsprechende Treiber deinstalliert werden, sofern er nicht verwendet wird.

Hier die Meldung von Windows 11:

image

Bevor nun der Treiber deinstalliert wird, ist es sinnvoll zu prüfen ob dieser nicht doch geladen ist. Für diesen Fall, konnte ich das schon im Vorfeld ausschließen, da es sich um mein eigenes Surface Laptop Studio handelte und ich keine WDC-Geräte im Einsatz habe.

Der folgende “One-Liner” in PowerShell zeigt, ob zum Beispiel der Treiber für “Volume Shadow Copy / volsnap” geladen ist (Quasi als Test).

# Check if volsnap\.sys is running
Get-CimInstance Win32_SystemDriver | Where-Object { $_.State -eq 'Running' -and $_.PathName -match 'volsnap\.sys' } | ForEach-Object { "Driver '$($_.Name)' is running from path: $($_.PathName)" }

image

Wie im folgenden Aufruf zu sehen, muss nun der Volsnap gegen den WDCsam64_PreWin8 ausgetauscht werden. Der Name lässt sich übrigens über die Zwischenablage kopieren. Im Gegensatz zu oben darf nun nichts angezeigt werden.

# Check if wdcsam64_prewin8\.sys is running
Get-CimInstance Win32_SystemDriver | Where-Object { $_.State -eq 'Running' -and $_.PathName -match 'wdcsam64_prewin8\.sys' } | ForEach-Object { "Driver '$($_.Name)' is running from path: $($_.PathName)" }

Jetzt kann der WDC-Treiber entfernt werden. Am einfachsten geht das mit pnputil.exe, wenn man den “Veröffentlichter Name“: oem26.inf verwendet (oben im Screenshot blau unterstrichen). Die Eingabeaufforderung dazu bitte als Administrator ausführen.

# Deleting wdcsam64_prewin8.sys driver
pnputil /delete-driver oem26.inf /uninstall /force

image

Jetzt den PC neu starten und die Speicherintegrität kann eingeschaltet werden, was aber danach einen erneuten Neustart erfordert.

image

Sieht am Ende so aus und Windows 11 ist damit auch zufrieden.

image

Enjoy it, b!

P.S. jetzt kümmere ich mich darum wieso Windows 11 glaubt, dass mein Laptop alles in DE-DE anzeigen muss, obwohl ich EN-US eingestellt habe.

Windows Server 2016 | Update NuGet fails

Ein paar Tage hat er ja noch, der Windows Server 2016 und falls mit PowerShell neue Module geladen werden sollen kann eine Aktualisierung des NuGet-Paketproviders erforderlich sein.

Sollte diese fehlschlagen und die folgende Fehlermeldung erscheinen, kann das an einer nicht ausreichenden Transportverschlüsselung liegen.

Hier die Fehler beim Versuch ein PowerShell-Modul zu installieren, was wiederum eine Aktualisierung von NuGet notwendig machte.

image

Bei dem Versuch die Aktualisierung manuell durchzuführen.

image

Die Lösung lag in der Verwendung von TLS1.2 für .Net.

# Forcing .Net to use TLS1.2 instead of SSL3 or lower TLS versions
[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12;

image

Danach hat auch die Installation des PowerShell Windows Update Modules ohne Probleme funktioniert.

Enjoy it, b!

WSUS | Optimierung des IIS (WSUS Application Pool)

Hier auf dem Blog gibt es einige Artikel zum Thema WSUS (Windows Server Update Services) und ja, ich stimme Euch zu. Man kann ihn wirklich hassen oder lieben, doch besonders in den heutigen Zeiten bin ich mehr als froh, wenn ich auf einfache Weise ein Update zurückhalten kann. Es läuft momentan nicht optimal mit den Windows Updates Winking smile

Hier nochmals eine Aufstellung der Beiträge:

Doch worum geht es heute? Microsoft liefert einen umfangreichen Beitrag zu den Windows Server Update Services best practices, die immerhin am 02. Februar 2025 ihre letzte Überarbeitung erfahren haben.

Windows Server Update Services (WSUS) best practices – Configuration Manager | Microsoft Learn

Besonders hervorzuheben sind die notwendigen Einstellungen für den WSUS Application Pool.

image

Diese Einstellungen können auch mit der PowerShell konfiguriert werden, was insbesondere bei mehreren WSUS eine Erleichterung darstellt.

image

Zum Download gibt es den Code hier.

Enjoy it, b!

Surface Pro 9 | Langsames Kopieren auf eine SSD

Ich denke, dass die folgenden Erkenntnisse auf jeden Computer mit Windows 11 übertragbar sind, sofern er über eine schnelle Schnittstelle (USB-C oder Thunderbolt) verfügt.

Analysiert habe ich das alles auf einem Microsoft Surface Pro 9 und daher rührt der Titel.

Ausgangssituation

Ich verwende externe SSDs hauptsächlich (zu 95%) als Speichermedium für Fotos und RAW-Dateien. Früher liefen auf meinen externen Festplatten oft virtuelle Maschinen (VMs), die vielleicht die restlichen 5% ausmachen.

Es handelt sich um Dateigrößen zwischen 25MB und bis zu 100MB, eine VM kann also auch mal 50 oder 100GB haben, wahrscheinlicher ist aber, dass auf der externen SSD ein paar ISO-Dateien herumliegen (die sind meistens zwischen 4 und 6GB groß).

Die beiden Schnittstellen des Surface sind als USB-C nach der USB 4.0-Spezifikation ausgeführt und leisten zumindest theoretisch 40GBit/s.

Als Übersicht hier die einzelnen Geschwindigkeiten, da wir diese nachher noch benötigen (als Anhaltspunkt).


Spezifikation Geschwindigkeit
USB 2.0 480Mbit/s ~ 60MB/s
USB 3.0 5Gbit/s ~ 625MB/s
USB 3.1 10GBit/s ~ 1250MB/s
USB 3.2 20GBit/s ~ 2500MB/s
USB 4.0 40GBit/s ~ 5000MB/s

Kurz vor meinem Urlaub wollte ich eine Reihe von Verzeichnissen mit Bildern (etwas über 100 GB) auf eine zweite externe SSD sichern, was über eine halbe Stunde dauerte. Die beiden verwendeten externen SSDs waren eine alte Samsung Portable T5 mit 1TB und eine Samsung Portable T7 mit 4TB.

  • Samsung Portable SSD T5 mit USB 3.1 und ~ 540MB/s
  • Samsung Portable SSD T7 mit USB 3.2 und ~1000MB/s

Meine Erwartung war, dass die 100GB Daten in weniger als 10min kopiert werden.

Der eigentliche Test

Um die Sache nicht unnötig kompliziert zu machen, habe ich mich für das ISO von Windows 11 in der Version 23H2 als Testobjekt (mit 6,8GB) entschieden.

Ein erster Test ergab eine Schreibgeschwindigkeit von ~ 30MB/s was deutlich unter den Möglichkeiten der alten Samsung T5 liegt.

image

Auch robocopy bestätigte in seiner Zusammenfassung die geringe Performance.

image

Mein erster Verdacht fiel auf das verwendete USB-Kabel, ein USB-C Ladekabel von UGREEN, da dieses vom Hersteller mit 480Mbps angegeben wird und somit schnell genug für die 540MB/s des Samsung T5 sein sollte. Trotzdem habe ich das USB-Kabel von UGREEN durch ein original “Samsung SSD” USB-C Kabel ersetzt und damit eine 10x höhere Schreibrate erreicht.

image

Robocopy hat hier eine Geschwindigkeit von 323.678.163 Bytes/sec. ermittelt.

Das ist die erste Erkenntnis, die ich zusammenfassen möchte:

Es kommt auf das Kabel an, genauer gesagt auf dessen Bandbreitenspezifikation.

Das USB-C Kabel von UGREEN hat seinen Weg zu mir gefunden, als ich versuchte, die Anzahl der Kabel für ein größeres Projekt zu minimieren.

Dabei stellte sich mir die Frage, ob man mit einem geeigneten Kabel und einer schnelleren SSD wie der T7 noch höhere Übertragungsraten erzielen könnte.

Testmuster mit einer Samsung Portable Shield T7 4TB

Neben einer doppelt so hohen Schreibgeschwindigkeit will ich mir auch den Einfluss der Windows Write-Caching Policy anschauen.

Wie schon die Samsung Portable T5 war auch die T7 wie folgt eingestellt.

image

Damit war eine Geschwindigkeit von um die 540MB/s zu erreichen.

image

Ob in der Write-caching policy die beiden Optionen Enable write caching on the device und Turn of Windows wirte-cache buffer flushing on the device aktiviert waren, spielte keine große Rolle.

image

Die Datenrate erhöhte sich um ~ 25MB/s auf 560MB/s.

Die zweite Erkenntnis wäre damit, dass hauptsächlich die Einstellung Removal Policy = Better Performance eine Rolle spielt, insofern das passende Kabel verwendet wird.

Removal Policy = Better Performance

Möchte man also sowohl sein Surface über das Kabel laden als auch eine externe SSD mit guter Performance betreiben, so muss dieses beiden Spezifikationen entsprechen. Die Annahme, dass wenn das Kabel schnellladefähig ist, auch eine hinreichende Übertragungsrate erzielt wird, kann ich nicht bestätigen.

Das beste kommt zum Schluss

Natürlich könnte man die Frage stellen, was mache ich wenn mein originales Kabel verloren geht? Richtig, aufpassen Winking smile aber es gibt auch noch Alternativen. Im großen Fluss habe ich ein, für USB4 zertifiziert Kabel gefunden (30cm) das ebenfalls 40Gb/s. Die Hoffnung war das es ungefähr die Datenrate des Samsung-Kabels erreichen würde. Dem war aber nicht so, mit diesem Kabel waren 15% mehr Durchsatz möglich.

image

Enjoy it, b!