Samsung EVO SSD eigenaars

[1337LutZ]

Ik heb op Overclock.net deze topic gevonden.

http://www.overclock.net/...written-data-in-the-drive

De vraag is: Hebben jullie hier ook last van?

Na het defragmenteren was mijn performance weer overal gelijk.

Voor:


Na:


Kunnen jullie je resultaten delen?

EDIT

Mocht je dit willen testen. Dan kan je om een goede vergelijking te maken het beste FileBench runnen op je SSD om zo het voor en na te vergelijken.

[ Voor 17% gewijzigd door 1337LutZ op 07-09-2014 18:30 ]

[ShitHappens]

Voor:

Na:

Moet er wel bij zeggen, dat deze er nog niet eens een maand in zit en maar voor een kwart vol staat.

[ Voor 8% gewijzigd door ShitHappens op 07-09-2014 17:35 ]

[1337LutZ]

ShitHappens schreef op zondag 07 september 2014 @ 17:34:
Voor:
[afbeelding]
Na:
[afbeelding]
Moet er wel bij zeggen, dat deze er nog niet eens een maand in zit en maar voor een kwart vol staat.

Is dit na een volledige defrag (niet optimize) van defraggler? Het kan idd zo zijn dat de hoeveelheid data en duur uitmaakt. Bij mij scheeld het echt veel.

Ik zie alsnog een dikke performance drop die daar niet hoort te zijn.

Heb je btw samsung magician geinstalleerd en de OS optimalisatie gerunned en firmware gechecked?

[ Voor 13% gewijzigd door 1337LutZ op 07-09-2014 17:39 ]

[thorgal21]

Verkeerde gevens :3 Mn EVO zit in mijn laptop. Ik ga die even benchmarken!

[ Voor 111% gewijzigd door thorgal21 op 07-09-2014 17:45 ]

[1337LutZ]

Thorgal jij hebt dan weer redelijk normale resultaten. Hoewel ik niet weet hoe de 120gb versie moet presteren.

Alleen bij jou zit de access time echt all over the place. Als je bij onze twee screenshots kijkt zie je dat het bijna niet verspringt.

Heb je de PRO of EVO? Want ik zie het er niet bij staan bij jou.

[ Voor 12% gewijzigd door 1337LutZ op 07-09-2014 17:43 ]

[Timons106]

[thorgal21]

1337LutZ schreef op zondag 07 september 2014 @ 17:42:
Thorgal jij hebt dan weer redelijk normale resultaten. Hoewel ik niet weet hoe de 120gb versie moet presteren.

Alleen bij jou zit de access time echt all over the place. Als je bij onze twee screenshots kijkt zie je dat het bijna niet verspringt.

Heb je de PRO of EVO? Want ik zie het er niet bij staan bij jou.

Foutje van mij :3 Ik dacht dat in mijn desktop ook een EVO zat. Ik benchmark even mijn laptop waar een 120GB EVO in zit. momentje!

[sphere]

Timons heeft zo te zien 0GB overprovisioning. Misschien maakt dat nog uit?

[1337LutZ]

Timons106 schreef op zondag 07 september 2014 @ 17:45:
[afbeelding]

Jouw resultaten zijn ook echt all over the place. Zou jij ook een defrag willen runnen en kijken of het helpt?

thorgal21 schreef op zondag 07 september 2014 @ 17:46:
[...]


Foutje van mij :3 Ik dacht dat in mijn desktop ook een EVO zat. Ik benchmark even mijn laptop waar een 120GB EVO in zit. momentje!

Ja ik dacht al.

[thorgal21]

1337LutZ schreef op zondag 07 september 2014 @ 17:49:
[...]


Jouw resultaten zijn ook echt all over the place. Zou jij ook een defrag willen runnen en kijken of het helpt?


[...]


Ja ik dacht al.

Hier de goede!:

[1337LutZ]

thorgal21 schreef op zondag 07 september 2014 @ 17:50:
[...]


Hier de goede!:

[afbeelding]

Yea thats more like it. Zou jij ook een defrag kunnen runnen?

[ShitHappens]

1337LutZ schreef op zondag 07 september 2014 @ 17:36:
[...]


Is dit na een volledige defrag (niet optimize) van defraggler? Het kan idd zo zijn dat de hoeveelheid data en duur uitmaakt. Bij mij scheeld het echt veel.

Ik zie alsnog een dikke performance drop die daar niet hoort te zijn.

Heb je btw samsung magician geinstalleerd en de OS optimalisatie gerunned en firmware gechecked?

Samsung Magician staat erop ja, OS optimalisatie gedaan, firmware ok.
Alleen defraggler niet gerund, ga dat nu even doen.

[1337LutZ]

ShitHappens schreef op zondag 07 september 2014 @ 17:52:
[...]

Samsung Magician staat erop ja, OS optimalisatie gedaan, firmware ok.
Alleen defraggler niet gerund, ga dat nu even doen.

Ben benieuwd!

[Timons106]

1337LutZ schreef op zondag 07 september 2014 @ 17:49:
[...]


Jouw resultaten zijn ook echt all over the place. Zou jij ook een defrag willen runnen en kijken of het helpt?


[...]


Ja ik dacht al.

Ik zou zweren dat ik overprovisioning aan had gezet!

Duurt zo'n defrag lang? Ik was namelijk van plan volgende week m'n laptop te formatteren.

[Reepje]

Op een ssd mag je nooit een defrag doen. Je kan daarom daar beter niet toe oproepen.

[Zalmanman]

Heeft defraggen wel nut?

http://www.ghacks.net/200...uld-you-defragment-a-ssd/

Solid State Drives can access any location on the drive in the same time. This is one of the main advantages over hard drives. This also means that there is no need to defragment a Solid State Drive ever. These drives have actually been designed to write data evenly in all sectors of the drive which the industry is calling wear levelling. Each sector of a Solid State Drive has a limited number of writes before it cannot be overwritten any more. (this is a theoretical limit which cannot be reached in work environments)
If you did defragment your Solid State Disk you can rest assured that you did not harm it in any way. It is just that this process is not needed and that defragmentation causes lots of write processes which means that the drive will reach its write limits sooner.
No need for defragmentation is therefore another advantage of Solid State Drives.

Verder las ik ook dit:

The short answer to your question is that SSDs should not be defragmented. As you noted, the method of data storage differs from that of traditional HDDs. The HDD uses physical movement of the head to access various sectors of the disk, and thus data needs to be arranged in a sequential manner to avoid latency because of unnecessary movement. Defragmenting is a method of achieving a sequential arrangement, it prevents data from being physically scattered all over the HDD, and therefore minimizes latency. SSDs do not operate in this fashion, and the SSD controller distributes data all over the drive. There is no need to treat a SSD in the same way as a HDD, and defragmenting is completely unnecessary.

Bron: http://www.itworld.com/an...ould-ssds-be-defragmented

Edit: Reepje was eerder. Mêh.

[thorgal21]

Ik had idd ook ergens gelezen dat het minder goed is voor je laptop :l

[1337LutZ]

Reepje schreef op zondag 07 september 2014 @ 17:53:
Op een ssd mag je nooit een defrag doen. Je kan daarom daar beter niet toe oproepen.

Omdat je lifespan door het bewegen van data verminderd, maar een SSD gaat makkelijk 10 jaar mee onder normale omstandigheden dus eenmalig defragmenteren lijkt mij geen probleem.


Als het defraggen niet uit maakt, hoezo zijn mijn leestijden dan drastisch verbeterd?

Edit: Ik vraag ook alleen om een eenmalige defrag. Dat gaat niet de SSD magisch kapot maken gelukkig.

[ Voor 10% gewijzigd door 1337LutZ op 07-09-2014 17:57 ]

[Reepje]

De manier van data opslag is helemaal anders op een ssd dan op een hdd. Het is daarom niet optimaal voor je filesystem (ook weer niet catastrofaal, maar toch). Over de levensduur hoef je echt niet druk te maken, je kan wat mij betreft elke week een keer defraggen, maakt voor de levensduur misschien 1 maand uit (dus geen 55 jaar en 4 maanden, maar slechts 55 jaar en 3 maanden).

Wat je wel krijgt dat dat programma HD (van hard disk) tune en mooier blauw lijntje laat zien.

[1337LutZ]

Van OCN.

This could be different things happening with defrag , the fragments are removed and it moves files around so files are rewritten and become new files . Is the speed picking up again because the file is rewritten or is it because it is to much fragmented . On a not regular basis i defrag my ssd when needed with windows defrag , the effect can be very good when combining of free space is used .
On NTFS level i think it is to big of impact for ssd and old files do not fragment automatic , it starts with writing fragmented to ssd or the file could be re-saved and starts to fragment . And it is not easy to get fragmented files on a fast ssd , the evo is fast but maby the TLC could be giving problems when data remains longer on ssd .

