SSD über SATA sau lahm

[bLu3to0th]

Hi,

Ich habe das Problem (aufgefallen durch das Spiel Crossout, dass ich auf dem Screenshot gerade nach C: verschiebe), dass meine zweite SSD saulahm ist. Das liegt aber nicht an der SSD selbst, sondern muss irgendwie an Windoof (10) liegen.
Ich habe gerade ein Hardwareupgrade hinter mir (von nem i5 Sandy aufn Ryzen 2600).

Im alten System war die angesprochene SSD, die Systemplatte und war den Spezis entsprechend schnell.

Im neuen System habe ich jetzt eine NVMe SSD als Sys und die Alte als Spiele-SSD.

Ich habe aber das Problem, dass die zweite SSD im System, die nicht die SystemSSD ist, andauernd gurken lahm ist.
Das war im Altsystem so und ist auch jetzt wieder so, dabei war es jedes Mal eine andere Zweit-SSD, auch Ports und Sata-Kabel wurden sowohl im Altsystem als auch im Aktuellen bereits getauscht.

Das hat sich dahingehend bemerkbar gemacht, dass ich im Spiel die ersten 10-15min immer massive Ladezeiten(schlechter als mit ner HDD) habe. Danach hat es sich entweder eingependelt oder es ist genug im RAM - das weiß ich gerade nicht.

Aber hier muss definitiv irgendein Problem mit Win10 bestehen, denn ansonsten laufen die SSDs alle einwandfrei.

Kopiervorgang von der Zweit-SSD(Adata SU650) auf die System-SSD(960 Evo Plus)

Auch Laufwerksoptimierung, Treiber etc schon auf Vordermann gebracht.

Der Witz ist: Wenn ich die Kabel/Ports tauschen... rennt die Zweit-SSD für ein bis zwei Tage wieder tadellos und dann gurkt sie wieder rum.

Hat einer noch ne Idee?

 

[AudioholicA]

Was sagt Chrystal Disk Info zum Zustand der SSD? Über welchen Controller läuft die SSD? Welches Mainboard?
Chipsatztreiber installiert? Soo viele Fragen...

 

[Whatafall]

ist Trim aktiv ?? Kannst du mit CrystalDiskInfo auslesen

 

[bLu3to0th]

Es liegt nicht an der Platte...
Wenn man die umsteckt dann gehts ja für'n Tag oder so

 

[Whatafall]

Ergänzung (28. September 2019)

Ich habe aber das Problem, dass die zweite SSD im System, die nicht die SystemSSD ist, andauernd gurken lahm ist.
Das war im Altsystem so und ist auch jetzt wieder so, dabei war es jedes Mal eine andere Zweit-SSD, auch Ports und Sata-Kabel wurden sowohl im Altsystem als auch im Aktuellen bereits getauscht.

Sry aber verstehe den Text nicht so richtig ! Hast du das Problem bei mehreren SSD´s gehabt oder war/ist es immer die gleiche SSD und wie viele SSD´s sind verbaut ? Welches Mainboard hast du ? AHCI aktiv ?

 

[Holt]

ist Trim aktiv ??

Der Kopiervorgang geht doch von der AData auf die Samsung 960 Evo (eine Evo Plus gibt es nur bei der 970) und damit eine NVMe SSD, bei denen ist TRIM immer aktiv, denn NVMe ist neuer als TRIM:

Kopiervorgang von der Zweit-SSD(Adata SU650) auf die System-SSD(960 Evo Plus)

Das Problem dürfte einfach die AData sein, die hat laut diesem Review einen DRAM less Controller von Maxiotek, die der Nachfolger von JMicron sind, genauer "JMicron spun off their SSD controller business into Maxiotek". Die SSD Controller von JMicron waren immer Grütze und saulahm, DRAM less Controller sind spätestens bei anspruchsvolleren Workload ebenfalls lahm und beides kombiniert dürfte die Folgen haben die Du nun siehst. Zumal die SU650 auch noch QLC NAND hat und bei QLC ist nicht nur die Schreib- sondern auch die Leseperformance im QLC Bereich geringer: Bei 4k QD1 Lesend sind es bei der 860 QVO nur 4.400 IOPS statt 7.500 aus dem Pseudo-SLC Bereich, QD32 werden im QLC sogar weniger als halb so viele IOPS lesend wie aus dem Pseudo-SLC erzielt.

