Samsung 840/840 Evo - Leistungsprobleme & Fix - Forum - Page 13

that

Hoffnungsloser Optimist

Registered: Mar 2000
Location: MeidLing
Posts: 11326

08.03.2020 - 21:33

Zitat aus einem Post von that
Vielleicht will ja jemand mit einer 850 EVO oder 860 EVO (oder einer anderen SSD) die Tests in diesem Thread nachvollziehen und checken, ob eure SSD auch betroffen ist.

Updates: Ich hab testweise jetzt mal die ganze SSD gelesen:

Code:

root@ws ~ # dd if=/dev/sda of=/dev/null bs=2M
...
1000204886016 bytes (1,0 TB, 932 GiB) copied, 9321,18 s, 107 MB/s

Und nochmal:

Code:

root@ws ~ # dd if=/dev/sda of=/dev/null bs=2M
...
1000204886016 bytes (1,0 TB, 932 GiB) copied, 11880,4 s, 84,2 MB/s

Wird immer langsamer! :eek:

Also mal ein komplettes Image gezogen (selbstverständlich, ohne dass irgendwelche Filesysteme von der SSD gemountet waren):

Code:

root@ws ~ # dd if=/dev/sda of=/mnt/s1/sda.img bs=2M
...
1000204886016 bytes (1,0 TB, 932 GiB) copied, 13025,1 s, 76,8 MB/s

Noch langsamer. Aber wenigstens keine Lesefehler. Anschließend hab ich das Image wieder zurückkopiert, und jetzt geht es wieder so schnell wie es sollte:

Code:

root@ws ~ # dd if=/dev/sda of=/dev/null bs=2M
...
1000204886016 bytes (1,0 TB, 932 GiB) copied, 1805,23 s, 554 MB/s

COLOSSUS

Administrator
Frickler

Registered: Dec 2000
Location: ~
Posts: 11907

11.03.2020 - 21:18

Meine 850 EVO 1TB (OP auf 800GB, in einem Windows 10-Desktop) hat das Problem nicht laut AS SSD Benchmark.

that

Hoffnungsloser Optimist

Registered: Mar 2000
Location: MeidLing
Posts: 11326

11.03.2020 - 21:51

Zitat aus einem Post von COLOSSUS
Meine 850 EVO 1TB (OP auf 800GB, in einem Windows 10-Desktop) hat das Problem nicht laut AS SSD Benchmark.

Liest dieser Benchmark überhaupt alte Dateien oder nur seine eigene, die er gerade selbst geschrieben hat?

Viper780

Er ist tot, Jim!

Registered: Mar 2001
Location: Wien
Posts: 48943

11.03.2020 - 21:59

Zitat aus einem Post von COLOSSUS
Meine 850 EVO 1TB (OP auf 800GB, in einem Windows 10-Desktop) hat das Problem nicht laut AS SSD Benchmark.

Auf was für werte kommst du?

Bei mir:

Garbage

Administrator
The Wizard of Owls

Registered: Jul 2000
Location: GR.ch|TI.ch
Posts: 11225

12.03.2020 - 00:34

Zitat aus einem Post von that
Liest dieser Benchmark überhaupt alte Dateien oder nur seine eigene, die er gerade selbst geschrieben hat?

Nur die gerade erstellte Datei, somit für das Problem unbrauchbar.

Es gab damals ein Tool, das eben genau das Thema angesehen hat.

COLOSSUS

Administrator
Frickler

Registered: Dec 2000
Location: ~
Posts: 11907

12.03.2020 - 09:31

Ich kann den Datentraeger bzw. die Daten darauf "at rest" auch nochmal in Sequenz lesen lassen, aber ich habe im Alltag nicht das Gefuehl, dass da was lahmt.

@Viper: Sieht fuer mich so aus, als haettest du irgendeine Art von DRAM-Cache aktiviert, und die SSD selbst hat mit den ermittelten Zahlen wenig bis nichts zu tun.