Ik denk dat deze reactie van waarde kan zijn. Het kan zijn dat TLC geheugen na langere tijd sneller fragmenteerd en daarom de waardes drastisch achteruit gaan.

Bij het defragmenteren worden bestanden weer 1 fragment en herschreven naar een "sector" waardoor de performance weer stijgt.

Reepje schreef op zondag 07 september 2014 @ 17:58:
De manier van data opslag is helemaal anders op een ssd dan op een hdd. Het is daarom niet optimaal voor je filesystem (ook weer niet catastrofaal, maar toch). Over de levensduur hoef je echt niet druk te maken, je kan wat mij betreft elke week een keer defraggen, maakt voor de levensduur misschien 1 maand uit (dus geen 55 jaar en 4 maanden, maar slechts 55 jaar en 3 maanden).

Wat je wel krijgt dat dat programma HD (van hard disk) tune en mooier blauw lijntje laat zien.

Dus het performance verlies is een illusie? de OP van Overclock.net geeft namelijk bij een bestandsbenchmark van de SSD daadwerkelijk betere lees/schrijfwaardes aan. (Het lezen van bestanden die op de SSD zitten, niet een standaard temp. file test)

[ Voor 28% gewijzigd door 1337LutZ op 07-09-2014 18:03 ]

[wesleytjuh]

Bij deze mijn resultaten:

Ongeveer 2/3 van de schijf in gebruik.

[ Voor 17% gewijzigd door wesleytjuh op 07-09-2014 18:07 ]

[1337LutZ]

wesleytjuh schreef op zondag 07 september 2014 @ 18:06:
Bij deze mijn resultaten:
[afbeelding]
Ongeveer 2/3 van de schijf in gebruik.

Yea zelfde dus.

zou je filebench kunnen runnen op je SSD (Program files 86 map bijv.) om te kijken wat je lees/schrijftijden zijn en dan een defrag runnen om te kijken of de snelheid weer normaal is?

Kan je hier vinden: http://www.overclock.net/...he-drive/50#post_22807216

[ Voor 12% gewijzigd door 1337LutZ op 07-09-2014 18:10 ]

[Reepje]

Helaas een topic dat tot een absoluut dieptepunt op tweakers gerekend kan worden.

Wat je ook kan doen: stop de ssd in een wasmachine en meet de vibratie van het ding tijdens centrifugeren. Zet de vibratiewaarde dan uit tegen de decibels die de machine produceert en deel dat door het stroomverbruik. Misschien komt er nog wat leuks uit!

[1337LutZ]

Reepje schreef op zondag 07 september 2014 @ 18:13:
Helaas een topic dat tot een absoluut dieptepunt op tweakers gerekend kan worden.

Wat je ook kan doen: stop de ssd in een wasmachine en meet de vibratie van het ding tijdens centrifugeren. Zet de vibratiewaarde dan uit tegen de decibels die de machine produceert en deel dat door het stroomverbruik. Misschien komt er nog wat leuks uit!

Hoezo is het een dieptepunt? Na de defragmentatie zijn duidelijke verbeteringen in de resultaten te zien. Dus wat is het probleem?

Ook is het apart om te zien dat het niet bij de PRO voorkomt (MLC) maar alleen bij de EVO (TLC).

EDIT: ik dacht dat het Tweakers was. Het verbeteren van performance en er achter komen waarom iets zo is zou toch juist gewild zijn hier?

[ Voor 16% gewijzigd door 1337LutZ op 07-09-2014 18:18 ]

[wesleytjuh]

Maar is het verschil na defrag ook merkbaar? Dus niet enkel zichtbaar in een benchmark maar ook merkbaar tijdens het laden van een spel, of het starten van Windows?

[Reepje]

Ik zie niets? Voor wat betreft HDtune, dit is te gebruiken voor ssd's in zoverre je naar de gele lijn kijkt. Ik zie daar geen rare veranderingen.

Voor verbetering van de resultaten, welke resultaten? Er telt maar 1 ding voor de ssd. En dat is snelheid.
Een manier om dat te bekijken is as-ssd benchmark.

[1337LutZ]

Reepje schreef op zondag 07 september 2014 @ 18:20:
Ik zie niets? Voor wat betreft HDtune, dit is te gebruiken voor ssd's in zoverre je naar de gele lijn kijkt. Ik zie daar geen rare veranderingen.

Voor verbetering van de resultaten, welke resultaten? Er telt maar 1 ding voor de ssd. En dat is snelheid.
Een manier om dat te bekijken is as-ssd benchmark.

AS-SSD test toch niet de hele SSD en de file tree? Het test alleen door een bestand over te kopieren van plek a naar b toch?

Dit zijn de resultaten van het testen van bestanden op de SSD zelf, dus geen "benchmark".

Voor:


Na:


Lijkt me genoeg te zeggen?

[Reepje]

Je onderzoekt schijnrelaties. Of je ssd is op een totaal verkeerde manier aangesloten op je systeem en presteerd daardoor erg slecht (bijv doordat trim niet werkt, het ding niet in AHCI mode staat, er rare tuning truukjes zijn uitgevoerd, niet op een chipset poort maar op een marvell of asmedia poort etc).

Maar laten we nu even dat file bench nemen. Die is 6,9 keer beter. Dat betekend dus dat je systeem nu bijv in 18 sekonden opstart, en voor de defrag in 125 sekonden?

Als dat het geval is, dan hielp je defrag dus wel, maar dan is er dus iets helemaal fout met je configuratie.

[1337LutZ]

Reepje schreef op zondag 07 september 2014 @ 18:29:
Je onderzoekt schijnrelaties. Of je ssd is op een totaal verkeerde manier aangesloten op je systeem en presteerd daardoor erg slecht (bijv doordat trim niet werkt, het ding niet in AHCI mode staat, er rare tuning truukjes zijn uitgevoerd, niet op een chipset poort maar op een marvell of asmedia poort etc).

Maar laten we nu even dat file bench nemen. Die is 6,9 keer beter. Dat betekend dus dat je systeem nu bijv in 18 sekonden opstart, en voor de defrag in 125 sekonden?

Als dat het geval is, dan hielp je defrag dus wel, maar dan is er dus iets helemaal fout met je configuratie.

Deze resultaten zijn niet van mij, maar van een andere gebruiker op OCN. Er zijn meerdere gebruikers met de EVO SSD die dezelfde resultaten zien. Ikzelf heb geen screenshot genomen na deze test.

EDIT: Reepje heb je een EVO? Want je gaat wel redelijk offtopic / flamemode over iets wat wel gewoon resultaten boekt met onderbouwende resultaten.

Het gaat trouwens om oude data, die al langere tijd op de SSD aanwezig is.

[ Voor 10% gewijzigd door 1337LutZ op 07-09-2014 18:34 ]

[Reepje]

Wat tips. Staar je niet dood op benches. Zeker als je alleen kijkt naar "hoe hoog krijg ik de waardes, hoe recht krijg ik de mooie blauwe lijn in hdtune etc"
Niet alles wat je leest op internet hoeft waar te zien (geldt voor de posts van OCN, geld ook voor posts hier op tweakers, inclusief mijn stukjes) :
als je echt wil weten of je ssd optimaal presteert ga dan na bij jezelf: hoe snel start mijn pc op, krijg ik geen rare hang-ups, en hoe ziet mijn as ssd bench eruit.

Dan ben je al een heel eind.

[1337LutZ]

Reepje schreef op zondag 07 september 2014 @ 18:37:
Wat tips. Staar je niet dood op benches. Zeker als je alleen kijkt naar "hoe hoog krijg ik de waardes, hoe recht krijg ik de mooie blauwe lijn in hdtune etc"
Niet alles wat je leest op internet hoeft waar te zien (geldt voor de posts van OCN, geld ook voor posts hier op tweakers, inclusief mijn stukjes) :
als je echt wil weten of je ssd optimaal presteert ga dan na bij jezelf: hoe snel start mijn pc op, krijg ik geen rare hang-ups, en hoe ziet mijn as ssd bench eruit.

Dan ben je al een heel eind.

Mij maakt de opstart snelheid niet uit. Maar het snelheidsverlies van bestanden die langer bestaan dan anderen en het feit dat een defragmentatie dit weer gelijk trekt.

[Trommelrem]

Benchmarks voor SSD's kloppen niet.

Hier de Evo 500 GB's:


