840 Evo extrem langsam beim Entpacken?

[nighteeeeey]

Ich entpacke gerade eine ~35Gb große Rar Datei mit einer Mkv (alles legal).

Das passiert auf einer 840 Evo 1TB. Die noch 200Gb frei hat.

Angefangen hab ich bei 250Mb/s, konstant bis ca. 30%. Dann brach die Entpackungsrate rapide ein erst auf 90Mb und dann immer weiter. Bin jetzt bei 65Mb/s bei 82% angekommen.

Entpacke mit 7z und der Prozess benötigt nichtmal 1% CPU Auslastung (4960x).

Ist das alles normal? Warum wird die CPU nicht ausgelastet? Sollte das so sein? Warum ist die Festplatte so langsam? Ist das kein "sequenzieller" Vorgang der schneller gehen sollte? Liegts am DRAM Cache der SSD?

Ist irgendwie n bisschen belastend.

Ich bin Fotograf und Filmer und habe oft mit großen Mkvs zu tun die ich gepackt bekomme zum bearbeiten. Mein Mainlaufwerk was auch als Scrapdisk für Premiere eingesetzt wird ist ne 960 Pro Nvme. Würde das auch zum Entpacken größerer Rar Archive mit einer großen Datei helfen, die da zu entpacken? Anstatt auf größeren SSDs, die aber langsamer und/oder nicht Nvme sind?

Bitte um Rat!

Vielen Dank

 

[BFF]

Hi,

Entpacken von Archiven auf ein und dem selben Datentraeger dauert halt etwas. 35 GB plus 35 GB temporaerer Krams beim Entpacken sollen/wollen auch geschrieben werden.

Was helfen kann in Sachen Geschwindigkeit ist, wenn Du/Ihr 7z anstatt RAR als Archiv verwende(s)t.
Und wenn die Archive nicht am Stueck aufschlagen sondern Split-Archive sind.
Ah ja. Der Antivirensoftware beibringen, dass sie diese Archive bzw. die Ordner mit diesen Archiven nicht scant.

Welche Festplatte meinst Du? Du hast doch eigentlich nur SSD.

BFF

 

[Killer1980]

Wie alt war das rar Archiv und ist die Firmware Ader 840er auf den aktuellen Stand?

Ergänzung (1. November 2018)

Das Problem gab es damals.
https://www.golem.de/news/trotz-update-samsungs-ssd-840-evo-wird-wieder-langsamer-1501-111997.html
Inzwischen soll es aber mit neuer Firmware gelöst worden sein.

 

[Baal Netbeck]

Die 840 ist doch TLC Speicher mit SLC fake Speicherbuffer oder täusche ich mich?
Da wird also erstmal eine Weile in SLC Schreibweise geschrieben, aber irgendwann muss das umgeschrieben werden. Dann brechen deine Datenraten ziemlich ein.

Ergänzung (1. November 2018)

Für so extreme Anwendungsgebiete, empfehlen sich die pro SSDs mit MLC Speicher und zusätzlich das entpacken von einer SSD auf eine zweite.

 

[xxMuahdibxx]

normal wenn gleichzeitig gelesen und geschrieben werden muss ...

 

[Freud445]

Servus Nighteeeeey,

es gibt da ein sehr nützliches Tool von Samsung, selbst zu kontrolle ob eine Festplatte/SSD/MVne funktioniert. Es heißt "Samsung Magician" Es hat mehrere Funktionien wie z.b. Eine Selbstkontrolle sowie Treiber updates. Probier es mal und schau ob dein Problem da mit behoben wird

 

[Martin.H]

Die schnellste Option wird sein, von einer SSD auf eine zweite zu entpacken (siehe Baal Netbeck' Post).
Ggfs ist das sogar dann noch schneller, wenn man es danach wieder zurück auf die erste kopiert.

 

[TNM]

840 Evo, das war doch das Teil mit dem Performance Bug?
Aktualisierungen durchgeführt? Wenn nein: Samsung Magician installieren, Firmware aktualisieren.

 

[Holt]

Das Problem gab es damals.
https://www.golem.de/news/trotz-update-samsungs-ssd-840-evo-wird-wieder-langsamer-1501-111997.html
Inzwischen soll es aber mit neuer Firmware gelöst worden sein.

Es ist schon lange mit der neusten FW behoben und betrifft auch nur Daten die schon lange auf der SSD stehen, was hier wohl kaum der Fall sein dürfte wenn man liest: "bin Fotograf und Filmer und habe oft mit großen Mkvs zu tun die ich gepackt bekomme zum bearbeiten." Die Aufträge werden ja wohl kaum erst Monate nach dem Erhalt der Daten bearbeitet werden und nur übers Wochenende die Daten stehen zu lassen, reicht nicht aus um den Effekt des Bugs zu triggern.

Die 840 ist doch TLC Speicher mit SLC fake Speicherbuffer oder täusche ich mich?

Die hat einen Pseudo-SLC Schreibcache, wie praktisch jede SSD mit TLC NAND. Dieser bei Samsung TurboWrite genannte Schreibcache ist bei der 840 Evo 1TB 12GB groß, aber dies erklärt den Abfall nach etwa 30% der 35GB großen Datei nur zum Teil. Denn die 840 Evo 1TB sollte auch bei vollem Pseudo-SLC Schreibcache noch mit bis zu 420MB/s schreiben, zumindest bei langen sequentiellen Zugriffen, wenn vorher genug Platz frei war und die getrimmt wurde (mit TrimCheck prüfen).

Allerdings sind SSDs mit NAND bei gleichzeitigen Lese- und Schreibzugriffen deutlich langsamer als wenn nur gelesen oder nur geschrieben wird (die Intel Optanes sind da eine Ausnahme) und erst recht wenn sie ein SATA Interface haben, denn anders als PCIe ist SATA eben nicht vollduplex. Wie stark der Effekt ist, hängt natürlich vom jeweiligen Modell ab, aber eine 840 Evo dürfte da als ältere SATA SSD mit TLC NANDs schon deutlich schlechter als eine deutlich aktuellere 960 Pro PCIe SSD mit MLC NAND abschneiden.

Das die CPU Auslastung des Prozesses so gering ist, deutet darauf hin das das Archiv nicht komprimiert ist, was bei solchen Mediendateien auch Sinn macht, da sich diese nicht mehr weiter verlustfrei komprimieren lassen. Es ist dann also auch normal und ggf. bremst dann allenfalls ein anderer Prozess wie der Virenfinder, aber eigentlich sollte der bei mkv Dateien auch nicht aktiv werden, aber es kann nicht schaden sich die CPU Last des Prozesses mal anzusehen. Beachte aber das diese meist nur einen Thread (pro Datei) benutzen und bei einer CPU mit 6 Kernen und 12 Threads kann ein Thread im Task Manager maximal 100%/12 = 8% CPU Last erzeugen. Die Singlethreadperformance ist eben immer noch sehr wichtig und vielen Usern fällt dies beim Blick auf die CPU Last im Takt Manager eben leider gar nicht auf.