drive.google.com
C:\Program Files\smartmontools\bin>smartctl -A /dev/sdc
smartctl 7.2 2020-12-30 r5155 [x86_64-w64-mingw32-w10-20H2] (sf-7.2-1)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF SMART DATA SECTION ===
SMART/Health Information (NVMe Log 0x02)
Critical Warning: 0x00
Temperature: 47 Celsius
Available Spare: 100%
Available Spare Threshold: 10%
Percentage Used: 1%
Data Units Read: 40.684.396 [20,8 TB]
Data Units Written: 29.956.598 [15,3 TB]
Host Read Commands: 1.148.367.555
Host Write Commands: 818.473.183
Controller Busy Time: 205
Power Cycles: 137
Power On Hours: 307
Unsafe Shutdowns: 21
Media and Data Integrity Errors: 0
Error Information Log Entries: 0
Warning Comp. Temperature Time: 0
Critical Comp. Temperature Time: 0
Temperature Sensor 1: 47 Celsius
Temperature Sensor 2: 57 Celsius
100% Auslastung der CPU im Taskmanager sagt nicht aus, dass die SSD am Limit läuft, sondern nur das zu 100% der Zeit mindestens eine Anfage ausstehen ist, was bei so vielen parallelen Zugriffen ja gar nicht anderes sein kann. Daher kann man die Prozentangabe der Laufwerke im Taskmanager nicht mit der für die CPU vergleichen, die nur 100% erreicht, wenn alle Kerne voll ausgelastet sind. Tatsächlich sollte die SSD sogar bei QD1 zu 100% oder wenigstens 99% ausgelastet sein, wenn es nur ein 4k Zugriff ist, schafft Deine lesend knapp 59MB/s, also nicht einmal 1% dessen was sie bei 8 parallelen 1MB Zugrifen (SEQ1M Q8T1) oder 32 parallelen 128k langen Zugriffen (SEQ128K Q32T1) schafft. Auch zeigt der direkte Vergleich der beiden letzteren, dass 32 parallele Zugriffe für 128k mehr Leistung aus der SSD kitzeln können als 8, also nur ein Viertel der Zugriffe, selbst wenn von denen jeder 8 mal so lang ist, insgesamt also über 8 statt nur 4MB gelesen wird. Dabei sind aber bei Heimanwendern schon 4 parallele Zugriffe eine seltene Ausnahme.
Man sollte auch nicht so schnell hintereinander benchen, sonst kann es ja nicht anderes sein, da beim Benchen der Pseudo-SLC Schreibcache natürlich gefüllt wird und wenn der nich zu groß ist, dann kann beim nächsten Lauf nicht so schnell geschrieben werden.
Dann hat es doch entweder mit PCIe 4.0 oder der AM4 Plattform zu tun. Es müsste also mal jemand auf Rocket Lake testen ob es da auch so ist, dann könnte man dies weiter eingrenzen.
Nein, da SSDs den DRAM Cache für die Verwaltungsdaten nutzen, also vor allem die Mappingtabelle, deshalb ist dessen Größe ja auch in aller Regel propotional zur Kapazität der SSD. Die DRAM Caches sind keine Schreibcaches und haben daher keinen direkten Einfluss auf die Scheibgeschwindigkeit, allenfalls einen indirekten, sollte der Controller erst Teil der Verwaltungsdaten aus dem NAND in seinen internes DRAM laden müssen um zu schauen wo freie NAND Pages sind.
Wie gesagt. SystemRestore hilft und ist einfach zu machen.
Die SSD muss Idle sein, wenn da ständig drauf zugegriffen wird, dann hat der Controller keine Zeit den Schreibcache zu leeren. Das ist bei Dir ja C:, also das Systemlaufwerk und da musst Du doch wissen was dabei Dir da alles für Zugriffe stattfinden, schau halt mit dem Resourcen Monitor und HWInfo64 -> Sensors mal nach, denn der Resourcen Monitor bildet einen Durchschnitt über eine recht lange Zeit ab, aber sieht man also auch noch Zugriffe die schon beendet sind.
Was weiß ich, dies hängt halt davon ab wie lange der Controller wirklich Idle ist und wie viele Daten im Pseudo-SLC Schreibcache stehen. SimonX200 hat dazu ja einiges ausprobiert.
Das sagt ja alleine gar nichts aus, wenn sowas wie z.B. ein Torrent Client dort läuft und daher ständig auf die SSD zugegriffen wird, hat deren Controller keine Zeit mal den Pseudo-SLC Schreibcache zu leeren, egal wie viele Stunden der pro Tag läuft. Hänge Dich nicht am Torrent Client auf, es ist nur ein Beispiel und es gibt zahlreiche andere Programme die dafür sorgen könnten, dass die SSD zu selten Idle ist. Da muss aber jeder in seinem eigenen System schauen was dies sein könnte.
Wo hast Du die abgelesen, im Resourcen Monitor oder bei HWInfo64? HWInfo64 zeigt per Default den Durchschnitt der letzten Sekunde an und wenn da länger 0 bei Lesen und Schreiben steht, dann ist sie wirklich Idle, während man wie gesagt im Resourcen Monitor noch die letzten Zugriffe sehen wird, weil der eben stark verzögert, sonst könnte man auch kurze Zugriffe gar nicht so schnell sehen und da schaut man ja vor allem welche Prozesse auf welche Dateien zugreifen. Daher würde ich für so eine Diagnose immer beide Tools zusammen nutzen, denn auch wenn wirklich nur ein paar kB/s übertragen werden, dies dafür aber dauerhaft, dann ist die SSD nicht Idle, dazu braucht es offenbar keine GBs.
Glauben heißt nicht Wissen, man sollte Probleme schon diagnostizieren.
Nicht unbedingt, vielleicht versucht die FW Auslegung der PM9A1 zusammen mit irgendwelchen Energiespareinstellung genau dies Problem. Samsung will es ja wohl bei der 980 Pro mit einem FW Update lösen, vielleicht sieht die Lösung einfach so aus, dass die SSD danach einfach bestimmte Energiesparzustände nicht mehr unterstützt und dann bräuchte man auch für die PM9A1 kein FW Update, wenn man diese einfach deaktiviert.
Gute Frage, ich kenne jedenfalls keines, im Zweifel hilt nur die Leistungsaufnahme zu messen um dies sicher ermitteln zu können, wozu man sich natürlich einen Adapter bauen müsste um diese auch wirklich ermitteln zu können. Aber gehe mal davon aus, dass alle Energiesparzustände die aktiv sind, dann auch genutzt werden wenn die Bedingungen dafür gegeben sind, also die SSD eine bestimmte Zeit Idle ist. Wie lange für welchen Energiesparzustand müsste eigentlich auch kofigurierbar sein.
github.com
Supported Power States
St Op Max Active Idle RL RT WL WT Ent_Lat Ex_Lat
0 + 8.37W - - 0 0 0 0 0 0
1 + 8.37W - - 1 1 1 1 0 200
2 + 8.37W - - 2 2 2 2 0 200
3 - 0.0500W - - 3 3 3 3 2000 1200
4 - 0.0050W - - 4 4 4 4 500 9500.\NVMeTool.exe 0g
2
y.\NVMeTool.exe 0
[I] Running on Windows 10 build 19042
[I] Getting controller identify data succeeded.
[M] SerialNumber (SN): XXXXXXXXXXX
[M] Model Number (MN): SAMSUNG MZVL22T0HBLB-00B00
[M] Firmware Revision (FR): GXB7301Q
[M] Version (VER): 0x00010300 (NVMe Revision 1.3.0)
[I] Getting controller's SMART / Health information log page succeeded.
# Input command:
# - r: Read data from LBA = 0
# - w: Write data to LBA = 0
# - d: Deallocate LBA = 0
# - l: Get Log Page
# - i: Identify
# - g: Get Feature
# - s: Set Feature
# - f: Flush
# - t: Device Self-test
# - z: Format NVM
# - v: Security Receive
#
# press 'q' to quit program
> g
# Input Feature Identifier (in hex):
# Supported Features are:
# 01h = Arbitration
# 02h = Power Management
# 03h = LBA Range Type
# 04h = Temperature Threshold
# 05h = Error Recovery
# 06h = Volatile Write Cache
# 07h = Number of Queues
# 08h = Interrupt Coalescing
# 0Ah = Write Atomicity Normal
# 0Bh = Asynchronous Event Configuration
# 0Ch = Autonomous Power State Transition
# 0Dh = Host Memory Buffer
# 0Eh = Timestamp
# 10h = Host Controlled Thermal Management
# 11h = Non-Operational Power State Config
# 80h = Software Progress Marker
> 2
# Get Feature : Power Management (Feature Identifier = 02h), Press 'y' to continue
> y
[I] Power Management:
bit [ 7: 5] Workload Hint (WH):
Current = 0 (no workload)
Default = 0 (no workload)
Saved = 0 (no workload)
bit [ 4: 0] Power State (PS)
Current = PS0
Default = PS0
Saved = PS0
Capabilities: this feature is
bit [ 2] 1 = changable
bit [ 1] 0 = for entire controller
bit [ 0] 0 = not savable
# Input command:
# - r: Read data from LBA = 0
# - w: Write data to LBA = 0
# - d: Deallocate LBA = 0
# - l: Get Log Page
# - i: Identify
# - g: Get Feature
# - s: Set Feature
# - f: Flush
# - t: Device Self-test
# - z: Format NVM
# - v: Security Receive
#
# press 'q' to quit program
>[I] Power Management:
bit [ 7: 5] Workload Hint (WH):
Current = 0 (no workload)
Default = 0 (no workload)
Saved = 0 (no workload)
bit [ 4: 0] Power State (PS)
Current = PS3
Default = PS0
Saved = PS0
Capabilities: this feature is
bit [ 2] 1 = changable
bit [ 1] 0 = for entire controller
bit [ 0] 0 = not savableHalt ob die Schreibrate der mit oder der ohne Pseudo-SLC Schreibcache entspricht. Natürlich wird letzteres der Fall sein, wenn man mehrfach direkt hintereinander bencht, aber nach einer gewissen Pause sollte dann wieder ersteres der Fall sein.
Also scheint es dann an der AM4 Plattform zu liegen und nicht generell an PCIe 4.0, was natürlich vermuten lässt, dass Samsung diese SSD auf Basis von Intel Samples auf Intel Plattformen entwickelt hat. Entweder hat AMD bei der Implementierung von PCIe 4.0 irgendwas anderes interpretiert und damit implementiert als Intel und Samsung, wie z.B. das per Default da mehr Energiesparfunktionen aktiviert sind. Gerade was die Lanes am X570 angeht, wäre dies ja auch logisch, da der X570 Chipsatz ja thermisch sowieso schon auf Kante genäht ist. Vielleicht sollten die Betroffenen mit X570 Boards mal schauen ob es einen Unterschied macht ob sie die SSD in einem Slot mit Lanes direkt von der CPU oder vom X570 betreiben.