Deze waardes zijn hoger dan de fabrikant zelf specificeert. Conclusie: Benchmarkutilities kloppen niet altijd.

[1337LutZ]

Trommelrem schreef op zondag 07 september 2014 @ 18:54:
Benchmarks voor SSD's kloppen niet.

Hier de Evo 500 GB's:
[afbeelding]

Deze waardes zijn hoger dan de fabrikant zelf specificeert. Conclusie: Benchmarkutilities kloppen niet altijd.

Heb je toevallig RAPID mode aan staan?

Het gaat nu ook niet meer zozeer om die benchmark maar om het verlies van performance bij ouderen bestanden.

[Rukapul]

Kwestie van weten wat je meet. In dat opzicht is dat filebench tooltje een goed initiatief omdat het normaal gebruik (lezen van grote oude files) automatiseert en meet. Tevens handmatig verifieerbaar.

Wat mooi zou zijn om de correlatie tussen ouderdom en leessnelheid te bepalen. Uiteraard wel voor defrag tools de data hebben gerefreshed en bepaalde files met antidatering files genegeerd).

Een simpel python script zou dat zo moeten kunnen doen.

[1337LutZ]

FileBench geeft btw het ouderdom van het bestand aan.

Rukapul schreef op zondag 07 september 2014 @ 19:00:
Kwestie van weten wat je meet. In dat opzicht is dat filebench tooltje een goed initiatief omdat het normaal gebruik (lezen van grote oude files) automatiseert en meet. Tevens handmatig verifieerbaar.

Wat mooi zou zijn om de correlatie tussen ouderdom en leessnelheid te bepalen. Uiteraard wel voor defrag tools de data hebben gerefreshed en bepaalde files met antidatering files genegeerd).

Een simpel python script zou dat zo moeten kunnen doen.

Op OCN is het gemeld dat als je met dd gewoon de bestanden heen en weer kopiert de performance van de bestanden weer normaal is. Ook heeft Samsung aangeven dat oudere bestanden inderdaad minder prioriteit worden gegeven.

Mijn vraag is dan: Waarom komt dit dan bij de EVO versie voor en niet bij de PRO. En waarom zouden bestanden uberhaupt langzamer worden als ze ouder zijn, het is toch een SSD...

[Rukapul]

1337LutZ schreef op zondag 07 september 2014 @ 19:06:
FileBench geeft btw het ouderdom van het bestand aan.


[...]


Op OCN is het gemeld dat als je met dd gewoon de bestanden heen en weer kopiert de performance van de bestanden weer normaal is.

dd is dan ook de meest basale manier om blokken te refeshen

Ook heeft Samsung aangeven dat oudere bestanden inderdaad minder prioriteit worden gegeven.

'prioriteit' is me te vaag. En prioriteit geven is ook vaag als het onderliggende principe domweg aan de techniek relateert.

Mijn vraag is dan: Waarom komt dit dan bij de EVO versie voor en niet bij de PRO. En waarom zouden bestanden uberhaupt langzamer worden als ze ouder zijn, het is toch een SSD...

Precies. Is dit iets wat direct aan een eigenschap van TLC flash relateert? Ik kan in elk geval niet direct iets vinden over 'TLC flash read degradation'.

[1337LutZ]

Rukapul schreef op zondag 07 september 2014 @ 19:12:
[...]

dd is dan ook de meest basale manier om blokken te refeshen

[...]

'prioriteit' is me te vaag. En prioriteit geven is ook vaag als het onderliggende principe domweg aan de techniek relateert.

[...]

Precies. Is dit iets wat direct aan een eigenschap van TLC flash relateert? Ik kan in elk geval niet direct iets vinden over 'TLC flash read degradation'.

Ik kan daar ook niets over vinden. Alleen is het gewoon vaag dat je SSD performance degrade aan de hand van bestandsouderdom.

[Verwijderd]

HDTune is een benchmark programma geschreven in het tijdperk van hardeschijven en niet bedoeld voor SSDs. Het gaat uit van een enorm simpel opslagapparaat. Het test met een enorm low level I/O die kunstmatig is omdat geen enkel programma in de praktijk dergelijke I/O genereert.

Het grote verschil is dat HDtune buiten het filesystem om test, dat heeft bepaalde gevolgen. Zo is één belangrijk verschil dat er wordt getest met single queue I/O; terwijl dat nooit voorkomt bij sequential I/O. Je filesystem zorgt altijd voor extra queueing; read-ahead ofwel write buffering.

Een ander verschil is dat HDtune ruwe LBA leest, dus ook plekken waar het filesystem niets heeft opgeslagen. Bij simpele hardeschijven maakt dat niet uit; daar kun je spreken van begin en eind. Alle LBA komt overeen met een fysieke locatie op de platter van de hardeschijf. Of je nu bestaande data of onbeschreven plekken leest; de hardeschijf reageert daar niet anders op. SSDs echter wel.

Zo zijn de plekken waar de performance zichtbaar achteruitgaat, de plekken waar de SSD data heeft geschreven. Dit kun je ook zien bij de access time. Je ziet als het ware meerdere 'lagen' in de access time. Op plekken waar geen data staat, is de access time lager omdat er niet van NAND gelezen hoeft te worden. Je kunt dit ook zien op Intel X25-V bijvoorbeeld - deze kan helemaal niet zo snel lezen als SATA/300 mogelijk maakt, maar doet dat wel op plekken die helemaal niet in gebruik zijn:



Je hebt nieuwere versie van HDtune nodig om de access time te kunnen onderscheiden; omdat 0.1ms te weinig specifiek is voor SSDs; dan zie je de onderlinge verschillen niet meer. Maar ook hier zul je gelijksoortige verschillen zien.

In de praktijk is dit helemaal geen probleem, omdat je filesystem niet leest zoals HDtune dat doet. Wat HDtune leest als sequentieel, is door je filesystem heel anders opgeslagen. Lang verhaal kort; het hoeft helemaal niet nadelig te zijn als HDtune allerlei dalen en pieken vertoont. Het opnieuw schrijven kan echter wel degelijk voor wat performancewinst zorgen, maar aangezien SSDs al zo snel zijn zul je daar weinig in de praktijk van merken. Het zijn vooral kunstmatige benchmarks waarin je veel verschil merkt.

Bovendien, benchmarks kunnen verraderlijk zijn. Een HDD geeft met dezelfde benchmark met dezelfde data ook grofweg dezelfde resultaten. Bij een SSD niet. Die doet allerlei dingen op de achtergrond waardoor de ene test nooit exact gereproduceerd kan worden. Dit maakt het lastig om conclusies te trekken met benchmarking als je niet exact weet wat je aan het doen bent. Mijn advies is dan ook om je niet zo blind te staren op benchmarks - het is niet alsof je hier in de praktijk veel aan hebt.

[Reepje]

Dit is dan een stelling die jij hier neerzet? "De EVO Samsung SSD degradeerd aan de hand van bestandsouderdom. Waarbij dus een 600% degradatie is vastgesteld bij een schijf van enkele maanden oud".

Misschien kan dit topic dan inderdaad naar general chat verplaatst worden.

Een van de zaken waar ssd mee "kampen", is de zogenaamde write amplification door wear levelling en garbage collection. Data op een ssd is niet statisch, maar wordt herhaaldelijk herschreven voor verschillende oorzaken. Statische bestanden (bijvoorbeeld die van het windows besturingssysteem) worden zelfs herhaaldelijk verplaatst. Dit wordt geregeld door de firmware. En tussen firmwares zit natuurlijk verschil. Write amplification kan zelfs rond de 2x zijn. Als ik bijv naar mijn ssd kijk (een crucial) dan zie ik een average block erase count van 5. Het aantal schrijfakties op de ssd is verder 648 GB. Aangezien de ssd 240 GB is en elke blok 5x is herschreven is er 1200 GB totaal geschreven, write amplification is dus ongeveer 2.

[1337LutZ]

CiPHER bedankt voor je uitleg.

Weet jij misschien waar het aan kan liggen dat "oudere" bestanden slechte lees snelheiden geven? Bij een OCZ, Crucial of Samsung PRO komt dit namelijk niet voor. Weet jij meer over of TLC Nand er mee temaken kan hebben?

[Swordlord]

Een gegeven is dat de Samsung EVO gebruikt maakt van buffer technieken.
Zo is een stukje van het NAND in een SLC configuratie gezet, dat sneller te lezen en te beschrijven is dan de standaard TLC configuratie.

Nieuwe actieve bestanden, hebben kans dat ze nog in die buffer rondhangen.
Maar de extreme slechte lees snelheden zouden niet hieraan te verwijten moeten zijn geweest.

