SSD-tråden: info om og diskusjon rundt SSD

[Theo343]

Hmm vil dette være en trend for Vertex også tro?

Ser snart for meg skrekkoverskriften "SSD's quickly diminishes/deteriorates over time"

Endret 14. februar 2009 av Theo343

[Nizzen]

Jeg venter jo også på noen Vertex ssd, men det er jo greitt å ha noen sas og satadisker i bakhånd om ssd failer totalt etterhvert

[Theo343]

Japps, jeg har 2 SAS porter på Revo kortet mitt, så skulle det bli noe fusk vil jeg kjøpe 2stk SAS 146GB 15K RPM og sette i Raid0. Bruker bare Acronis til å ta automatisk oppdatert imageprofil om natten så er det ingen fare med 2 SAS disker i Raid0.

 

Men først skal jeg gi 2xVertex en spin.

 

EDIT:

Jeg misstenker at godeste og gladgærne Nizzen venter på 6-12 stk 30GB Vertex disker . Det er godt han gleder oss hehe.

Endret 14. februar 2009 av Theo343

[Anv]

Vedr: pcper artikkelen.

 

På en måte er det litt skremmende, men samtidig må man være klar over at SSD for forbrukere er i startfasen.

Nye problemer kan og vil dukke opp, men siden SSD er ren "elektronikk" (ingen mekaniske deler) skulle man tro at dette kan løses med firmware eller spesielle utilities for SSD "defragmentering/optimalisering".

 

Benching ser ut til å være noe av det værste man kan gjøre med X25-M. (da det har et annet bruksmønster enn normal bruk)

 

Dette har ikke skremt meg fra SSD, tvert i mot har det bare vist at teknologien er under utvikling og at de er klar over problemene.

[Beef Supreme]

Er dette forbeholdt MLC, eller vedrører det SLC også?

[Anv]

Det gjelder MLC, SLC, FusionIO m.m.

 

Bare søk på google så finner du endel om emnet, det er også omtalt i tidligere reviews så problemet er ikke helt nytt men rykter sprer seg fort når sluttbrukere får "problemer".

[GullLars]

Så langt jeg har fått med meg har ikke Fusion-IO problemer med dette. De bruker en helt annen arkitektur og teknologi enn Intel gjør. Det er også store forskjeller i kontroller teknologi fra "mainstream" SSD til "enterprise". Det er ikke bare MLC vs SLC som utgjør prisforskjellen.

 

Her er en sammenlikning av mine 2x Mtron Pro (1. gen) i raid-0 fra ASUS 790FX sørbro (650SB). Det første bildet er fra når de var helt nye og jeg kjørte vista fra velociraptoren. Det andre bildet er med vista og alle programmer + Steam (CSS) installert på de, og bruk fra ca 5. sep til i dag. Som dere kan se er det nå 2,5GB ledig plass, og dette skal i teorien videre degradere skriveytelsen (man vil kunne merke forskjell fra ca 10% ledig og nedover, avhengig av kontroller, wear leveling, og garbage collection, samt reserverte celler).

Første bilde: når de var nye og "tomme". 100MB lengde

Andre bilde: etter ca et halvt års bruk som systemdisk. 1000MB lengde

 

Det slo meg også at første gangen kjørte jeg med 100MB som lengde, så her er et nytt SS med 100MB lengde etter et halvt år som systemdisk:

 

Ut fra dette vil jeg konkludere med at leseytelsen er nøyaktig lik, og det samme er skriveytelsen bortsett fra sekvensielt der det er en liten degradering. Denne degraderingen kommer sansynligvis av 2 ting, det blir kjørt OS fra enheten, og det er liten plass igjen (det blir vanskeligere for kontrolleren å rydde unna plass fort nokk). Jeg synes dette er nydelige resultater, og står fortsatt fast på at jeg ikke har angret i det hele tatt at jeg betalte 10.000 kr for disse 2x32GB enhetene i månedskifte august/september.

 

Jeg vil også poengtere at disse enhetene er produsert i 2007, så det er ikke ny teknologi som sitter i de. SLC cellene er også oppgitt å tåle 5 millioner skrivesykler, så påvirkningen på levetid av disse benchmarkene bekymrer meg ikke det minste

Jeg gleder meg til å teste disse fra adaptec 5805 kortet mitt senere, det vil forhåpentligvis klare å gi begge fritt pusterom. Ut fra benchmarks gjort med Mtron Battleship vil jeg håpe å oppnå opp mot dobbelt av 4kb random read tallene jeg har her

(edit: typo. rettlesing er kjekt)

Endret 14. februar 2009 av GullLars

[Anv]

@GullLars

 

Benching påvirker levetiden i liten grad, hvis man da ikke bencher dagen lang. (noe som er helt usannsynlig)

Det påvirker imidlertid ytelsen, samtidig *kan* man bruke enkelte av benchprogrammene til å få tilbake ytelse. (f.eks HDTach eller IOmeter)

 