Viper780

Er ist tot, Jim!

Registered: Mar 2001
Location: Wien
Posts: 48943

12.03.2020 - 10:23

Jetzt wo du es sagst - mal schauen was da aktiv ist.

erlgrey

formerly known as der~erl

Registered: Aug 2002
Location: Wien
Posts: 4368

12.03.2020 - 10:40

du hast vermutlich im samsung magican die ramdisk aktiviert.

Viper780

Er ist tot, Jim!

Registered: Mar 2001
Location: Wien
Posts: 48943

12.03.2020 - 10:54

vermute ich auch - erklärt warum der RAM immer mindestens halb voll ist

Viper780

Er ist tot, Jim!

Registered: Mar 2001
Location: Wien
Posts: 48943

13.03.2020 - 20:56

Ihr hattet natürlich recht
"Rapidmode" war im agican aktiviert

jetzt schauen die werte realistischer aus

that

Hoffnungsloser Optimist

Registered: Mar 2000
Location: MeidLing
Posts: 11326

13.03.2020 - 21:24

Zitat aus einem Post von Viper780
jetzt schauen die werte realistischer aus

Stimmt - sagt aber trotzdem nichts aus über das Problem, um das es in diesem Thread geht.

COLOSSUS

Administrator
Frickler

Registered: Dec 2000
Location: ~
Posts: 11907

25.04.2020 - 14:42

@that: Hab den versprochenen bzw. vermissten Test nachgeholt, da ich mal Ubuntu 20.04 in der Final sehen wollte:

Code:

root@ubuntu:~# uname -a
Linux ubuntu 5.4.0-26-generic #30-Ubuntu SMP Mon Apr 20 16:58:30 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
root@ubuntu:~# hdparm -i /dev/sda

/dev/sda:

 Model=Samsung SSD 850 EVO 1TB, FwRev=EMT03B6Q, SerialNo=XXX
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
 BuffType=unknown, BuffSize=unknown, MaxMultSect=1, MultSect=1
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=1677721600
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: unknown:  ATA/ATAPI-2,3,4,5,6,7

 * signifies the current active mode

root@ubuntu:~# smartctl -A /dev/sda
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.0-26-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, [url]www.smartmontools.org[/url]

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   098   098   000    Old_age   Always       -       7274
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       263
177 Wear_Leveling_Count     0x0013   099   099   000    Pre-fail  Always       -       19
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   100   100   010    Pre-fail  Always       -       0
181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       -       0
183 Runtime_Bad_Block       0x0013   100   100   010    Pre-fail  Always       -       0
187 Uncorrectable_Error_Cnt 0x0032   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0032   067   051   000    Old_age   Always       -       33
195 ECC_Error_Rate          0x001a   200   200   000    Old_age   Always       -       0
199 CRC_Error_Count         0x003e   100   100   000    Old_age   Always       -       0
235 POR_Recovery_Count      0x0012   099   099   000    Old_age   Always       -       5
241 Total_LBAs_Written      0x0032   099   099   000    Old_age   Always       -       33929545029


root@ubuntu:~# echo 3 > /proc/sys/vm/drop_caches; dd if=/dev/sda of=/dev/null bs=2M status=progress
858834075648 bytes (859 GB, 800 GiB) copied, 1561 s, 550 MB/s
409600+0 records in
409600+0 records out
858993459200 bytes (859 GB, 800 GiB) copied, 1562.75 s, 550 MB/s

Bei meinem Exemplar ist also kein Leistunseinbruch messbar.

Elbart

Here to stay

Registered: Dec 2002
Location: Hobbingen
Posts: 844

05.05.2020 - 10:44

Hat jemand von euch es je geschafft, eine 840 EVO (120GB) von Firmware EXT0CB6Q auf EXT0DB6Q aktualisiert zu bekommen?
Das Update auf die C-Version passierte damals mit dem "Performance Restoration"-Tool.