[ Voor 17% gewijzigd door Swordlord op 07-09-2014 19:54 ]

[jbhc]

Reepje; misschien moet je niet zo uit de hoogte reageren.

Het verhaal van CiPHER legt zeer duidelijk uit wat er aan de hand is met de benchmarkstools en het leuke is dat hij zijn verhaal kan onderbouwen met de getoonde uitkomst.

Dit is hoe een forum (en zeker een technisch forum) zou moeten werken. Iemand zet een stelling of vraag neer en andere mensen reageren hier op. Uiteindelijk kan iedereen er op deze manier van leren.

Opmerkingen over dieptepunten dragen helemaal niets bij aan de discussie. Erger nog, ze verpesten de discussie compleet.

Iemand vertellen hoe iets wel zou moeten is meer constructief dan iemand vertellen dat het fout is.

[1337LutZ]

jbhc schreef op zondag 07 september 2014 @ 22:58:
Reepje; misschien moet je niet zo uit de hoogte reageren.

Het verhaal van CiPHER legt zeer duidelijk uit wat er aan de hand is met de benchmarkstools en het leuke is dat hij zijn verhaal kan onderbouwen met de getoonde uitkomst.

Dit is hoe een forum (en zeker een technisch forum) zou moeten werken. Iemand zet een stelling of vraag neer en andere mensen reageren hier op. Uiteindelijk kan iedereen er op deze manier van leren.

Opmerkingen over dieptepunten dragen helemaal niets bij aan de discussie. Erger nog, ze verpesten de discussie compleet.

Iemand vertellen hoe iets wel zou moeten is meer constructief dan iemand vertellen dat het fout is.

Dankje jbhc

Ben benieuwd of iemand meer weet over de degradatie van oudere bestanden.

OCN quote:

But it seems that the EVO somehow isn't able to read sequential parts of older files in parallel anymore.

EDIT
Ik heb vanochtend mijn laptop opnieuw opgestart naar het doorlezen van de OCN thread updates. Ik kan zeggen dat ik zelf een merkmaar verschil zie tussen voor en na. Mijn Windows 8 cirkel draait nu maar 1.5x ipv de voorheengaande 4-5x. Ook het laden van login naar desktop is weer vrijwel instant.

[ Voor 13% gewijzigd door 1337LutZ op 08-09-2014 08:20 ]

[Verwijderd]

Erg interessant, vooral omdat het probleem door meerdere gebruikers wordt gemeld. Ik constateer zelf nauwelijks verschillen. Dat zou kunnen betekenen dat het per situatie verschillend kan zijn.

Wel merkwaardig zijn de verschillen tussen drie Samsung SSD's. Ik gebruik een EVO 120 GB, een EVO 1 TB en een PRO 256 GB. Alle drie zitten op dezelfde RAID controller, een Dawicontrol DC 624e. Geconfigureerd als losse, zelfstandige disks. Dus geen RAID, geen JOBD, niks. Ik kan niet controleren of het TRIM commando dat Windows stuurt, door de controller heen komt.

Als defragger gebruik ik Auslogics Disk Defrag, die vrijwel hetzelfde doet als Defraggler. Hij verplaatst de bestanden naar een andere positie en schrijft ze als 1 blok data weg. Ik heb de Samsung disk cache niet geinstalleerd. Op alle SSD's is de meeste recente firmware van Samsung geinstalleerd. De test is uitgevoerd op een ASUS P6T-SE met een Core I7-920 op 2,80 GHz. Windows 8.1 X64 met 36 GB DDR3 RAM.

Eerst de EVO 120, voor en na de defrag. De disk is half vol en heeft 20 GB OP.

Voor de defrag:


Na de defrag:

Ietsje sneller, te verwaarlozen.


Dan de EVO 1 TB. Eveneens half vol met 20 GB OP. Meer OP wilde ik niet verspillen.

Voor de defrag:


Na de defrag:

Weinig verschil, de diepste dip is afgezwakt.

Dan de PRO. Dat is een MLC, dus 2-level terwijl de EVO triple-level is. De PRO is duurder en is een paar procent sneller dan de EVO, vooral in IOPS. De 100.000 IOPS die Samsumg belooft haal ik alleen met de disk cache die via Samsung Magician geinstalleerd kan worden. Zonder cache is hij nauwelijks sneller dan de EVO. Dat wist ik van tevoren, maar ik wilde een betere disk voor zwaar gebruik. De meting is kaal, zonder cache. De disk is kwart vol met 20 GB OP.

Voor de defrag:


Na de defrag:

Eveneens ietsje sneller, maar belangrijker is dat de PRO geen dips heeft en dus altijd de maximale snelheid haalt, ook op plaatsen waar data staat.

Ter vergelijking nog mijn oude OCZ Vertex2, die al jaren betrouwbaar draait. Ondanks de SATA2 snelheid is hij gevoelsmatig sneller dan de PRO of EVO. Alleen omdat Windows 7 sneller (of soepeler) op lijkt te starten. De disk zit half vol, zonder OP.

Voor de defrag:


Na de defrag:

Nauwelijks verschil.

Mijn conclusie is dat defraggen of verplaatsen van bestanden voor mij weinig zin heeft. Voor degenen waarbij het wel helpt zou ik eerst uitzoeken of de oorzaak niet iets anders is dan een EVO probleem. Bijvoorbeeld: is de Windows defragger wel uitgeschakeld. Want dat gaat niet altijd automatisch. Dat onding verplaatst in het wilde weg bestanden en laat vaak versnipperde bestanden achter. Als het bestandssysteem zoals Windows dat ziet extreem gefragmenteerd is dan schijnt Windows daar moeite mee te hebben. Alhoewel extreme bestandsfragmentatie voor de SSD totaal niets uitmaakt, moet Windows zelf wel harder werken om de stukken en brokken bij elkaar te sprokkelen. In dat geval is een simpele defrag voldoende. Een volledige defrag met optimalisatie van de access tijd is alleen zinvol voor traditionele disks met schijven en koppen. Voor een SSD is dat zinloos en levert alleen maar extra slijtage.

[1337LutZ]

Verwijderd schreef op maandag 08 september 2014 @ 14:05:
Erg interessant, vooral omdat het probleem door meerdere gebruikers wordt gemeld. Ik constateer zelf nauwelijks verschillen. Dat zou kunnen betekenen dat het per situatie verschillend kan zijn.

Wel merkwaardig zijn de verschillen tussen drie Samsung SSD's. Ik gebruik een EVO 120 GB, een EVO 1 TB en een PRO 256 GB. Alle drie zitten op dezelfde RAID controller, een Dawicontrol DC 624e. Geconfigureerd als losse, zelfstandige disks. Dus geen RAID, geen JOBD, niks. Ik kan niet controleren of het TRIM commando dat Windows stuurt, door de controller heen komt.

Als defragger gebruik ik Auslogics Disk Defrag, die vrijwel hetzelfde doet als Defraggler. Hij verplaatst de bestanden naar een andere positie en schrijft ze als 1 blok data weg. Ik heb de Samsung disk cache niet geinstalleerd. Op alle SSD's is de meeste recente firmware van Samsung geinstalleerd. De test is uitgevoerd op een ASUS P6T-SE met een Core I7-920 op 2,80 GHz. Windows 8.1 X64 met 36 GB DDR3 RAM.

Eerst de EVO 120, voor en na de defrag. De disk is half vol en heeft 20 GB OP.

Voor de defrag:
[afbeelding]

Na de defrag:
[afbeelding]
Ietsje sneller, te verwaarlozen.


Dan de EVO 1 TB. Eveneens half vol met 20 GB OP. Meer OP wilde ik niet verspillen.

Voor de defrag:
[afbeelding]

Na de defrag:
[afbeelding]
Weinig verschil, de diepste dip is afgezwakt.

Dan de PRO. Dat is een MLC, dus 2-level terwijl de EVO triple-level is. De PRO is duurder en is een paar procent sneller dan de EVO, vooral in IOPS. De 100.000 IOPS die Samsumg belooft haal ik alleen met de disk cache die via Samsung Magician geinstalleerd kan worden. Zonder cache is hij nauwelijks sneller dan de EVO. Dat wist ik van tevoren, maar ik wilde een betere disk voor zwaar gebruik. De meting is kaal, zonder cache. De disk is kwart vol met 20 GB OP.

Voor de defrag:
[afbeelding]

Na de defrag:
[afbeelding]
Eveneens ietsje sneller, maar belangrijker is dat de PRO geen dips heeft en dus altijd de maximale snelheid haalt, ook op plaatsen waar data staat.