PS: Schau Dir mal hier im Preview eines Maxiotek SSD Controllers bei Anandtech die Performance Consistency an, die ist unterirdisch, selbst mit MLC liegt der noch weit hinter anderen mit TLC.

 

[bLu3to0th]

Ergänzung (28. September 2019)

Sry aber verstehe den Text nicht so richtig ! Hast du das Problem bei mehreren SSD´s gehabt oder war/ist es immer die gleiche SSD und wie viele SSD´s sind verbaut ? Welches Mainboard hast du ? AHCI aktiv ?

Das Problem habe ich jetzt schon mit zwei verschiedenen SSDs nachstellen können.. davor war die Adata System und eine 840evo die Spiele-SSD.. da hat die 840er dasselbe Problem gehabt..
Dann gabs n Hardwareupgrade bei dem die Adata zur Spiele-SSD wurde und eine 860er zur System.. selbes Problem nun mit der ADATA.

Der Kopiervorgang geht doch von der AData auf die Samsung 960 Evo (eine Evo Plus gibt es nur bei der 970) und damit eine NVMe SSD, bei denen ist TRIM immer aktiv, denn NVMe ist neuer als TRIM:
Das Problem dürfte einfach die AData sein, die hat laut diesem Review einen DRAM less Controller von Maxiotek, die der Nachfolger von JMicron sind, genauer "JMicron spun off their SSD controller business into Maxiotek". Die SSD Controller von JMicron waren immer Grütze und saulahm, DRAM less Controller sind spätestens bei anspruchsvolleren Workload ebenfalls lahm und beides kombiniert dürfte die Folgen haben die Du nun siehst. Zumal die SU650 auch noch QLC NAND hat und bei QLC ist nicht nur die Schreib- sondern auch die Leseperformance im QLC Bereich geringer: Bei 4k QD1 Lesend sind es bei der 860 QVO nur 4.400 IOPS statt 7.500 aus dem Pseudo-SLC Bereich, QD32 werden im QLC sogar weniger als halb so viele IOPS lesend wie aus dem Pseudo-SLC erzielt.

PS: Schau Dir mal hier im Preview eines Maxiotek SSD Controllers bei Anandtech die Performance Consistency an, die ist unterirdisch, selbst mit MLC liegt der noch weit hinter anderen mit TLC.

Wie gesagt, das Problem besteht immer nur dann, wenn es nicht die System-SSD ist und 5MB/s mit ner SSD, die sonst nichts anderes zu tun hat? Defintiv: Nein.

 

[Holt]

Du hast ja scheinbar noch zwei weitere Laufwerke im Rechner, poste doch mal die Screenshots von CrystalDiskInfo für die beiden.

Benche auch mal die Lesegeschwindigkeit der bestehenden Daten der AData mit dem File Bench Tool von Blublah (Quelle). Möglicherweise warnt der Virenfinder, immerhin macht das Tool ja ordentlich Zugriffe auf die Platte, mir wäre nicht bekannt das es Schadsoftware wäre, aber auf eigenes Risiko und im Zweifel finden sich sicher auch andere Tools die die reale Lesegeschwindigkeit existierender Daten benchen. Die üblichen SSD Benchmarks wie ATTO, AS-SSD oder CrystalDiskMark benchen ja nur die Performance frischer Dateien, oft auch nur des Pseudo-SLC Caches, da sie die Dateien ja schreiben und dann sofort wieder einlesen.

 

[bLu3to0th]

Geliefert wie bestellt:

 

[Holt]

Die Werte der anderen beiden Platte sind in Ordnung, ich hatte den Verdacht das es dort ggf. ein Problem mit dem SATA Datenkabel geben könnte, manchmal beeinträchtigt dies auch andere Laufwerk am gleichen SATA Host Controller, aber dies ist nicht der Fall.

Mit dem Ergebnis von Filebench dürfte aber klar sein wieso das Kopieren so langsam ist, mein Verdacht die Quelle wäre einfach zu langsam hat sich damit bestätigt. Wie saht der Screen aus nachdem Du da OK gedrückt hast? Da sieht man welchen Zusammenhang es zwischen der Lesegeschwindigkeit und dem Datum der Dateien gibt.

Wenn es nicht an der AData selbst liegt, so könnte es ggf. auch am Virenfinder liegen, einige sind ganz schöne Bremsen.