iodrive (FusionIO) har laget en egen "format" utility for å få tilbake ytelsen.

Felles for de aller fleste metodene er at de er destruktive, dvs du mister alle data.

 

Jeg er ikke i tvil om at dette løser seg og kommer til å fortsette utskiftingen av HDD'er i tiden som kommer.

(det er vel tvilsomt at jeg bytter ut alt i år, i mellomtiden blir teknologien både raskere og mer utprøvd)

Endret 14. februar 2009 av Anvil

[GullLars]

Jeg kjørte akkurat gjennom 9x6=54 serier med 1000MB + 9x6=54 serier med 100MB på raidet mitt. Ytelsestallene er ikke påvirket i det heletatt. Og når jeg fortsatt får nøyaktig like tall etter et halvt år med aktiv bruk (SSDene har ikke sittet i fred kan jeg love deg ), så drar jeg konklusjonen at mine enheter ikke har fått degradert ytelse over tid. Det betyr ikke at jeg er uenig i at andre enheter kan få det.

 

Hvis ioDrive får degradert ytelse over tid er det noe jeg ikke viste om, hvis du har link til kilder setter jeg pris på det, siden jeg gjærne vil lese hele artikkelen/testen i dybden for å forstå problemet bedre. Hittil har jeg vært av den oppfattningen at de fleste high end SSDer har løst dette problemet, og at teknologien og IP som går med til dette er grunnen til at "enterprise SSD" koster såpass mye som det gjør.

EasyCO (blandt flere andre) har også laget software som ordner slike problemer gjennom "write management" og device drivers. Men som vanlig vet de godt hva de skal ha for dette.

[Anv]

Endel finner du på SSDForum.

 

Link

 

edit:

Jeg har ingen anelse om man merker degraderingen på andre måter enn i benchmarks. Får følge med på mine etterhvert. Jeg har relativt mye data som endrer seg hver dag så det er bare å vente og se.

Endret 14. februar 2009 av Anvil

[Beef Supreme]

Det kom ut en ny firmware til Mtron igår faktisk.

 

Products to be Applied:

All 7500 / 3500 / 7000 / 3000 series

 

Support Security mode Features Set

ATA8 spec (Standard)

Support Secure Erase (Secure Data Elimination) feature

Available only when SSDs have HSE or SSE model name.

Fixed data compare error when Write Cache is disabled

Fixed drive blocking issue when the LBAs over the Max LBA are accessed.

Fixed several drive rejection issues that are caused by ECC error when write operation.

Fixed the incorrect information of SSD’s Life time displayed on SW untility in some models.

It’s not critical issue related to Performance, Compatibility, and Stability of SSD.

Fixed recognization issues of MSD-PATA3025-016 in several systems

 

 

Vil gjerne oppgradere, men er litt redd for at raidet mitt går i dass. Får prøve i morra og håpe på det beste

[GullLars]

Arconis har blitt gratis, lag deg et bilde av raidet før du oppgraderer firmware, så kan du sette bildet tilbake etterpå hvis det går galt. Vurderer å ta en firmware oppgradering etterhvert jeg også, men jeg ser egentlig ikke vitsen med mindre det øker ytelsen betraktelig.

[Anv]

 

CDM tatt etter noen dagers intensivt bruk. (VMWare, Installering av Windows 7)

 

Nå har jeg tømt disken og sjekket ytelsen mot det jeg fikk første dag.

Det er et lite avvik i leseytelse og linja er ikke lengre like flat som den var første dagen, men det er ikke store forskjellen.

 

Legger ut en graf som viser ny og brukt ytelse når jeg har fått kjørt den litt mere.

(om en ukes tid ca)

 

edit: la til atto

Endret 15. februar 2009 av Anvil

[GullLars]

Fine tall det der.

Du hadde vell ikke gidde å gjenntatt Crystal diskmark med 1000MB lengde?

Jeg fant at det kan gi forskjellige resultater fra 100MB. Jeg regner med det blir pga lengden i forhold til cache, og at det gir en ilustrasjon av hvordan kontrolleren takler å opprettholde hastighetene over tid.

[Anv]

 

Her er den, kan ikke se noen større avvik.

Som i de andre testene står den i min HTPC P5Q Deluxe, Xeon 3360 @3.6GHz

Endret 15. februar 2009 av Anvil

[Timster]

Jeg leste også testen om at SSD fikk mye dårligere ytelse etterhvert og det må jo være en firmvare "feil" for en SSD er jo solid- state og blir ikke slitt på lik linje med en HDD. Cellene blir jo litt degradert etter hvert, men ikke etter så kort tid som de testet den vel.

Var det noen som la merke til i den testen (eller kanskje jeg surrer) at hvis man skrev over hele mediet med en diger fil, så fikk den tilbake standard ytelse?

 