Ter vergelijking nog mijn oude OCZ Vertex2, die al jaren betrouwbaar draait. Ondanks de SATA2 snelheid is hij gevoelsmatig sneller dan de PRO of EVO. Alleen omdat Windows 7 sneller (of soepeler) op lijkt te starten. De disk zit half vol, zonder OP.

Voor de defrag:
[afbeelding]

Na de defrag:
[afbeelding]
Nauwelijks verschil.

Mijn conclusie is dat defraggen of verplaatsen van bestanden voor mij weinig zin heeft. Voor degenen waarbij het wel helpt zou ik eerst uitzoeken of de oorzaak niet iets anders is dan een EVO probleem. Bijvoorbeeld: is de Windows defragger wel uitgeschakeld. Want dat gaat niet altijd automatisch. Dat onding verplaatst in het wilde weg bestanden en laat vaak versnipperde bestanden achter. Als het bestandssysteem zoals Windows dat ziet extreem gefragmenteerd is dan schijnt Windows daar moeite mee te hebben. Alhoewel extreme bestandsfragmentatie voor de SSD totaal niets uitmaakt, moet Windows zelf wel harder werken om de stukken en brokken bij elkaar te sprokkelen. In dat geval is een simpele defrag voldoende. Een volledige defrag met optimalisatie van de access tijd is alleen zinvol voor traditionele disks met schijven en koppen. Voor een SSD is dat zinloos en levert alleen maar extra slijtage.

Dank voor je tests! Het schijnt dat als de SSD bestanden herschrijft ze weer sneller beschikbaar zijn. Als je interesse hebt kan je dat vanaf deze post lezen en over 2 posts staan de results.

http://www.overclock.net/...he-drive/80#post_22814099

Op het moment werk iemand aan een Filerewrite functie binnen zijn geschreven FileBench applicatie waarmee we dan 100% zeker weten of het opnieuw wegschrijven van een bestand het probleem oplost.

[Padje]

1337LutZ schreef op zondag 07 september 2014 @ 17:55:
[...]


Omdat je lifespan door het bewegen van data verminderd, maar een SSD gaat makkelijk 10 jaar mee onder normale omstandigheden dus eenmalig defragmenteren lijkt mij geen probleem.


Als het defraggen niet uit maakt, hoezo zijn mijn leestijden dan drastisch verbeterd?

Edit: Ik vraag ook alleen om een eenmalige defrag. Dat gaat niet de SSD magisch kapot maken gelukkig.

Ik weet niet hoor je hebt het over een eenmalige defrag? Wat was er in eerste instantie mis dat je erbij kwam om uberhaupt te defragmenteren? Wss komt dit door de CPU load die ook een rol speelt namelijk in me i7 is de EVO 1 rechte lijn.

[Verwijderd]

Defragmenteren is altijd slecht op een SSD omdat je het tegenovergestelde doet. Het filesystem denkt dat alle data na de defrag netjes bij elkaar staat. Maar in werkelijkheid heeft de logische LBA geen relatie meer met fysieke NAND adressen. Bij hardeschijven is dit wel zo: LBA0 (de eerste sector; bootsector) is aan het begin van de hardeschijf aan de buitenste tracks; terwijl de laatste sector in de binnenste tracks is opgeslagen. Hier is er dus een directe relatie tussen LBA en fysieke locatie. Zodoende heeft defragmenteren nut op hardeschijven, omdat de seekafstand zo kan worden verkleind.

Bij SSDs is dit heel anders en zijn de random writes juist wat data door de war schopt. De performance hoeft er niet zozeer onder te leiden te hebben bij een goede SSD, maar de write amplification gaat wel omhoog.

Echter, bij Windows 8 is 'defrag' slimmer en maakt het onderscheid tussen hardeschijven en SSDs. Zodra een SSD wordt gedetecteerd, wordt bij een 'defrag' (wat thans 'optimize' wordt genoemd) helemaal geen defragmentatie uitgevoerd, maar een TRIM erase op de vrije ruimte. Dat is ook binnen no time klaar; een paar seconden. Als je al normaal TRIM ondersteuning hebt, zou dit verder weinig mogen uitmaken. Maar het kan in elk geval geen kwaad. Maar in dit geval kun je niet van defragmenteren spreken; data wordt niet verplaatst.

[1337LutZ]

@Padje: Ik heb dit gedaan vanwege het topic op OCN. We zijn aan het proberen om te achterhalen waarom er zo een drastische degradatie in performance op oudere bestanden plaatsvind. Andere SSD's hebben hier namelijk geen last van.

[Verwijderd]

SwordLord gaf daar een goede uitleg over; de EVO series is niet strict een TLC-SSD maar plaatst een gedeelte van de NAND in sneller SLC. Wat jij noemt 'oudere gegevens' kunnen derhalve in de TLC verdrukt worden omdat nieuwere gegevens naar SLC worden geschreven. Maar ik ken niet de exacte werking van de Samsung EVO serie om daar iets heel nuttigs over te zeggen. Maar het klinkt mij wel plausibel.

[1337LutZ]

Verwijderd schreef op maandag 08 september 2014 @ 20:14:
SwordLord gaf daar een goede uitleg over; de EVO series is niet strict een TLC-SSD maar plaatst een gedeelte van de NAND in sneller SLC. Wat jij noemt 'oudere gegevens' kunnen derhalve in de TLC verdrukt worden omdat nieuwere gegevens naar SLC worden geschreven. Maar ik ken niet de exacte werking van de Samsung EVO serie om daar iets heel nuttigs over te zeggen. Maar het klinkt mij wel plausibel.

Hmm ok, maar dan zou je toch alsnog niet degradatie verwachten die tot "HDD" snelheden gaat? Of moeten we dat maar accepteren omdat we een goedkope EVO gekozen hebben?

[Verwijderd]

Kun je dat aantonen met goed uitgevoerde benchmarks?

[1337LutZ]

Verwijderd schreef op maandag 08 september 2014 @ 20:17:
Kun je dat aantonen met goed uitgevoerde benchmarks?

Als je de OCN thread doorleest zal je resultaten vinden die voor en na rewrite scenarios weergeven en daarbij ook de voor en na snelheden laten zien.

Voorbeeld:

[ Voor 23% gewijzigd door 1337LutZ op 08-09-2014 20:20 ]

[Verwijderd]

Nou dat doorlezen mag jij doen; jij bent immers die op zoek is naar de informatie.

Maar het punt is vooral: zijn die benchmarks goed uitgevoerd. Is er een rustperiode aangebracht waarop de SSD kan settlen. Vooral bij de EVO is dat nodig omdat de SSD bij 'rust' heel actief kan zijn in het herschikken van de gegevens; namelijk het van SLC naar TLC overbrengen van de gegevens. Als je niet goed benchmarkt, kun je derhalve resultaten krijgen die heel laag zijn maar bij normaal (realistisch) gebruik vrijwel nooit voorkomen. Dan zit je dus met kunstmatige benchmarks waarvan je niet weet wat je precies aan het testen bent.

Edit: aan de gegevens die je post kan ik weinig zien. Behalve vreemde dingen zoals meer dan 3000 gigabyte per seconde?! Ook zie ik 2MB/s maar onduidelijk is wat de request size is; hoe groot de bestanden zijn. Dat maakt nogal veel uit. Ook de sector size / cluster size is belangrijk van het filesystem; omdat je anders sector size amplification krijgt; je filesystem zit grote sectoren uit te lezen waarvan slechts een deel wordt gebruikt.

Benchmarken is tricky, vooral als iemand de benchmarks uitvoert die niet bijster veel bestand heeft van de materie. SSDs benchmarken is nog veel trickier, omdat zelfs iemand met veel verstand nog allerlei factoren niet kan uitsluiten. De gouden regel is bij benchmarken is: als je de resultaten exact kunt relateren aan één factor (ceteris paribus) dan verliezen ze hun betekenis.

[ Voor 39% gewijzigd door Verwijderd op 08-09-2014 20:30 ]

[1337LutZ]

Hmm, het gaat over bestanden die er al een jaar op staan. En er is ook een gebruiker die deze zelfde symptomen heeft na het uitvoeren van de nodige TRIM commands etc. Als je PC snachts aan staat en idled, zou dat toch genoeg moeten zijn voor de SSD om te settlen?

EDIT: Alle bestanden zijn groter dan 1mb btw.

[ Voor 8% gewijzigd door 1337LutZ op 08-09-2014 20:53 ]

[Verwijderd]

Denk dat je NTFS fragmentatie kunt uitsluiten , de verschillen zijn pas meetbaar met grotere 100MB + bestanden waarbij je spreekt over ms verschil tussen een gefragmenteerd bestand of niet gefragmenteerd . Valt me wel op dat Anandtech melding maakt van ander gedrag als bij andere ssd http://www.anandtech.com/...g-ssd-840-250gb-review/11

