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

[Simen1]

Personlig liker jeg at C300 og Intel ikke komprimerer data.

Av ren nysgjerrighet: Hvorfor liker du ikke komprimering?

[Theo343]

Hvorfor skal jeg får variabel ytelse på lagringsmediet fordi kontrolleren bedriver komprimering. Jeg synes den slags hører hjemme andre stedet om man absolutt vil ha det.

 

Jeg sa heller ikke at jeg ikke liker komprimering generelt, jeg vil bare ikke ha det i drevets kontroller.

 

Hvorfor liker du det?

Endret 23. desember 2010 av Theo343

[Simen1]

Jeg var nysgjerrig fordi jeg ikke kunne komme på noen ulemper med komprimering. Sammenlignet med en SSD uten komprimering vil det i mine øyne være utelukkende positivt fordi det gir "turbo" i enkelte situasjoner. Det gir aldri ytelsereduksjon. Kun en variabel turbo fra null til et ukjent tall.

[Anv]

Nå er det jo slik at de sekvensielle ytelsestallene som oppgis på SF baserte SSDer er oppgitt basert på tilnærmet 100% komprimerbare data.

Man oppnår i praksis aldri denne ytelsen.

 

Hadde tallene vært oppgitt for ikke komprimerbare data hadde det du sier vært korrekt.

 

Ytelsestallene for sekvensiell I/O ville da ha vært ca 200/130 MB/s, i forhold til ca 275/275MB/s det ser ikke så pent ut akkurat.

Komprimering gir ytelsesreduksjon når man går ut med data som gir de beste forutsetningene.

 

Igjen, SF yter kanonbra på random I/O men det er ikke disse tallene som markedsføres.

Problemet er at "bransjen" bruker sekvensiell I/O som målestokk.

[Simen1]

Hva som er oppgitt/markedsført ser jeg ikke så nøye på. Jeg tenker mer prinsippielt om komprimering vs ikke komprimering på ellers like SSDer. Tenk deg en SSD der man kan slå av og på komprimeringen. Jeg ville helt klart hatt komprimeringen slått på og ser ingen ulemper med det.

[Anv]

Svaret er egentlig ikke sort/hvitt.

 

Fordelen med komprimering er i praksis at man får betydelig lengre levetid på NANDen (forutsatt at man har komprimerbare data), ellers merkes det svært lite til ytelsesfordeler vs SSDer som ikke bruker kompresjon.

 

Jeg ville ikke ha valgt en SF basert SSD til en "multimedia" maskin, som boot "disk" er den derimot nesten perfekt.

Steady-state oppnås mye tidligere når man jobber med ikke komprimerbare data og trangen til en HDDerase dukker opp.

(Steady-state på en SF basert SSD gir en rimelig brutal "degradering" av ytelse, vi snakker fort om 30% eller mer)

[ysoligard]

(Steady-state på en SF basert SSD gir en rimelig brutal "degradering" av ytelse, vi snakker fort om 30% eller mer)

 

Ble litt nyskjerrig....Kan du gi en forklaring på hva som menes med "steady-state"?

[Theo343]

Anvil/simen1:

Det er akkurat slike ting som dette jeg mener. Det egner seg ikke like godt til all bruk og jeg ser ikke at jeg trenger fordelene vs ulempene.

Det skurrer litt for meg å ha komprimering i drevets kontroller nettopp fordi det ikke egner seg til all bruk, i tillegg er ikke samme komprimeringsalgoritme optimalt til alle type data osv. Uten at jeg kjenner kontrolleren og dette i detalj.

 

Jeg forstår klart fordelen ved at det skrives/leses mindre data til flashmedium, men jeg trenger heller ikke den ekstra levetiden samt at jeg har nevnte skepsis til det. Jeg synes også på lik linje som Anvil at det er tullete å bruke best-case komprimeringsrate som markedsføring av sekvensiell ytelse da det gjør markedsføringen ennå hakket mer villedende.

 

Som OS disk til en SFF maskin jeg driver å bygger kunne jeg dog vurdert den om den kom med et tilbud på rundt 750,- for en Vertex2/Force 64GB utgave innenfor 1 måned. Hvis ikke går jeg liksågodt for en C300.

Endret 24. desember 2010 av Theo343

[Anv]

(Steady-state på en SF basert SSD gir en rimelig brutal "degradering" av ytelse, vi snakker fort om 30% eller mer)

 

Ble litt nyskjerrig....Kan du gi en forklaring på hva som menes med "steady-state"?

 

Steady-state oppnås i det øyeblikk alle celler har vært skrevet til 1 gang.

I det øyeblikket begynner bla. virkningen av wear-levelling å vise seg, m.m.

 

Jeg har en hel haug med Vertex 2 så mine betraktninger rundt SF er ikke ment å skape uro eller negativitet rundt disse SSDene

Jeg anbefaler gjerne en Vertex 2 (eller en hvilken som helst SF basert SSD) hvis bruksområdet passer.

 

Prisene på bla Vertex 2 120GB er svært gunstige nå og gjør dem til meget gode kjøp.

Vertex 2 240GB er på supertilbud nå på NetShop og jeg har vært nært å trykke på knappen flere ganger.

 