Ich habe die D-Firmware-Update-ISO in verscheidenen Rechnern (AMD, Intel), und auch in verschiedenen Art und Weisen (CD, USB-Stick mit FreeDOS etc.) getestet, aber immer gibt's irgendein Problem, dass der Firmware-Updater überhaupt nicht startet oder die Platte nicht als Ziel erkannt wird.

Oder geht das Update nur mit dem Magician (4.6)?

Als Workaround ginge, ein Image von der Platte zu ziehen und dann eine komplette Formatierung zu machen, aber dann kommt das Problem in 1, 2 Jahren sicher wieder.
Und die SSD ist jetzt schon komplett am Sand: https://i.imgur.com/5U7p9x1.png

So dauert das Kopieren den halben Tag.

InfiX

she/her

Registered: Mar 2002
Location: Graz
Posts: 13721

05.05.2020 - 11:49

hmm? ich hab noch EXT0DB6Q

das ist das update was iirc damals kam um das problem zu fixen sollt ich da was machen? ^^

e: ignore what I just said, im buchstaben verlesen

iirc hab ich das mit dem samsung magician eingespielt, ja.

that

Hoffnungsloser Optimist

Registered: Mar 2000
Location: MeidLing
Posts: 11326

05.05.2020 - 19:58

Zitat aus einem Post von COLOSSUS
@that: Hab den versprochenen bzw. vermissten Test nachgeholt

...
Code:
 Model=Samsung SSD 850 EVO 1TB, FwRev=EMT03B6Q, SerialNo=XXX
Bei meinem Exemplar ist also kein Leistunseinbruch messbar.

Danke fürs Testen! Meine Firmware ist EMT01B6Q, vielleicht macht das den Unterschied.