[Verwijderd]

Als de bestanden inderdaad 1 megabyte groot zijn; dan is het wel heel erg vreemd dat je performance 1MB/s is. Maar dat zou ik dan met een 'echt' programma willen zien en niet met FileBench wat voor mij onbekend is. Kopiëer dan met explorer (file manager van windows) handmatig bestanden, gaatt het dan echt met 1MB/s? Dat zou ik alleen kunnen verklaren als je kabelfouten hebt; en dat kun je zien in de SMART data zoals UDMA CRC Error Count.

[1337LutZ]

Verwijderd schreef op maandag 08 september 2014 @ 20:59:
Als de bestanden inderdaad 1 megabyte groot zijn; dan is het wel heel erg vreemd dat je performance 1MB/s is. Maar dat zou ik dan met een 'echt' programma willen zien en niet met FileBench wat voor mij onbekend is. Kopiëer dan met explorer (file manager van windows) handmatig bestanden, gaatt het dan echt met 1MB/s? Dat zou ik alleen kunnen verklaren als je kabelfouten hebt; en dat kun je zien in de SMART data zoals UDMA CRC Error Count.

Als het goed is staat er in de thread iemand die het handmatig gekopierd heeft en "maar" 60mbs kreeg, en na het "herschrijven" weer volledige snelheid.

[Verwijderd]

Maar daarbij ontbreekt waarschijnlijk de informatie wat er in de tussentijd is gebeurd. Wellicht dat voorafgaand aan de 60MB/s score er ook allerlei I/O acties hebben plaatsgevonden; waardoor tijdens de benchmark die 60MB/s produceerde, er allerlei activiteit op de achtergrond plaats heeft gevonden.

Dit is waarom dit soort benchmarks zo bedrieglijk kunnen zijn; je dient ze in pristine omstandigheden uit te voeren, anders schend je het principe van ceteris paribus en zijn je scores betekenisloos.

[robj28]

Ik heb ook lees snelheid problemen met mijn 840 EVO 250 GB, Maar Samsung werkt inmidels al aan een oplossing: http://www.anandtech.com/...nce-bug-fix-is-on-the-way

[Verwijderd]

Verwijderd schreef op maandag 08 september 2014 @ 23:04:
Maar daarbij ontbreekt waarschijnlijk de informatie wat er in de tussentijd is gebeurd. Wellicht dat voorafgaand aan de 60MB/s score er ook allerlei I/O acties hebben plaatsgevonden; waardoor tijdens de benchmark die 60MB/s produceerde, er allerlei activiteit op de achtergrond plaats heeft gevonden.

Dit is waarom dit soort benchmarks zo bedrieglijk kunnen zijn; je dient ze in pristine omstandigheden uit te voeren, anders schend je het principe van ceteris paribus en zijn je scores betekenisloos.

Bepaalde Binaire bestanden kunnen een hogere uitslag geven met dat programma , zo kan ik mijn XM25 V40 500MB/s laten lezen en ssd Raid0 met 2400 MB/s .



Kan de speed afstellen onder de 2400 op wat ik wil door het aantal Binaire bestanden te variëren , dit is met 200GB aan Binaire bestanden

[Viscerous]

Ook maar eventjes gekeken of ik het probleem heb, en jahoor. Toch best dramatische resultaten. Hopelijk kan Samsung het ook daadwerkelijk oplossen.

[GurbY{nl}]

Draaien jullie de "gewone" (W) defrag na de eerste test? Of met een andere utility..?? Zal em vanavond ook eens testen (heb een 256G); zit er nu ca. 1 maand in...

Dit nog wel gevonden: http://www.golem.de/news/...-oktober-1409-109434.html

[ Voor 30% gewijzigd door GurbY{nl} op 25-09-2014 07:32 ]

[1337LutZ]

Yes! Er is een update!

nieuws: Samsung brengt 15 oktober fix uit voor snelheidsdegradatie 840 EVO-ssd's

Is dus daadwerkelijk een probleem en niet een "slecht onderbouwde ervaring" of wat mensen het ook allemaal benoemden.

[temp00]

Ik heb een paar maanden geleden een 840 Evo 1TB gekocht (lekker groot omdat ik geen concessies wilde doen in gebruiksgemak) en van de week geschrokken het nieuwsbericht op de FP gelezen. Net even getest en met name die drop van 45% tot 80% vind ik erg raar. Meerdere keren getest maar telkens blijft hij zo raar droppen. Getest op de Intel controller van m'n ASRock Z77 Extreme4 mobo. Uiteraard alle achtergrond processen (waar mogelijk) uitgeschakeld tijdens de test.


Pas dit beeld in alle commotie die er de laatste tijd te doen is rond de Evo's?

[1337LutZ]

temp00 schreef op vrijdag 26 september 2014 @ 19:14:
Ik heb een paar maanden geleden een 840 Evo 1TB gekocht (lekker groot omdat ik geen concessies wilde doen in gebruiksgemak) en van de week geschrokken het nieuwsbericht op de FP gelezen. Net even getest en met name die drop van 45% tot 80% vind ik erg raar. Meerdere keren getest maar telkens blijft hij zo raar droppen. Getest op de Intel controller van m'n ASRock Z77 Extreme4 mobo. Uiteraard alle achtergrond processen (waar mogelijk) uitgeschakeld tijdens de test.
[afbeelding]

Pas dit beeld in alle commotie die er de laatste tijd te doen is rond de Evo's?

Yes, dit is precies het probleem wat zich voordeed.

[temp00]

Nou daar zijn we mooi mee dan Net even HDTach erbij gepakt en idd ook weer een nagenoeg identiek grafiekje.

Ben geen expert natuurlijk maar ik had hier en daar gelezen dat sommigen vermoeden dat het komt door een IC die te warm wordt als gevolg van een teveel aan ECC-acties. Als dat zo zou zijn dan zou een FW-update alleen helpen als die er voor zorgt dat de schijf structureel in snelheid wordt gethrottled wat natuurlijk gewoon kut is.

In Samsung Magican is er nog geen FW-update beschikbaar maar ik dacht in een ander topic wel een linkje te hebben gezien naar FW-update. Straks maar even proberen

[Fietsbel]

Is dit een probleem van de SSD zelf of icm met windows? Heb namelijk recentelijk een 840 evo in mijn imac geinstalleerd en weet niet of ik hier ook last van ga krijgen.

[temp00]

Volgens mij maakt 't niet welk OS je draait. Anders moet je even de verschillende sites door lezen. Hier ook het nieuwsbericht: nieuws: Samsung brengt 15 oktober fix uit voor snelheidsdegradatie 840 EVO-ssd's

[Steef]

Fietsbel schreef op zaterdag 27 september 2014 @ 17:16:
Is dit een probleem van de SSD zelf of icm met windows? Heb namelijk recentelijk een 840 evo in mijn imac geinstalleerd en weet niet of ik hier ook last van ga krijgen.

De oorzaak ligt schijnbaar in de belasting op de ECC verwerking (wat weer een gevolg is van TLC geheugen, maar dat terzijde)

De opgeslagen data degradeert met de tijd, ter compensatie is een hardware error checking aanwezig welke fouten in de uitgelezen data hersteld alvorens deze door te leveren aan het systeem. Schijnbaar heeft data van 30+ dagen oud dusdanig veel fouten dat de error correctie een zo grote last op de hardware legt dat deze te warm word, terug schakelt en prestatieproblemen met zich mee brengt.

Zo heb ik het begrepen. Dit zou inhouden dat het niet afhankelijk is van het OS.

[ Voor 3% gewijzigd door Steef op 28-09-2014 12:55 ]

[Fietsbel]

Bedankt voor jullie antwoorden, hopelijk zal de fix van 15 oktober het goed oplossen

[redfoxert]

Ik vraag me werkelijk af in hoeverre dit specifiek is voor Samsung EVO SSD's, de data degradatie dus.

Die ECC zou in feite helemaal niet nodig moeten zijn als de bitjes in de flash gewoon netjes hun waarde behouden. Blijkbaar is dat bij deze SSD's niet het geval en moet de ECC hardware overmatig corrigeren met problemen op performance gebied als gevolg.

Wat gaan ze doen met die firmware fix? De ECC hardware throttlen met een overall performance verlies tot gevolg? Waarom is die data ineens na ongeveer 30 dagen dermate beschadigd dat ECC nodig is? vragen vragen vragen ...

[Steef]

Relatief duidelijk filmpje wat het probleem beschrijft:

