OCZ en Indilinx krikken ssd-prestaties op met nieuwe firmware

Reacties

« 1 2 3 »

Door Worran, maandag 10 augustus 2009 18:32

dat is heel mooie natuurlijk!

maar ik vraag me wel af, of dit invloed heeft op de levensduur van de ssd?

Door Phyxion, maandag 10 augustus 2009 18:34

Of niks of het wordt er beter op (Ik denk het laatste). Of je ze nu meteen leegt haalt of later maakt niks uit voor de levensduur. Het voordeel van later doen is dat er niet te veel tegelijk gebeurd en waarschijnlijk voor een betere levensduur zorgt.

Door ls470, maandag 10 augustus 2009 22:18

Het lijkt me logischer dat de levensduur hierdoor vermindert: stel dat bijvoorbeeld de helft van een blok verouderde data bevat. De controller gaat dan de andere helft van het blok moeten copieren naar een nieuw blok, zodat het oude blok gewist wordt en terug beschikbaar is.
Als daarna het nieuwe blok verder volgeschreven wordt en de tweede helft van wat in een oud blok stond gewist wordt moet de controller terug een half blok copieren om het te kunnen wissen en vrijmaken.

Anderzijds, als de controller wacht tot het echt nodig is om dat blok te wissen kan het zijn dat beide helften tegen dan al gewist zijn en dus niets naar een ander blok gecopieerd moet worden en dus maar in totaal 1 blok gewist wordt.

Het is dus niet zo simpel om de controller te laten beslissen wanneer hij mag/moet beginnen met opruimen in idle-time: te weinig en het heeft geen effect; te veel en de levensduur wordt serieus ingekort...

Door Vastloper, dinsdag 11 augustus 2009 07:31

Je begrijpt het artikel niet helemaal, het is geen defragmentatie process dat is sowieso af te raden op SSD omdat dit altijd je schijven eerder door de cycles laat gaan. Dit gaat puur om een erase cycle uitvoeren op blokken die volledig zijn vrijgegeven al, normaal als je iets wist in een filesysteem dan word de data zelf niet gewist maar de de entry in de filesystem tabel die verwijst naar het blok word geleegd, zodra iemand anders het blok kan gebruiken voor een nieuw bestand oid dan word er een nieuwe entry gezet en het blok direct overschreven.
Bij de normale schijven van vroeger was een erase zinloos en was het sneller direct de nieuwe waarden erin te schrijven zodra dit kon. Bij SSD en met name flash chips moet een page/block eerst gewist worden voordat je gaat shcrijven. Met schrijven van flash kan je namelijk alleen 1'en 0 maken. een erase cycle zorgt ervoor dat een heel block/page in 1 keer weer naar alleen 1'en word gezet.
Nu is de truuc dus om tijdens idle alles alvast te erasen wat al is vrijgegeven zodat er in 1 keer "overschreven" kan worden. Nadeel hiervan is echter wel dat het programma's als undelete onmogelijk maakt. Wel een voordeel voor gevoelige gegevens.

Door RoadRunner84, dinsdag 11 augustus 2009 09:28

Dat klopt niet helemaal, de blokken waar hier over gesproken wordt zijn de flash sectors, deze zijn meestal 512 bytes. Een bestandssysteem maakt ook gebruik van sectors, deze zijn altijd even groot of groter (bijvoorbeeld 2 kilobytes) dan deze flash sectors. Een sector is dus nooit "deels" beschreven: het maakt wel deel uit van een bestand of het maakt er geen deel van uit. Natuurlijk kan een bestand wel groeien (een log bijvoorbeeld), maar dat is geen probleem: Een gewiste sector kan wel deels beschreven worden en later aangevuld (bits kunnen maar één kant op "vallen" in flash, de andere kant moet de hele sector gewist worden).
Het enige wat er hier dus gebeurd is dat in plaats van deze volgorde:
write-use-delete-nothing-erase-write
wordt deze volgorde aangehouden:
write-use-delete-nothing-erase_while_nothing-nothing-write
Het enige nadeel, zoals hieronder beschreven, is dat files niet geundelete kunnen worden.