Jeg har litt betenkeligheter med å anbefale de minste SF SSDene (dvs 60GB og mindre) da man raskt oppnår steady-state med mindre man kjører flere i raid-0.

Det kommer selvsagt også an på bruksmønsteret, hvis mye er statisk er det null problem.

 

 

@Theo

Jeg avventer til G3 kommer, med mindre det kommer noen kanontilbud på noe spennende

 

Jeg anbefaler Intel G2, C300 eller Vertex 2 uten noen annen preferanse enn pris/ kapasitet, de yter så bra at man ikke merker noen forskjell i praksis. (med forbehold om bruksområde)

 

--

 

GOD JUL

Til alle brukere på hw.no

Endret 24. desember 2010 av Anvil

[BAT]

GOD JUL ALLE SAMMEN

[johome]

GOD JUL

[Theo343]

God Jul

Endret 24. desember 2010 av Theo343

[GullLars]

Siden mange andre har gjort det følger jeg også på.

 

God Jul

[ysoligard]

God jul til alle

[Efreet]

Fekk meg ein SSD til jul no.

 

Skal ha den til hdd i laptoppen min, så snart eg får skrudd ut den andre. dumme øydelagde skruar >.<

 

 

Er det nokre ting eg burde gjer FØR eg erstatter den, utanom generell backup?

meinar eg leste noko om BIOS og auking av yting.

 

Alle tips eller linker er kjekke, søkte litt men fann lite relevant

[johome]

Angående BIOS.

Prøv å enable AHCI modus.

[BAT]

Artikkel hos Tom's Hardware

 

SSD Performance: TRIM And Firmware Updates Tested

[GullLars]

Artikkel hos Tom's Hardware

 

SSD Performance: TRIM And Firmware Updates Tested

Min kommentar på tom's hardware:

I have a couple of critical comments on the article, which was overall good.

"TRIM is a feature that facilitates the controller’s work. It is a command issued by the operating system and basically enables an SSD to eliminate the garbage collection overhead."

Nope. It reduces GC overhead by eliminating moving of "false valid" pages, correctly marking them as "dirty". Still, there is a overhead from cleaning the dirty pages, which depends on the algorithms and freespace avalible to the controller.

 

TRIM also effectively gives you a second freespace which is dynamical and up to the unused partitioned volume. With the first one being factory reserved.

 

 

"The results clearly show that you definitely want to go with a system that supports TRIM. Although the overall performance levels are almost identical with and without TRIM (‘fresh’ test runs), a SSD without TRIM suffers from severe performance drops if you start torturing it with high-intensity workloads, especially if they involve sequential activity (high capacity) and a large number of I/O operations. This type of torturing may already occur with a few concurrent P2P downloads happening alongside other user activity, although our scenario was designed to be more extreme, of course."

Not the overall performance, but the INITIAL performance is equal. Once the drive reaches steady-state (settles on a performance level dependent on your usage pattern) the difference will be there, but depend on your usage pattern and free partitioned space.

 

Sequential IOs do NOT degrade performance in any notable manner, only if you factor in reducing the avalible dynamic freespace if TRIM is active. In which case, sequential IOs are best-case and will restore drive performance if it overwrites random data.

 

Random write IOs will degrade drive performance by increasing GC overhead, both for systems with and without TRIM, by increasing the fragmentation of dirty LBAs, meaning increased GC overhead. Systems with TRIM will suffer less from random writes since they have more optimal GC by not moving around dirty data and instead cleaning it.

 

P2P workloads are usually semi-random (random within an enclosed LBA space) and the data recieved is typically buffered to be written out in random 128-512KB chunks. This can make them taxing on HDDs, but for SSDs you'd need at least a 100Mbit line at 100% load to impact user experience. Due to the block size being close to Erase-Block size, and files downloaded typically being in one or a few large LBA chunks invalidated all at the same time, they won't cause much degrading and GC overhead.

[Simen1]

Jeg har litt betenkeligheter med å anbefale de minste SF SSDene (dvs 60GB og mindre) da man raskt oppnår steady-state med mindre man kjører flere i raid-0. Det kommer selvsagt også an på bruksmønsteret, hvis mye er statisk er det null problem.

Hvor reelt er egentlig dette? Er det allerede merkbart med tilbakemeldinger på nettet om utslitte SF SSDer? Eller kan man forvente at de holder 3-5 år med normal bruk?

[Anv]

SF baserte SSDene har vel muligens den beste forutsetningen til å leve i 3-5 år, bla pga DuraWrite og kombinasjonen med komprimering, deduplikering ++.

Levetiden er ikke problemet, det er en merkbar degradering av ytelse når man jobber med ikke-komprimerbare data som er problemet.

edit:

egentlig ikke bare ikke-komprimerbare data, ikke-komprimerbare data bare fremskynder steady-state.

 

Grunnen til at degraderingen er så godt merkbar er at de er så utrolig raske frem til dette skjer

Det kunne vært skrevet mye om dette men dette får holde, iallefall i denne omgang.

 

Man kan mao trygt kjøpe en SF SSD til boot-disk.

Endret 25. desember 2010 av Anvil