De test van PCP toont aan dat een hogere temperatuur invloed heeft op het uitlezen van oude data, wat de hypothese van het terug schalen van ARM controller chip in de SSD ondersteunt.

[Swordlord]

Het probleem zal niet alleen voor de Samung 840 drives zijn, het is een inherent probleem van TLC geheugen.
Al het Flash NAND (dus SLC, MLC & TLC) heeft de nadelige eigenschap, dat het spanning verliest over verloop van tijd.

Grof gesteld voorbeeld ter illustratie

• Het voltage waarop NAND opereert is 1 tot 10V.
• Er is altijd een grijs gebied tussen voltage punten en dit moet ook gerespecteerd worden omdat anders de bit anders kan worden aangezien
• Als dit grijs gebied wordt bereikt, is ECC correctie nodig.
• Vervaltijd van de spanning is 0,1V per maand.

------------

SLC met zijn 2 states, heeft dus voltage bereik 0-4V voor een 0 en 6 tot 10V.
Als de cell is geprogrammeerd op 10V en de Dan heeft SLC NAND heel wat tijd, voordat het grijs gebied van 5V wordt bereikt.

MLC heeft 4 states, Je hebt dus meer states nodig, dit betekend minder marge voor hoe groot 1 bit signaal is, maar ook dat de marge van het grijs gebied kleiner wordt.
Heel grof genomen de niveau's
00 = 0-1,5V,
01 = 2-3,5V,
11 = 5,5V-7V,
10 = 7,5V-9V
Er is nu dus nog maar opeens 1,5V speelruimte om te bepalen wat welke bit nou is.
Maar dit is schijnbaar nog meer dan acceptabel om goede data retentie zonder al te veel benodigdheden tot ECC te garanderen.

TLC nand brengt 8 bit combinaties met zich mee, daar tussenin moet ook nog eens het grijs gebied gerespecteerd worden.
Dan kom je uit op dat TLC nand maar iets van 0,5V speelruimte heeft voor te bepalen wat een bit nou is.

Zet daar het phenomeen bij dat je spanningsverlies gegarandeerd zal hebben en de kans dat een bitje in het grijs gebied komt en dus ECC correctie nodig heeft, wordt angstaanjagend groot.

[ Voor 17% gewijzigd door Swordlord op 28-09-2014 13:05 ]

[Trommelrem]

Swordlord schreef op zondag 28 september 2014 @ 12:57:
Er is nu dus nog maar opeens 1,5V speelruimte om te bepalen wat welke bit nou is.

Maar spanning zal alleen maar dalen, niet stijgen. Dus als je echt moet gokken, dan zal er meestal goed worden gegokt

[Swordlord]

Bij het programmeren kan niet altijd worden gegarandeerd dat de spanning ook daadwerkelijk is afgeleverd binnen de bit treshhold.
Een signaal dat dus 1,5V had moeten zijn, kan toevallig uitkomen als 1,6V
Dan is dat volgens jouw logica eigenlijk iets dat in het 2V bereik moest zitten.

Daarom wordt er altijd een grijs gebied gehanteerd, alles wat in dat bereik zit, bestaat niet, omdat het foute data kan zijn.
Dit principe wordt ook al jaren toegepast in data transmissies.

[ Voor 25% gewijzigd door Swordlord op 28-09-2014 13:12 ]

[Saven]

Holy shit Hier duikt ie wel heel veel?


Een 256 evo waarvan 143gb in gebruik van de 209.1gb (ivm over provisioning)

[ Voor 3% gewijzigd door Saven op 28-09-2014 13:21 ]

[Trommelrem]

Opzich zal de fix heel simpel zijn. Gewoon tijdens idle time alle chips opnieuw inlezen. Als een SSD een levensduur heeft van meer dan 30 jaar bij continu beschrijven mits je 10% vrije ruimte hebt, dan denk ik dat af en toe een full read geen probleem zal mogen vormen.

[rty]

Gaat het alleen over pure schrijfsnelheid of gaat het aantal iops hierdoor ook (merkbaar) naar beneden?

[Swordlord]

Trommelrem schreef op zondag 28 september 2014 @ 13:26:
Opzich zal de fix heel simpel zijn. Gewoon tijdens idle time alle chips opnieuw inlezen. Als een SSD een levensduur heeft van meer dan 30 jaar bij continu beschrijven mits je 10% vrije ruimte hebt, dan denk ik dat af en toe een full read geen probleem zal mogen vormen.

Inlezen is niet genoeg, het moet refreshed worden, dat moet dus een erase en program cycle zijn...
Swordlord in "Het grote SSD topic ~ Deel 9" Daar heb ik het er ookal over gehad.

rty schreef op zondag 28 september 2014 @ 13:27:
Gaat het alleen over pure schrijfsnelheid of gaat het aantal iops hierdoor ook (merkbaar) naar beneden?

Dude, leer eens lezen... Schrijfsnelheid heeft geen problemen.
..
Het lezen van oude data gaat naar 50 MB/s, omdat de drive het niet allemaal voor elkaar krijgt het goed uit te lezen gezien de vele ECC correcties...

[ Voor 9% gewijzigd door Swordlord op 28-09-2014 13:35 ]

[Jeroen.Abeelen]

Moet ik me zorgen maken over mijn Samsung SSD?

[M2M]

Jeroen.Abeelen schreef op woensdag 01 oktober 2014 @ 19:14:
[afbeelding]

[afbeelding]

Moet ik me zorgen maken over mijn Samsung SSD?

onder het mom van "if it looks too good to be true".... ja

[Reepje]

Jeroen.Abeelen schreef op woensdag 01 oktober 2014 @ 19:14:

Moet ik me zorgen maken over mijn Samsung SSD?

Ja, zet de computer meteen uit ! Je sata kan maximaal 600 MB/s lezen volgens zijn specificaties. Omdat er nu bijna 7000 MB/s doorheen gaat, zal je computer zeer binnenkort exploderen.

[1337LutZ]

Jeroen.Abeelen schreef op woensdag 01 oktober 2014 @ 19:14:
[afbeelding]

[afbeelding]

Moet ik me zorgen maken over mijn Samsung SSD?

Je hoeft je geen zorgen te maken. RAPID mode gebruikt voor sommige dingen je werkgeheugen, dus vandaar de snelle snelheden. Als je RAPID mode uitzet, zal je normale snelheden zien.

P.S. Ik heb slechte ervaringen met RAPID mode, waarbij er teveel werkgeheugen werd gebruikt en dingen zoals photoshop en chrome constant chrashden.

[Saven]

Kan dit dan wel softwarematig fatsoenlijke worden opgelost? Feit blijft gewoon dat er teveel ECC errors zijn

[Swordlord]

Mogelijkheden die samsung heeft:

1. Wear leveling protocol minder lui maken, dus meer data rotatie op het NAND waardoor lading in de cellen niet tot kritisch lage punten vallen.
   Nog steeds wel problematisch als een user niet veel GB's schrijft. Want er zijn niet genoeg write cycles om eventueel tijdig de drive een volledige refresh te geven.
2. Minder agressieve terug throtteling, waardoor de controller dus wel in gereduceerde snelheid, iets meer acceptabele performance kan bieden.
3. ECC routine optimaliseren, minder workload op de controller, waardoor minder snel thermisch plafond wordt bereikt.
4. Een soort watchdog introduceren, als een cell richting kritisch voltage gaat, erase en program opnieuw.
5. Combinatie van alles hierboven.

[pafdaddy]

Saven schreef op maandag 06 oktober 2014 @ 11:16:
Kan dit dan wel softwarematig fatsoenlijke worden opgelost? Feit blijft gewoon dat er teveel ECC errors zijn

Staat dat al onomkomelijk vast?

[Thomg]

Klein lijstje hier.
http://imgur.com/a/uaU2a
De eerste twee zijn pre defrag ( of eigenlijk domweg niks ervoor gedaan ).
De derde is na de performance optimization van samsung disk magician.
De laatste is na de defrag.

Alhoewel ik er wel op vooruit ging vind ik het nog steeds wel zorgelijk.

[temp00]

5.0 en 11.7% cpu usage tijdens de eerste twee testen. Zullen dus best wat programma's/achtergrond processen draaien die ook voor schijfactiviteit zorgen en de test dus beïnvloeden. Ongetwijfeld is er wat aan de hand, ik merk het zelf ook op m'n Evo, maar creëer eerst eens betere testcondities voordat je gaat vergelijken.

[Thomg]