Door springtouwtje, dinsdag 11 augustus 2009 10:02

een Flash sector is van buiten misschein 512 byte, maar de page size van een page erase is meestal veel groter.

Door siggie, maandag 10 augustus 2009 18:37

Blocks moeten toch eerst gewist worden eer dat deze weer beschreven kunnen worden. Wat er nu gebeurd is dat het wissen van vrijgegeven blokken veel eerder gebeurd, zodat wanneer deze blokken weer gebruikt gaan worden, direct de schrijfactie kan plaatsvinden (ipv wissen+schrijven).

Door ]Byte[, maandag 10 augustus 2009 18:37

Volgens mij niet. Het verschil is dat het wissen van de eerder beschreven blokken nu in idle-tijd gedaan worden en niet op het moment dat het geheugenblok opnieuw beschreven word. (zoals nu gedaan word)
Dat scheelt dus de wis-actie voordat de schrijfactie gedaan kan worden.
Simpel maar effectief!

[Reactie gewijzigd door ]Byte[ op maandag 10 augustus 2009 18:38]

Door likmereet, maandag 10 augustus 2009 21:12

je bedoelt van 171 jaar naar 169 jaar bv ?

Door c0d1f1ed, maandag 10 augustus 2009 22:53

Inderdaad. Steeds weer opnieuw die discussie over de levensduur van flash. Ze hebben een langere levensduur dan klassieke harddisks met bewegende onderdelen!

Door Chovav, maandag 10 augustus 2009 18:34

@ racer13 waarschijnlijk niet veel, aangezien die blokken toch al vrij waren en gewist moeten worden voordat ze gebruike kunnen worden. Of dat tijdens idle gebeurt of net voor het schrijven zal geen verschil uitmaken.

Voor de rest, ik snap niet dat het zo lang duurde om dit te verwezelijken. Het probleem was toch al lang duidelijk en de oplossing lijkt mij relatief simple. toch?

[Reactie gewijzigd door Chovav op maandag 10 augustus 2009 18:36]

Door twiFight, maandag 10 augustus 2009 18:49

Ik vind het inderdaad ook raar. Het eerder wissen van de 'lege' blokken was precies wat ik in mijn hoofd had, en ziedaar een paar regels later lees ik dat dat ook de 'fix' is. Overigens was mijn idee het gelijk bij het wissen van bestanden te doen, aangezien performance van de schijf er dan toch weinig toe doet. Ik heb zelden mijn HDD in gebruik wanneer ik iets wis.

Maar goed het zal wel komen door een nieuwe technologie, die fabrikanten zo snel mogelijk op de markt willen hebben.

Door DigiK-oz, maandag 10 augustus 2009 19:00

Gelijk bij het wissen van bestanden KAN ook. Enige vereisten : een SSD die het "trim" commando ondersteund (de meeste nog niet, maar wellicht ook via firmware toe te voegen) en een OS wat het ondersteund (weet alleen dat Windows 7 het doet, wellicht ook *nix varianten, eerdere windows versies in ieder geval niet).

Maar dan nog, is dit erasen tijdens idle time een hele mooie feature, al zal het met drives die kunnen trimmen plus windows7 dan niet/nauwelijks gebruikt worden.

Door Superstoned, maandag 10 augustus 2009 20:28

Een aantal nix bestandssystemen ondersteund Trim al, laatste kernel zou het moeten doen. Verder hoop ik dat deze verbetering ook voor linux kan komen, maar ik vermoed dat er vieze dingen zoals een daemon nodig zijn...

Door robvanwijk, maandag 10 augustus 2009 22:55

Ondersteuning voor TRIM is sowieso vereist; anders weet je niet welke blokken weer vrijgegeven zijn.
Er zijn drie soorten blokken: (1) nog nooit beschreven (2) ooit beschreven maar niet meer in gebruik (3) ooit beschreven en nog steeds in gebruik. Zonder TRIM kun je het verschil tussen de tweede en derde soort niet weten. En aangezien het nou juist precies de tweede soort is die je op wilt ruimen (en als het ware "terugzetten" naar de eerste soort) kun je zonder TRIM niks beginnen.

Door johnbetonschaar, maandag 10 augustus 2009 20:42

Het werkt net iets anders volgens mij. Wat ik ergens anders gelezen heb gaat het niet om het wissen van lege blokken, maar om het wissen van lege *cellen* van de SSD. Een SSD is opgebouwd uit cellen van (ik geloof) 512KB die opgedeeld zijn in blokken van 4KB. Op het moment dat een cel wordt beschreven waarvan bijvoorbeeld 320 van de 512KB bezet waren, dan wordt eerst de hele cel gelezen, gewist en dan herschreven met 512KB (de originele + de nieuwe inhoud).

Wat deze firmware update doet is een vorm van garbage collection, als de drive idle is loopt de controller alle niet volledig volle cellen af en bundelt de inhoud tot pakketjes van 512kb, zodat er meer volledig lege cellen overblijven. Writes van nieuwe data hoeven dan minder vaak half-volle cellen te legen/herschrijven op het moment dat de performance er wel toe doet.

De oplossing in deze firmware is dan dus ook net iets complexer dan het artikel doet vermoeden, want een efficient en veilig garbage collection algoritme schrijven is zeker niet triviaal.

[Reactie gewijzigd door johnbetonschaar op maandag 10 augustus 2009 20:48]

Door ls470, maandag 10 augustus 2009 21:58

De uitleg klopt ongeveer, maar de terminologie is niet helemaal juist: een NAND chip is opgebouwd uit blokken (de kleinste wisbare eenheid) die overeenkomen met wat jij cellen noemt.
Die blokken zijn onderverdeeld in paginas (bv. 2kB of 4kB) die de kleinste schrijfbare eenheid zijn (soms kan een pagina gedeeltelijk beschreven worden, maar dit is zeer beperkt)
De cellen van het geheugen zijn individuele floating gate transistoren, en komen dus overeen met 1 bit per cel (SLC) of 2-3 bit per cel (MLC)...

Het opruimen moet natuurlijk alleen gebeuren met blokken die cellen/paginas bevatten die al beschreven zijn, maar geen zinnige data meer bevatten (zodat het volledige blok gewist moet worden om die weer klaar voor gebruik te maken), niet met blokken die voor een stuk echt leeg zijn (gewist maar nog niet geschreven)...

Door Katsunami, maandag 10 augustus 2009 22:05

Ik vind het inderdaad ook raar. Het eerder wissen van de 'lege' blokken was precies wat ik in mijn hoofd had, en ziedaar een paar regels later lees ik dat dat ook de 'fix' is.

Eigenlijk vind ik het vreemd dat dit er nu pas is. Dingen optimaliseren tijdens idle-status is al zo oud als de tijd:

- Virusscan
- Defragmentatie
- Wachten met schrijven naar de hdd totdat deze even niet gebruikt wordt...
- ...

Toen ik voor de eerste keer las dat de blokken op SSD's eerst gewist moesten worden voordat er iets nieuws in kon worden geschreven, en dat dit het gebruik vertraagde naarmate er minder direct vrije blokken waren, was het eerste dat in mij opkwam: "Kunnen we defragmenteren in de achtergrond niet vervangen door wissen in de achtergrond?" En ziedaar...

Ik ga ervan uit dat men dit al lang in gedachte had, al sinds het eerste begin, maar dat nu pas het algoritme optimaal c.q. goed genoeg is.

Door locke960, maandag 10 augustus 2009 20:39

Waarschijnlijk doen ze het nu pas omdat men in eerste instantie het gedrag van een reguliere harde schijf zo exact mogelijk wilde nadoen. Deze verandering heeft namelijk ook nadelen en risico's.

1. Als je op een gewone harde schijf per ongeluk een bestand verwijderd kun je dat meestal nog terug halen met een of ander "undelete" utility. Dit omdat het OS het bestand niet echt weggooit maar alleen de gebruikte ruimte als "beschikbaar" markeert. Zolang het OS er niet daadwerkelijk andere data overheen schrijft kun je de data terughalen.
Met deze firmware kan dat niet meer omdat de SSD zelf de vrij ruimte bij de eerste gelegenheid leeg veegt.

2. Dat de SSD dit zelfstandig kan betekent dat deze niet meer domweg doet wat het OS vraagt, de SSD moet daadwerkelijk begrijpen hoe het filesysteem in elkaar zit. dwz, als het OS in de index aangeeft dat de ruimte beschikbaar is moet de firmware zelfstandig bepalen welke blokken op de SSD gewist kunnen worden. Dat kan bij een beschadigt filesysteem extra problemen opleveren. Het is trouwens ook de vraag welke filesystemen er ondersteund worden. Ik heb alleen nog maar Windows test resultaten gezien.

@Goderic: Het trim commando is de logische oplossing, maar dat wordt nergens genoemd. Dit lijkt een work around om de perfomance op te krikken op systemen die het trim commando (nog) niet ondersteunen.

[Reactie gewijzigd door locke960 op dinsdag 11 augustus 2009 13:01]

Door Goderic, dinsdag 11 augustus 2009 01:09

De SSD doet nogsteeds domweg wat het os vraagt: met het trim commando (wat btw ook in de nieuwste Linux kernel gaat zitten) zegt het os welke blokken nietmeer gebruikt zijn en de de SSD wist deze dan.

Door mbrunek, maandag 10 augustus 2009 18:35

Zeer interessant.

Dit zou een van de grootste nadelen van de SSD in een voordeel omzetten. Namelijk nagenoeg constante prestaties, onafhankelijk van de tijd dat hij al in gebruik is.

Ik denk dat andere fabrikanten hier ook tijd in moeten steken als ze de SSD echt de HD willen laten vervangen door het grote publiek.

[Reactie gewijzigd door mbrunek op maandag 10 augustus 2009 18:37]

Door Prototype666, maandag 10 augustus 2009 18:53

in pc's en servers die grote hoeveelheden data verwerken verandert dit niets, gezien de schijven daar toch bijna altijd in gebruik zijn. ookal blijven ssd's daar voordelig ivm lagere warmteproductie (voorzover ik weet zijn ze koeler in ieder geval)

Door c0d1f1ed, maandag 10 augustus 2009 22:58

...gezien de schijven daar toch bijna altijd in gebruik zijn.

De leessnelheden worden degraderen niet, en in vele systemen is het net dat wat de prestaties bepaald. Schrijfsnelheden zijn minder boeiend. Het is bijna louter om niet lager te scoren in synthetische benchmarks dat men deze probeert op te krikken.

Door mjtdevries, dinsdag 11 augustus 2009 16:38

Dat is onzin.
Natuurlijk willen ze beter scoren in benchmarks, maar ze willen ook voorkomen dat je vele seconden!!! zit te wachte op een schrijfactie.

Dat is wat nu bij veel goedkope SSDs gebeurd. Denk je een snel systeem te hebben, maar dan zit je ineens vaker te wachten op je systeem dan met je oude HDD.

Door gp500, maandag 10 augustus 2009 18:37

Geeft dat niet ook veel meer writes, oke het legen wordt gewoon naar voren gehaald.

Maar er wordt wel minder random geschreven, want bits/bytes worden zo vaker hergebruikt dan dat de lege eerst zijn beschreven.

Door zuurmeister, maandag 10 augustus 2009 18:39

Betekent dit dus dat het stroomverbuik in idle niet tot 0,41 watt daalt maar op het torenhoge niveau van 0,72 watt blijft?

lees ik hier voor de 30 gb vertex:

http://tweakers.net/revie...rtex-getest-pagina-6.html

Door Quacka, maandag 10 augustus 2009 18:53

hap hap: Torenhoog?
Ik denk dat het er ook aan ligt hoeveel je beschrijft en wist.
Zolang dit niet teveel is zal er niet al teveel gewist hoeven worden. Daarna kan de schijf weer gewoon in idle.

Door BRAINLESS01, maandag 10 augustus 2009 18:43

Zodra de ssd in idle-staat verkeert, worden gebruikte maar vrijgegeven geheugenblokken geleegd, zodat daar met dezelfde snelheid naar kan worden geschreven als bij een nieuwe drive.

Dat is natuurlijk logisch... waarom hadden ze dat er nog niet eerder in zitten? Zo moeilijk kan het niet zijn om te detecteren of de schijf idle is, gebruikte blokken dan weer leegmaken moet een eitje zijn.

Door martijnvanegdom, maandag 10 augustus 2009 20:04

@Bainless01 (en alle andere mensen die denken waarom hebben ze dit niet al veel langer.. )

Ik denk dat je 2 dingen over het hoofd ziet..

Zover ik weet hangt moet je bij het file system zijn om te kijken of bepaalde blokken in gebruik zijn. Dat detecteren van of een block in gebruik is, dat zou best eens een stuk lastiger kunnen zijn dan je zo op het eerste gezicht zou denken..

Daarnaast, als jij zo'n SSD hebt en je bent plots documenten kwijt omdat de firmware de verkeerde bllocken heeft geleegd dan denk ik dat je niet heel erg blij word. Om het dus werkend te krijg moeten je heel erg goed onderzocht hebben of je methode wel werkt..

Denk niet te makkelijk over dit soort technische dingen..

Door Chevy454, dinsdag 11 augustus 2009 07:33

Wat dacht je van eerst stabiliteit van het systeem? Je hebt niets aan een super uitgebreid systeem wat geveld gaat bugs. Beter een klein compact systeem wat goede resultaten voor snelheid maar vooral stabiliteit kent uitbrengen is het beste.

De extra performance komt later maar de fundamenten van het systeem moeten goed zijn.

Door edward2, maandag 10 augustus 2009 18:44

Kan je nou inmiddels de firm ware met behoud van data flashen, vroeger was dat dacht niet zo?

Door Sunbeam-tech, maandag 10 augustus 2009 19:13

Ja dat kan.
Met de eerdere firmware versies kon het idd nog niet.

Ik heb de Vertex 60GB in me Eee PC.
En de 3e firmware (1.30) die uitkwam kon ik flashen zonder de flash jumper op de SSD te plaatsen en had ook geen data verlies.

Ik weet natuurlijk niet of dit met de aankomende nieuwe firmware ook kan maar ik neem aan van wel.

[Reactie gewijzigd door Sunbeam-tech op maandag 10 augustus 2009 19:29]

Door Mig29, maandag 10 augustus 2009 22:24

Waarschijnlijk een beetje offtopic, maar ik ben wel erg benieuwd? Waarom kies je voor een SSD in een EeePC? Prestatiewinst lijkt me met een Atom niet echt de belangrijkste reden. Je investeert een bedrag ter grootte van ca 70% van de waarde van je netbook aan een SSD. Care to explain?

Door Sinned123, maandag 10 augustus 2009 23:36

Tja kan neit voor hem spreken maar kunnen maar een paar dingen zijn.
Minder verbruik waardoor langere batterij duur en minder warm.
Geen bewegende delen, waardoor vallen ed geen issue meer is.
Sneller, maar zoals jij als zegt met een atom merk je daar niet zoveel van.

Door High-Voltage2, dinsdag 11 augustus 2009 10:52

Sneller, maar zoals jij als zegt met een atom merk je daar niet zoveel van.

Tja, willen of niet, je zal toch moeten inzien dat zelfs bij een Atom of andere mobiele processor de HD de bottleneck is. Daarom wordt die gebufferd door iets sneller RAM geheugen en dat wordt nog eens gebufferd door cachegeheugen. Gewoon om de processor maar te kunnen laten werken. Zeker als je veel dingen tegelijk doet wordt de kans op een cache-mis aanzienlijk groter. Dus zal je meer op je RAM gaan leunen en dus heeft je HD automatisch meer werk.
Latency van een SSD is in vergelijkbaar met een gewone HD gewoon verwaarloosbaar, dus daar haal je zeker voordeel uit.

Door ChristianD, dinsdag 11 augustus 2009 08:41

Heb zelf ook een SSD in mij EEEPC 1000h geplaatst. De redenen voor mij waren:

Sneller opstarten
Betere respons bij opstarten applicaties
Lager stroomverbruik
Minder warmte

Al met al heeft de SSD ervoor gezorgd dat de algehele respons van mijn netbook aanzienlijk verbeterd is.

Door edward2, woensdag 12 augustus 2009 18:43

Ok thanx!

Door -Markster-, maandag 10 augustus 2009 18:45

goed nieuws

Maar ben ik dan alles kwijt, na het flashen ?

Door Sunbeam-tech, maandag 10 augustus 2009 19:25

Waarschijnlijk niet, zie hier boven voor het antwoord.

Door VNA9216, maandag 10 augustus 2009 18:48

Maar gaat die controller nu niet veel meer stroom verbruiken omdat hij eigenlijk continu bezig zal zijn?

Door D2D_Christiaan, maandag 10 augustus 2009 18:57

ja vast wel iets meer. maar het maximale verbruik van een SSD (onder load dus, bij de vertex +- 1W) is nog minder dan de meeste HDD in idle (meestal iets van 5 a 8W).

Door LvdBlom, maandag 10 augustus 2009 19:04

Volgens mij is dat maar van korte duur. Immers, er zal een moment zijn waarbij alle vrije blokken geleegd zijn, zodat er niks meer te legen valt, en dan zal de SSD drive alleen maar in idle toestand blijven en weinig stroom verbruiken.

De mate waarin de SSD in idle toestand zijn opschoonwerk doet, hangt af van hoeveel operaties er geweest zijn na de laatste succesvolle poging tot opschoning, zodat het de ene keer van korte duur is en de andere keer van lange duur, maar het extra stroomverbruik is sowieso tijdelijk.

Het is echter een wilde gok. Ik heb er zelf ook niet veel verstand van, maar het lijkt me wel logisch.

Door VNA9216, maandag 10 augustus 2009 19:27

Maar hij moet immers ook regelmatig checken of er blokken gewist moeten worden.
Zolang ze dat niet overdrijven valt het denk ik idd wel mee, maar je wilt dus duidelijk niet veel tijdelijke bestanden schrijven en weer weggooien denk ik. (al wil je dat natuurlijk altijd beperken met een SSD

Door flamingworm, maandag 10 augustus 2009 23:34

Zo zal er wss ingesteld kunnen worden dat wanneer een notebook/laptop/netbook op batterij bezig is de SSD niet getrimmed wordt, net zoals nu er dan niet gedefragmenteerd of geïndexeerd wordt. Vermoed ik

Of wie weet kun je het wel helemaal uitschakelen in 1x in de week/maand "trimmen"

Door springtouwtje, dinsdag 11 augustus 2009 10:06

wat in het OS opgelost mote worden, is dat het opschonen van de SSD alleen gebeurt als de laptop mains powered is.

Door Splorky, maandag 10 augustus 2009 18:57

in het begin van dat SSD's op de markt kwamen werdt gezegt dat er geen defragmentatie software nodig zou zijn.

nu is er firmware dat geheugenblokken die niet volledig vol zijn vrij maakt, en de data in andere datablokken zet die niet vrij zijn, maar wel nog plek is.

dus eigenlijk is er weer (een soort van) defragmentatie software, alleen dit keer in de firmware.

Door Sinned123, maandag 10 augustus 2009 23:37

Volgens mee klopt het deels.
SLC heeft volgens mij geen defragmentatie software nodig en MLC wel omdat het meerdere blocks in 1 sector wegschrijft.

« 1 2 3 »

Op dit item kan niet meer gereageerd worden.

19:38	Sharp integreert blu-ray-recorder in Aquos-tv
17:15	Symbian houdt nog twee jaar 'verouderde' S60-interface

Nieuws I/O

Shortcuts

Categorieën

Lees meer over

Gerelateerde producten

Gerelateerde content

Reacties

17:01 Nieuws

23:51 Productreviews

02:22 Vraag & Aanbod

25-05 Jobs

02:44 Etc.

04:27 Reacties

04:10 Forum

25-05 Gesponsorde acties

00:16 Tweakblogs

26-05 Computable headlines

25-05 CRN headlines