EDIT Jeg kom over http://www.fudzilla.com/index.php?option=c...5&Itemid=67 den siden å, er sjanser for at den har vert postet før, men er den den Vertexen som kommer nå? I og med at den het Vertex 2.

Endret 15. februar 2009 av Timster

[Anv]

Kort forklaring av problematikken.

 

På en HDD ligger dataene lagret i et system hvor logisk posisjon = fysisk posisjon.

Det trenges ingen "oppslagstabell" for å finne posisjonen man skal lese fra eller skrive til.

Det eneste som trenges her er da en (file allocation table) som forteller hvor filene fysisk ligger.

 

På en SSD er dette helt anderledes.

Logisk posisjon <> fysisk posisjon, dvs logisk posisjon nr 1 kan være fysisk posisjon nr 1000.

Dette endrer seg hele tiden og det kreves derfor et "system" i SSD'en som holder orden på dette.

Det er dette systemet som gjør hele forskjellen og som gir de nevnte problemene.

 

Forklaringen til XBitLabs skulle være forståelig for de fleste.

Stikkordet her er LBA (Logical Block Addressing) allocation table.

 

Link

 

Husk nå at bruksmønsteret til oss normale brukere er totalt anderledes enn disse iometer testene som simulerer server belastning.

Det er ingen mulighet for at man kan komme i nærheten av slik belastning.

 

Jeg vil oppfordre dere til å ta det med ro, ikke legg for mye i dette enda.

Skulle din SSD bli degradert kan man uansett få den tilbake til original ytelse med noen triks!

 

edit:

Årsaken til at dette vises så godt på Intel's og FusionIO's SSD'er er at de rett og slett er mer avansert enn "billige" SSD'er. (på godt og vondt)

Når det gjelder Intel's MLC og SLC så jevner dette seg ut over tid, de blir på en måte "innkjørt".

På MLC'en kan dette ta noe tid.

På SLC skjer dette kjapt.

Endret 15. februar 2009 av Anvil

[Simen1]

På en HDD ligger dataene lagret i et system hvor logisk posisjon = fysisk posisjon. Det trenges ingen "oppslagstabell" for å finne posisjonen man skal lese fra eller skrive til. Det eneste som trenges her er da en (file allocation table) som forteller hvor filene fysisk ligger.

Dette stemmer ikke. Harddisker har også et skjult adresselag kalt "low level". Harddisken har en firmware som holder styr på logisk posisjon i adressene som SATA-kontrolleren ser vs fysisk posisjon i low level. Før ca 1993 hadde ikke harddiskene noe low level. Da var adressene fysiske adresser med spor og sektorer. Harddiskprodusenten gikk bort i fra dette fordi det ga dem mulighet til å erstatte defekte clustere på disken med reserveclustere på et annet område. Levetiden og feilprosenten sank drastisk samtidig som OS slapp å gjøre så mye feilsøking og feilretting selv. Defekte filer ble veldig mye sjeldnere.

 

Problemet med SSD er at det er ganske ungt og kontrollerne ikke er utviklet skikkelig ennå for å kunne håndtere egenskapene flashmediene har. F.eks at ting må/bør skrives blokkvis, leses blokkvis osv. Dersom f.eks filsystemets clusterstørrelse eller et Raid-systems stripestørrelse er i ulage med den faktiske blokkstørrelsen så er det mange kontrollere som ikke klarer å håndtere det bra. Altså gir mye dårligere ytelse enn flash i utgangspunktet er i stand til. Ser man på OCZ Core vs FusionIO så ser man fort at noen produsenter får det til mye bedre enn andre. Det skyldes kontrollere, firmware, Raid, filsystemer, grensesnitt og mye annet.

[Anv]

Simen1

 

Forklaringen min er noe forenklet for at man skal fortå det på "norsk".

 

Her er Intels redegjørelse. (som i praksis er det jeg har sagt)

 

"SSDs all have what is known as an “Indirection System” – aka an LBA allocation table (similar to an OS file allocation table). LBAs are not typically stored in the same physical location each time they are written. If you write LBA 0, it may go to physical location 0, but if you write it again later, it may go to physical location 50, or 8.567 million, or wherever. Because of this, all SSDs performance will vary over time and settle to some steady state value. Our SSD dynamically adjusts to the incoming workload to get the optimum performance for the workload. This takes time. Other lower performing SSDs take less time as they have less complicated systems. HDDs take no time at all because their systems are fixed logical to physical systems, so their performance is immediately deterministic for any workload IOMeter throws at them.

"

Endret 15. februar 2009 av Anvil

[GullLars]

For å hindre panikk om degradert ytelse her: Hvis dere sjekker screenshots jeg har postet over, så ser dere at Mtron i alle fall ikke får degradert ytelse over tid. Men nå koster disse en god del også, og er designet for servere. (jeg vil tro at mobi ikke har noen problemer heller, siden de bruker samme teknologi. Mtron lager sine egene kontrollere og PCB mener jeg på, på samme måte som Bitmicro)