that Hoffnungsloser Optimist Registered: Mar 2000 Location: MeidLing Posts: 11326	08.03.2020 - 21:33 Zitat aus einem Post von that Vielleicht will ja jemand mit einer 850 EVO oder 860 EVO (oder einer anderen SSD) die Tests in diesem Thread nachvollziehen und checken, ob eure SSD auch betroffen ist. Updates: Ich hab testweise jetzt mal die ganze SSD gelesen: Code: `root@ws ~ # dd if=/dev/sda of=/dev/null bs=2M ... 1000204886016 bytes (1,0 TB, 932 GiB) copied, 9321,18 s, 107 MB/s` Und nochmal: Code: `root@ws ~ # dd if=/dev/sda of=/dev/null bs=2M ... 1000204886016 bytes (1,0 TB, 932 GiB) copied, 11880,4 s, 84,2 MB/s` Wird immer langsamer! Also mal ein komplettes Image gezogen (selbstverständlich, ohne dass irgendwelche Filesysteme von der SSD gemountet waren): Code: `root@ws ~ # dd if=/dev/sda of=/mnt/s1/sda.img bs=2M ... 1000204886016 bytes (1,0 TB, 932 GiB) copied, 13025,1 s, 76,8 MB/s` Noch langsamer. Aber wenigstens keine Lesefehler. Anschließend hab ich das Image wieder zurückkopiert, und jetzt geht es wieder so schnell wie es sollte: Code: `root@ws ~ # dd if=/dev/sda of=/dev/null bs=2M ... 1000204886016 bytes (1,0 TB, 932 GiB) copied, 1805,23 s, 554 MB/s`
COLOSSUS Administrator Frickler Registered: Dec 2000 Location: ~ Posts: 11907	11.03.2020 - 21:18 Meine 850 EVO 1TB (OP auf 800GB, in einem Windows 10-Desktop) hat das Problem nicht laut AS SSD Benchmark.
that Hoffnungsloser Optimist Registered: Mar 2000 Location: MeidLing Posts: 11326	11.03.2020 - 21:51 Zitat aus einem Post von COLOSSUS Meine 850 EVO 1TB (OP auf 800GB, in einem Windows 10-Desktop) hat das Problem nicht laut AS SSD Benchmark. Liest dieser Benchmark überhaupt alte Dateien oder nur seine eigene, die er gerade selbst geschrieben hat?
Viper780 Er ist tot, Jim! Registered: Mar 2001 Location: Wien Posts: 48943	11.03.2020 - 21:59 Zitat aus einem Post von COLOSSUS Meine 850 EVO 1TB (OP auf 800GB, in einem Windows 10-Desktop) hat das Problem nicht laut AS SSD Benchmark. Auf was für werte kommst du? Bei mir:
Garbage Administrator The Wizard of Owls Registered: Jul 2000 Location: GR.ch\|TI.ch Posts: 11225	12.03.2020 - 00:34 Zitat aus einem Post von that Liest dieser Benchmark überhaupt alte Dateien oder nur seine eigene, die er gerade selbst geschrieben hat? Nur die gerade erstellte Datei, somit für das Problem unbrauchbar. Es gab damals ein Tool, das eben genau das Thema angesehen hat.
COLOSSUS Administrator Frickler Registered: Dec 2000 Location: ~ Posts: 11907	12.03.2020 - 09:31 Ich kann den Datentraeger bzw. die Daten darauf "at rest" auch nochmal in Sequenz lesen lassen, aber ich habe im Alltag nicht das Gefuehl, dass da was lahmt. @Viper: Sieht fuer mich so aus, als haettest du irgendeine Art von DRAM-Cache aktiviert, und die SSD selbst hat mit den ermittelten Zahlen wenig bis nichts zu tun.
Viper780 Er ist tot, Jim! Registered: Mar 2001 Location: Wien Posts: 48943	12.03.2020 - 10:23 Jetzt wo du es sagst - mal schauen was da aktiv ist.
erlgrey formerly known as der~erl Registered: Aug 2002 Location: Wien Posts: 4368	12.03.2020 - 10:40 du hast vermutlich im samsung magican die ramdisk aktiviert.
Viper780 Er ist tot, Jim! Registered: Mar 2001 Location: Wien Posts: 48943	12.03.2020 - 10:54 vermute ich auch - erklärt warum der RAM immer mindestens halb voll ist
Viper780 Er ist tot, Jim! Registered: Mar 2001 Location: Wien Posts: 48943	13.03.2020 - 20:56 Ihr hattet natürlich recht "Rapidmode" war im agican aktiviert jetzt schauen die werte realistischer aus
that Hoffnungsloser Optimist Registered: Mar 2000 Location: MeidLing Posts: 11326	13.03.2020 - 21:24 Zitat aus einem Post von Viper780 jetzt schauen die werte realistischer aus Stimmt - sagt aber trotzdem nichts aus über das Problem, um das es in diesem Thread geht.
COLOSSUS Administrator Frickler Registered: Dec 2000 Location: ~ Posts: 11907	25.04.2020 - 14:42 @that: Hab den versprochenen bzw. vermissten Test nachgeholt, da ich mal Ubuntu 20.04 in der Final sehen wollte: Code: root@ubuntu:~# uname -a Linux ubuntu 5.4.0-26-generic #30-Ubuntu SMP Mon Apr 20 16:58:30 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux root@ubuntu:~# hdparm -i /dev/sda /dev/sda: Model=Samsung SSD 850 EVO 1TB, FwRev=EMT03B6Q, SerialNo=XXX Config={ Fixed } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0 BuffType=unknown, BuffSize=unknown, MaxMultSect=1, MultSect=1 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=1677721600 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 udma6 AdvancedPM=no WriteCache=enabled Drive conforms to: unknown: ATA/ATAPI-2,3,4,5,6,7 signifies the current active mode root@ubuntu:~# smartctl -A /dev/sda smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.0-26-generic] (local build) Copyright (C) 2002-19, Bruce Allen, Christian Franke, [url]www.smartmontools.org[/url] === START OF READ SMART DATA SECTION === SMART Attributes Data Structure revision number: 1 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 9 Power_On_Hours 0x0032 098 098 000 Old_age Always - 7274 12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 263 177 Wear_Leveling_Count 0x0013 099 099 000 Pre-fail Always - 19 179 Used_Rsvd_Blk_Cnt_Tot 0x0013 100 100 010 Pre-fail Always - 0 181 Program_Fail_Cnt_Total 0x0032 100 100 010 Old_age Always - 0 182 Erase_Fail_Count_Total 0x0032 100 100 010 Old_age Always - 0 183 Runtime_Bad_Block 0x0013 100 100 010 Pre-fail Always - 0 187 Uncorrectable_Error_Cnt 0x0032 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0032 067 051 000 Old_age Always - 33 195 ECC_Error_Rate 0x001a 200 200 000 Old_age Always - 0 199 CRC_Error_Count 0x003e 100 100 000 Old_age Always - 0 235 POR_Recovery_Count 0x0012 099 099 000 Old_age Always - 5 241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always - 33929545029 root@ubuntu:~# echo 3 > /proc/sys/vm/drop_caches; dd if=/dev/sda of=/dev/null bs=2M status=progress 858834075648 bytes (859 GB, 800 GiB) copied, 1561 s, 550 MB/s 409600+0 records in 409600+0 records out 858993459200 bytes (859 GB, 800 GiB) copied, 1562.75 s, 550 MB/s Bei meinem Exemplar ist also kein Leistunseinbruch messbar.
Elbart Here to stay Registered: Dec 2002 Location: Hobbingen Posts: 844	05.05.2020 - 10:44 Hat jemand von euch es je geschafft, eine 840 EVO (120GB) von Firmware EXT0CB6Q auf EXT0DB6Q aktualisiert zu bekommen? Das Update auf die C-Version passierte damals mit dem "Performance Restoration"-Tool. Ich habe die D-Firmware-Update-ISO in verscheidenen Rechnern (AMD, Intel), und auch in verschiedenen Art und Weisen (CD, USB-Stick mit FreeDOS etc.) getestet, aber immer gibt's irgendein Problem, dass der Firmware-Updater überhaupt nicht startet oder die Platte nicht als Ziel erkannt wird. Oder geht das Update nur mit dem Magician (4.6)? Als Workaround ginge, ein Image von der Platte zu ziehen und dann eine komplette Formatierung zu machen, aber dann kommt das Problem in 1, 2 Jahren sicher wieder. Und die SSD ist jetzt schon komplett am Sand: https://i.imgur.com/5U7p9x1.png So dauert das Kopieren den halben Tag.
InfiX she/her Registered: Mar 2002 Location: Graz Posts: 13721	05.05.2020 - 11:49 hmm? ich hab noch EXT0DB6Q das ist das update was iirc damals kam um das problem zu fixen sollt ich da was machen? ^^ e: ignore what I just said, im buchstaben verlesen iirc hab ich das mit dem samsung magician eingespielt, ja.
that Hoffnungsloser Optimist Registered: Mar 2000 Location: MeidLing Posts: 11326	05.05.2020 - 19:58 Zitat aus einem Post von COLOSSUS @that: Hab den versprochenen bzw. vermissten Test nachgeholt ... Code: `Model=Samsung SSD 850 EVO 1TB, FwRev=EMT03B6Q, SerialNo=XXX` Bei meinem Exemplar ist also kein Leistunseinbruch messbar. Danke fürs Testen! Meine Firmware ist EMT01B6Q, vielleicht macht das den Unterschied.

Samsung 840/840 Evo - Leistungsprobleme & Fix

Forum Index > Hardware > Komponenten > Storage & Memory

that

COLOSSUS

that

Viper780

Garbage

COLOSSUS

Viper780

erlgrey

Viper780

Viper780

that

COLOSSUS

Elbart

InfiX

that