temp00 schreef op maandag 06 oktober 2014 @ 19:17:
5.0 en 11.7% cpu usage tijdens de eerste twee testen. Zullen dus best wat programma's/achtergrond processen draaien die ook voor schijfactiviteit zorgen en de test dus beïnvloeden. Ongetwijfeld is er wat aan de hand, ik merk het zelf ook op m'n Evo, maar creëer eerst eens betere testcondities voordat je gaat vergelijken.

Omdat usage != schrijven/lezen van schijf.

Grappen en grollen terzijde, hoe?

[ Voor 4% gewijzigd door Thomg op 06-10-2014 19:42 ]

[temp00]

Dat stel ik niet. Maar je kan niet uitsluiten dat wanneer de CPU bezig is, er ook disk activiteit is. Sterker nog, met 11,7% vind ik dat best aannemelijk. 5% vind ik zelfs al veel. Als je gaat testen en vergelijken moet je er gewoon voor zorgen dat er zo weinig mogelijk externe factoren invloed hebben op het resultaat van je test. Het kleinste beetje disk activiteit van een programma anders dan je testprogramma kan namelijk al behoorlijke invloed hebben op je test.

[Buzz_Fuzz]

Ik zie hier niemand spreken over de "gewone" 840, zelfs niet in het nieuwsartikel over de verwachte fix, maar mijn Samsung 840, non-pro/non-evo, heeft toch gewoon hetzelfde probleem... (sata-300)



Samsung 830: geen probleem (sata-300)



File copy van een 1.5GB groot bestand uit 2007 van de Samsung 840 naar de 830:
(wat, nu ik erover denk, niet kan kloppen, want de 840 bestond nog niet in 2007 Anyway, het gaat hier dus om een (gecloned) bestand dat reeds van dag 1 op de SSD heeft gestaan, zo'n 2212 power-on hours geleden.))



Dafuq!?

File copy van een 1GB groot bestand uit 2010 van de Samsung 830 naar de 840:
(dito, 4145 power-on hours)



Diezelfde (nieuwe) file van hierboven terugkopiëren van de 840 naar de 830: terug geen probleem:




(Op de 840 staat de DXT07B0Q firmware.
Op de 830 staat de CXM01B1Q firmware.)

[Steef]

We mogen toch aannemen dat de heren bij Samsung het niet aan het verstand ontbreekt en inzien dat de 840 vergelijkbare problemen vertoont.

Nog 2 dagen voor de geplande firmware update

[Swordlord]

Het is meer dan bekend dat de 840 vanilla ook de problemen heeft...

Maar op Anandtech was Kristian zelf al twijfelachtig of er ook een fix kwam voor de 840 vanilla, gezien Samsung het aankondigd als: Patch voor 840 EVO komt eraan.

Enorme afgang voor hun zou ik zeggen als ze de 840 vanilla overslaan..

[ Voor 91% gewijzigd door Swordlord op 13-10-2014 13:14 ]

[temp00]

Zit ook te wachten op de firmware en ben erg benieuwd. Mocht er de 16de nog steeds geen FW zijn dan gaat m'n schijf terug naar Alternate en mogen hun voor een M500 zorgen. Potdomme eind Juli nog 382,99 voor die Evo uitgegeven.

[ Voor 4% gewijzigd door temp00 op 13-10-2014 18:31 ]

[Kuusj]

Nee de EVO 250GB van mij dan, heb het onding net 2 maanden, krap 400 uur on-time en 1.13TB written. Nu al 4% op de wear-level counter..

Ik ga dadelijk na het eten eens benchmarks draaien.

[Swordlord]

Kuusj, let op, RAW value is niet percentage. Maar het aantal keer dat je een volledige write cycle hebt gehad..
1000 GB / 250 GB = 4 cycles...

Voor de procentuele aftakeling moet je naar de current value kijken, die loopt van 100 terug naar 0%.

[ Voor 6% gewijzigd door Swordlord op 13-10-2014 18:43 ]

[Kuusj]

Samsung benchmark: http://prntscr.com/4vtnf2
Beginpagina Magician: http://prntscr.com/4vtno9
Overprovisioning: http://prntscr.com/4vtnw4
Die performance pagina: http://prntscr.com/4vtoif (wtf moet ik hier eigenlijk mee, echt duidelijk of je iets in of uitschakelt is het ook niet..)
S.M.A.R.T: http://prntscr.com/4vtv0h
S.M.A.R.T van mijn oude 1TB Barracuda: http://prntscr.com/4vtvo0
Plus deze: http://prntscr.com/4vtvyd


Bestand van ~10 GB (wel soms wat kleine bestandjes, maar dan nog): http://prntscr.com/4vtqto
Van C:/X naar C:
(nieuw, nog niks aan ge-edit, max 2 maanden geleden)

Belachelijk traag.
Mijn Seagate Barracuda welke stokvol zit, hetzelfde bestand: van F:/X naar F: http://prntscr.com/4vts6p.
(vervuilde installatie van hetzelfde spel, uit ~2012. 300 bestanden meer wat het er niet beter op zal maken.)

Wat een onding, ik heb trouwens ook niet het gevoel dat mijn systeem zo verschrikkelijk veel sneller is dan een verse HDD install. Ik had van tevoren al weinig goeds over SSD's te zeggen, maar 110 euro later ben ik er geen grijn enthousiaster van geworden. Echt niet.

[ Voor 15% gewijzigd door Kuusj op 13-10-2014 19:38 ]

[_Arthur]

kuusj98 schreef op maandag 13 oktober 2014 @ 19:31:
Ik had van tevoren al weinig goeds over SSD's te zeggen

Als ik jou was, zou ik dan lekker bij HDD's blijven.

Helaas heb je nu toevallig een SSD waar kennelijk een flinke firmware bug in zit: ik heb al jaren SSD's (van verschillende merken) en ben er niets anders dan tevreden over.

Kennelijk komt morgen de nieuwe firmware die dit hopelijk oplost.
Bron: http://www.anandtech.com/...ug-coming-on-october-15th

[Kuusj]

_Arthur schreef op dinsdag 14 oktober 2014 @ 12:31:
[...]

Als ik jou was, zou ik dan lekker bij HDD's blijven.

Helaas heb je nu toevallig een SSD waar kennelijk een flinke firmware bug in zit: ik heb al jaren SSD's (van verschillende merken) en ben er niets anders dan tevreden over.

Kennelijk komt morgen de nieuwe firmware die dit hopelijk oplost.
Bron: http://www.anandtech.com/...ug-coming-on-october-15th

Dat snap ik, misschien moet ik maar de 256GB Crucial MX100 uit de PC van mijn zusje slopen en die EVO van mij aan haar geven. Het boeit een 12 jarig meisje denk ik toch niet zo ontzettend veel

Maar, laten we inderdaad hopen dat die fix daadwerkelijk wat "fixt". Anders hebben we er nog weinig aan.

[GioStyle]

kuusj98 schreef op maandag 13 oktober 2014 @ 19:31:
Samsung benchmark: http://prntscr.com/4vtnf2
Beginpagina Magician: http://prntscr.com/4vtno9
Overprovisioning: http://prntscr.com/4vtnw4
Die performance pagina: http://prntscr.com/4vtoif (wtf moet ik hier eigenlijk mee, echt duidelijk of je iets in of uitschakelt is het ook niet..)
S.M.A.R.T: http://prntscr.com/4vtv0h
S.M.A.R.T van mijn oude 1TB Barracuda: http://prntscr.com/4vtvo0
Plus deze: http://prntscr.com/4vtvyd


Bestand van ~10 GB (wel soms wat kleine bestandjes, maar dan nog): http://prntscr.com/4vtqto
Van C:/X naar C:
(nieuw, nog niks aan ge-edit, max 2 maanden geleden)

Belachelijk traag.
Mijn Seagate Barracuda welke stokvol zit, hetzelfde bestand: van F:/X naar F: http://prntscr.com/4vts6p.
(vervuilde installatie van hetzelfde spel, uit ~2012. 300 bestanden meer wat het er niet beter op zal maken.)

Wat een onding, ik heb trouwens ook niet het gevoel dat mijn systeem zo verschrikkelijk veel sneller is dan een verse HDD install. Ik had van tevoren al weinig goeds over SSD's te zeggen, maar 110 euro later ben ik er geen grijn enthousiaster van geworden. Echt niet.

Hier thuis werken we met roaming profiles. In de profiles zitten ontzettend veel kleine bestanden. Bijvoorbeeld met mijn profile: (1,29GB, 30046 files), duurt het inloggen met een random hdd lang, rustig een half uur tot een uur. Absoluut niet handig. Met een ssd duurt het hooguit enkele minuten. Hier zitten dus wel met zijn allen een dikke grijns op te zetten.