Ekstrem ytelse på SSD

[Simen1]

Nå begynner det virkelig å skje ting med hastigheter og størrelse på SSD diskene azz !!! Når disse faller i pris, da blir det andre boller!

Det samme sa vi for et par år siden da vi hadde iRam 4GB i PCI-format som kostet ~6000 kr inkludert rambrikkene, og ønsket oss flash-baserte SSD med 16 GB og 50 MB/s for under 2000 kr. Poenget mitt er at man kan sitte på gjerdet og vente på noe bedre til man blir gammel og grå om man vil det. Jeg mener SSD er bra nok i dag til at det er verd prisen selv om det stadig kommer noe bedre og prisene synker.

 

Ja, om 5-10 år så vil jeg ikke tro at hastigheten på hw er noe flaskehals, når det gjelder high-end hw da

Flaskehals betyr at en komponent begrenser ytelsen mer enn andre komponenter. Det går fint an å ha en 10 år gammel PC uten flaskehalser. Altså at maskinvaren er godt balansert slik at ingen enkeltkomponent utpeker seg som vesentlig verre enn andre. Man unngår altså flaskehalser ved at alt er like tregt eller like raskt.

[GullLars]

Men i praksis vil det alltid oppstå flaskehalser pga forskjellige oppdateringsfrekvenser, responstid, og båndbredde blandt delene i maskinen. Dette fører til at en PC som kanskje er perfekt balansert for bruk på skrivebord og lette kontorprogrammer, vil oppleve store flaskehalser i spill (GPU/CPU), en/dekoding (CPU/RAM), flytting av store mengder data (HDD/SSD)... Man kan ikke få et system som er perfekt balansert for alle bruksmønster.

 

Jeg er forøvrig helt enig med Simen1, vi har nådd det punktet der "mainstream" SSD har god nokk ytelse til at det er verdt investeringen for folk flest (selv om mange ikke vet om / forstår det). Kjøper man en SSD til 1000-2000kr nå får man ytelse 5-10x det en hardisk er i stand til å gi, og selv om det vil komme noe som yter dobbelt så bra til samme prisen om 4-6mnd (guesstimate), så er overgangen fra HDD til god nokk SSD mye større enn overgangen fra en god nokk SSD til en dobbelt så bra SSD. Det samme gjentar jeg stadig om raid også. [HDD -> SSD] > [singel SSD -> 2x SSD RAID-0]

[ATWindsor]

Tja, hvilke mainstream SSDer finnes det som ikke har grusom random write? Den eneste jeg vet om er OCZ Vertex, og den er ikke engang ute. Intel sin m-25 såklart, men jeg vet ikke hvor mainstream jeg vil kalle den.

 

AtW

[GullLars]

For øyeblikket har du Vertex, og x25-M. Og snart de som er basert på Samsungs SLC-kontroller (OCZ Summit), men disse taper pris/ytelse mot vertex.

Du har også alle enheter fra Mtron, disse har god nokk random write til at det ikke skjer stuttering eller frysing, og de har veldig bra små block random read, men båndbredde er middelmådig ca 120/100 MB/s. Fordelen med Mtrons SSDer er at degradering er praktisk talt ikke-eksisterende, og det er brukt SLC NAND, så man trenger ikke å tenke over levetid heller uansett bruk.

[ATWindsor]

For øyeblikket har du Vertex, og x25-M. Og snart de som er basert på Samsungs SLC-kontroller (OCZ Summit), men disse taper pris/ytelse mot vertex.

Du har også alle enheter fra Mtron, disse har god nokk random write til at det ikke skjer stuttering eller frysing, og de har veldig bra små block random read, men båndbredde er middelmådig ca 120/100 MB/s. Fordelen med Mtrons SSDer er at degradering er praktisk talt ikke-eksisterende, og det er brukt SLC NAND, så man trenger ikke å tenke over levetid heller uansett bruk.

 

OCZ summit ser også desverre ut til å ha ganske dårlig random write. Og hva gjør at mtron sin degradering er ikke-eksiterende? Har de noe firmware som renser opp? Evt mindre blocks eller liknende?

 

AtW

[GullLars]

Jeg aner ikke nøyaktig hvordan Mtron har klart det. De bruker sin egen kontroller og PCB, så langt jeg har forstått. De er av forgie generasjon, alså samme som Memoright GT, OCZ Core, Samsung SLC (1. gen).

På meg virker det som om Mtron har en liten integrert cache på noen få MB i kontrolleren sin, og ikke har like nazi wear-leveling som intel. Alså, intel sier at forskjellen i wear på deres SSD til en hver tid ikke skal være mer enn 1,1-1,3x, hvis man tillater litt større tall i perioder vil det kunne hjelpe en del på garbage collection og gjøre det lettere å finne tomme blokker å skrive til.

Det er jo naturlig at skiv og tilfeldig skriv vil dette litt når man har brukt omtrent hele kapasiteten slik som jeg har gjort (ca 1GB ledig), men alikevell er det ikke mer enn 5-10% redusert skriv i forhold til da de var nye og "ferske" for over et halvt år siden. Jeg tror den lave ledige kapasiteten har skylden for den reduserte hastigheten. EasyCO har en veldig fin forklaring på dette i deres white-paper på MFT.

[ATWindsor]

Jeg aner ikke nøyaktig hvordan Mtron har klart det. De bruker sin egen kontroller og PCB, så langt jeg har forstått. De er av forgie generasjon, alså samme som Memoright GT, OCZ Core, Samsung SLC (1. gen).

På meg virker det som om Mtron har en liten integrert cache på noen få MB i kontrolleren sin, og ikke har like nazi wear-leveling som intel. Alså, intel sier at forskjellen i wear på deres SSD til en hver tid ikke skal være mer enn 1,1-1,3x, hvis man tillater litt større tall i perioder vil det kunne hjelpe en del på garbage collection og gjøre det lettere å finne tomme blokker å skrive til.

Det er jo naturlig at skiv og tilfeldig skriv vil dette litt når man har brukt omtrent hele kapasiteten slik som jeg har gjort (ca 1GB ledig), men alikevell er det ikke mer enn 5-10% redusert skriv i forhold til da de var nye og "ferske" for over et halvt år siden. Jeg tror den lave ledige kapasiteten har skylden for den reduserte hastigheten. EasyCO har en veldig fin forklaring på dette i deres white-paper på MFT.

'Ok, men de har redusert ytelse som alle andre? Problemet er jo at man etterhvert som det ikke er nok ledige blokker (dvs etter man skrevet hele diskens tilgjengelige lagringskapasitet en gang) så må man rewrite blokker, som tar lengre tid. Det er ihvertfall det jeg renger med skjer, og det harmonerer godt med tregere writes når diksen blir eldre. Det er vel forskjell på hvor mye diskene lider under dette, men alle diskene ser ut til å lide ihvertfall noe. Jeg vet ikke helt hvorfor man ikke bare sorterer alle blokkene når disken er idle dog.

 

AtW

[GullLars]

Foreløpig er det ikke helt mulig (uten overprovisjonering av flashblokker. Blir noe ala shot-stroking på harddisker... man setter av noe ekstra plass til å stokke om blokker). Når ATA Trim etter hvert blir støttet vil det bli mulig.

Foreløpig må man nøye seg med en kombinasjon av write-cache og write attenuation for å holde write accesstime lav. Å slette en SLC-blokk tar bare 0,2 ms å slette en MLC blokk tar 0,9 ms. Selve skrivingen tar en del mindre.

 

I praksis vil det være slik at en SSD vil ha "fresh" fart til hele mediet har blitt skrevet over, og så vil hastigheten reduseres mens ca 2-3x av kapasiteten skrives. Etter hele mediet har blitt skrevet over 5-10 ganger vil man nå den endelige farten man ender opp på, hva denne blir avhenger av kontrolleren, cache, og SLC vs MLC.

Mtron har ikke ekstrem skriv IOPS når den er ny, og mister heller ikke noe særlig over tid. Med bruk av MFT fra EasyCO kan skriv IOPS vedlikeholdes på 50-90% av les IOPS selv når de har blitt brukt lenge, dersom det er noe ledig plass. Siden MFT er software/driver, så tror jeg denne faktisk benytter seg av en form for ATA Trim, pluss write attenuation, og bruker RAM som cache.

Resultatene fra MFT er faktisk såpass gode at 2x Mtron Mobi i RAID-0 er konkurransedyktig med Intel SLC.

[ATWindsor]

Foreløpig er det ikke helt mulig (uten overprovisjonering av flashblokker. Blir noe ala shot-stroking på harddisker... man setter av noe ekstra plass til å stokke om blokker). Når ATA Trim etter hvert blir støttet vil det bli mulig.

Foreløpig må man nøye seg med en kombinasjon av write-cache og write attenuation for å holde write accesstime lav. Å slette en SLC-blokk tar bare 0,2 ms å slette en MLC blokk tar 0,9 ms. Selve skrivingen tar en del mindre.

 

I praksis vil det være slik at en SSD vil ha "fresh" fart til hele mediet har blitt skrevet over, og så vil hastigheten reduseres mens ca 2-3x av kapasiteten skrives. Etter hele mediet har blitt skrevet over 5-10 ganger vil man nå den endelige farten man ender opp på, hva denne blir avhenger av kontrolleren, cache, og SLC vs MLC.

Mtron har ikke ekstrem skriv IOPS når den er ny, og mister heller ikke noe særlig over tid. Med bruk av MFT fra EasyCO kan skriv IOPS vedlikeholdes på 50-90% av les IOPS selv når de har blitt brukt lenge, dersom det er noe ledig plass. Siden MFT er software/driver, så tror jeg denne faktisk benytter seg av en form for ATA Trim, pluss write attenuation, og bruker RAM som cache.

Resultatene fra MFT er faktisk såpass gode at 2x Mtron Mobi i RAID-0 er konkurransedyktig med Intel SLC.

 

ATA trim vil jo bare føre til at man stokker om når man sletter. Jeg skjønner ikke helt hvorfor dette ikke allerede i dag gjøres automatisk når disken idler, så slipper man alt styret med at ytelsen blir dårligere også.

 

AtW

[GullLars]

Det har med filsystem og OS å gjøre. Jeg vet heller ikke hvorfor de ikke kan implementere det ved en oppdatering eller revisjon.

 

Hele problemet består i at OS/filsystemet ikke sier i fra til SSDen hvilke blokker som ikke lenger er gyldig, så alle WRITE komandoer blir RE-WRITE i stedet.

HVIS det er slik at MFT eller lignende software klarer å implementere ATA Trim via software og drivere uten at man trenger å skrive om noe i filsystemet og OS, så er jo det en veldig fin midlertidig løsning. Filsystemet merker jo selv av hvilke LBA'er som er "ugyldige", og hvis en Trim eller lignende kommando gjennom et software/driver-program som leser av LBA status og forteller kontrolleren i SSD at blokken(e) er "skitten", så kan SSDen selv organisere når den ønsker å slette blokker, og hvordan den vil sortere erase-blocks.

Anandtech har en veldig fin artikkel på dette, som også går i dybden på mange andre punkter rundt SSD. Du burde lese den. Det er link til den et par plasser på ca side 95-98 i SSD-tråden, bare skum igjennom så finner du den fort. Det er ca en times lesing, men etterpå vil du vite mye mer om mekanismene i SSD, og ha dypere forståelse for problemstillingene.

[ATWindsor]

Det har med filsystem og OS å gjøre. Jeg vet heller ikke hvorfor de ikke kan implementere det ved en oppdatering eller revisjon.

 

Hele problemet består i at OS/filsystemet ikke sier i fra til SSDen hvilke blokker som ikke lenger er gyldig, så alle WRITE komandoer blir RE-WRITE i stedet.

HVIS det er slik at MFT eller lignende software klarer å implementere ATA Trim via software og drivere uten at man trenger å skrive om noe i filsystemet og OS, så er jo det en veldig fin midlertidig løsning. Filsystemet merker jo selv av hvilke LBA'er som er "ugyldige", og hvis en Trim eller lignende kommando gjennom et software/driver-program som leser av LBA status og forteller kontrolleren i SSD at blokken(e) er "skitten", så kan SSDen selv organisere når den ønsker å slette blokker, og hvordan den vil sortere erase-blocks.

Anandtech har en veldig fin artikkel på dette, som også går i dybden på mange andre punkter rundt SSD. Du burde lese den. Det er link til den et par plasser på ca side 95-98 i SSD-tråden, bare skum igjennom så finner du den fort. Det er ca en times lesing, men etterpå vil du vite mye mer om mekanismene i SSD, og ha dypere forståelse for problemstillingene.

 

Jeg kan ikke skjønne hvorfor det har noe med hverken filsystem eller OS å gjøre (problemet i deg selv). FIlsystemet vet ingenting om hvilke pages som reelt sett er opptatt på en SSD, det er nettopp det som gjør at en SSD fyller seg helt opp før den begynner å skrive til pages som har blitt brukt før. Det er nettopp derfor SSDen bare merker pages som ledig istedet for å slette de helt når den får beskjed fra filsystemt om å gjøre det. Når det derimot ikke er flere helt ledige pages, kun pages som har hatt data på se gfra før, så må SSDen begynne å rewrite, dvs lese all gyldig data innf ra en blokk (som består av mange pages), slette hele blokka, og skrive den gyldige dataen og den nye dataen på nytt. Denne operasjonen tar mye lenger tid enn om man bare kunne fylle tomme pages i en blokk. Grunnen er at du bare kan slette en hel blokk av gangen, ikke en enkelt page.

 

Spørsmålet er, hvorfor kan ikke bare enn SSD som har ledig tid begynne å stokke om på data slik at alle blokker (utenom en) enten har alle pages fulle av reelle data, eller har tomme pages?

 

AtW

[GullLars]

Det er fordi filsystemet sier ikke i fra til SSDen når filer slettes eller blir ugyldige. Og det vil forbli slik frem til filsystem/OS støtter kommandoen ATA Trim. Når det skjer, SÅ kan SSD selv bestemme når den ønsker å slette data. (dette er forklart mer grundig i denne artikkelen)

 

ps:

(problemet i deg selv)

Har du blitt filosof?

[ATWindsor]

Det er fordi filsystemet sier ikke i fra til SSDen når filer slettes eller blir ugyldige. Og det vil forbli slik frem til filsystem/OS støtter kommandoen ATA Trim. Når det skjer, SÅ kan SSD selv bestemme når den ønsker å slette data. (dette er forklart mer grundig i denne artikkelen)

 

ps:

(problemet i deg selv)

Har du blitt filosof?

 

Jeg følger ikke helt? Filsystemet må fører eller senere be SSDen overskrive en logisk blokk.I starten så skriver da SSDen kun data til ledige pages på disken og markerer de pages med dataene som skulle vært overskrevet som ugyldig. Problemet kommer når det ikke er flere ledige blokker igjen, og den må starte å fylle på pages som er i blokker der det er data fra før. Men SSDen vet godt hvilke pages den selv har market som ugylidge. Derfor kan den selv ordne opp når den idler, slik at man igjen får tomme pages samlet i hele blokker. Riktignok vil ikke det hjelpe om du kontinuerlig skriver svært mye, og deretter overskriver, men da hjelper ikke ATA trim noe heller såvidt jeg kan forstå.

 

AtW

[GullLars]

Det stemmer at SSD merker logiske blokker filsystemet ber den om å overskrive som "skitne", men hele poenget her er at filsystemet forteller bare SSDen hvilke blokker det vil overskrive. Filsystemet snakker ikke med SSD når det sletter blokker, det bare merker av i sin egen LBA tabell uten å si i fra til SSD-kontrolleren så den også kan merke av i sin LBA tabell. Dette fører til at når filsystemet har tildelt alle LBA det har tilgjengelig (selv om det er mindre enn SSDen har av fysiske blokker), så vil alle skrivekommandoer SSDen få være overskriving. Med ATA Trim så vil filsystemet si i fra til kontrolleren med en gang når filer blir slettet.

Jeg føler at vi har snakket om to forskjellige ting. Du vil se hva jeg mener hvis du leser artikkelen fra anandtech. Det er en veldig fin forklaring og illustrering der.

 

EDIT: Dersom SSDen har færre logiske blokker enn fysiske (overprovisjonering), så vil den kunne rydde klart fysiske blokker på forhånd, og på den måten unngå å fysisk overskrive blokker selv om det er en overskriv-kommando den mottar.

Endret 22. mars 2009 av GullLars

[Gjest Slettet-Pqy3rC]

Det stemmer at SSD merker logiske blokker filsystemet ber den om å overskrive som "skitne", men hele poenget her er at filsystemet forteller bare SSDen hvilke blokker det vil overskrive.

 

Altså; NTFS (som et eksempel) skriver kun i sin egen FAT tabell at en sektor (logisk blokk) ikke lenger er i bruk og markerer ikke dette på noen måte for lagringsenheten. En harddisk eller SSD vil aldri få vite at sektoren faktisk ikke lenger er i bruk.

Dette medfører følgelig at legringsenheten aldri opplever sletting av data, men kan til slutt oppleve at logiske blokker vil bli overskrevet.

Endret 22. mars 2009 av Slettet-Pqy3rC

[GullLars]

Akkurat det jeg prøver å forklare, men kanskje jeg rusla for mye rundt grøten.

 

Det jeg mente med det sistatet der er at en SSD sletter ikke nødvendigvis en fysisk blokk når den mottar en overskriv-kommando. Dersom det finnes ledige fysiske blokker skriver den til dem i stedet og merker den gamle som skitten, og kan så slette den gamle blokken på et bedre tidspunkt. Som du påpeker oppstår det problemer fordi filsystemet ikke sier i fra til SSDen, og den eneste måten en SSD kan holde hodet skikkelig over vannet er å ha nokk blokker som filsystemet ikke kan få tak i til at den kan rydde unna plass fort nokk. Alså at antallet fysiske blokker er en del større enn antallet logiske blokker. Mtron har rundt 5-10% overprovisjonering, hvis jeg ikke husker feil.

 

Slik reservering av fysiske blokker kombinert med en RAM write-cahce og write attenuation (sammenslåing av mange mindre blokker til større "on the fly") er nødvendig for nyere SSDer for å få gode random write tall. Random write kan videre økes betraktelig dersom filsystemene begynner å støtte ATA Trim, slik at en oppføring i FAT om ugyldig blokker også blir videresendt til SSDen, og effekten av ATA Trim vil være større jo mer ubrukt plass på partisjonen det er.

Status Quo er at selv om det er mye ubrukt plass kan ikke SSDen benytte seg av det, siden den aldri blir fortalt at blokkene er ugyldige før de blir overskrevne.

[ATWindsor]

Akkurat det jeg prøver å forklare, men kanskje jeg rusla for mye rundt grøten.

 

Det jeg mente med det sistatet der er at en SSD sletter ikke nødvendigvis en fysisk blokk når den mottar en overskriv-kommando. Dersom det finnes ledige fysiske blokker skriver den til dem i stedet og merker den gamle som skitten, og kan så slette den gamle blokken på et bedre tidspunkt. Som du påpeker oppstår det problemer fordi filsystemet ikke sier i fra til SSDen, og den eneste måten en SSD kan holde hodet skikkelig over vannet er å ha nokk blokker som filsystemet ikke kan få tak i til at den kan rydde unna plass fort nokk. Alså at antallet fysiske blokker er en del større enn antallet logiske blokker. Mtron har rundt 5-10% overprovisjonering, hvis jeg ikke husker feil.

 

Slik reservering av fysiske blokker kombinert med en RAM write-cahce og write attenuation (sammenslåing av mange mindre blokker til større "on the fly") er nødvendig for nyere SSDer for å få gode random write tall. Random write kan videre økes betraktelig dersom filsystemene begynner å støtte ATA Trim, slik at en oppføring i FAT om ugyldig blokker også blir videresendt til SSDen, og effekten av ATA Trim vil være større jo mer ubrukt plass på partisjonen det er.

Status Quo er at selv om det er mye ubrukt plass kan ikke SSDen benytte seg av det, siden den aldri blir fortalt at blokkene er ugyldige før de blir overskrevne.

 

Men som du er inne på, de fleste SSDer oppgir lavere kapasitet enn de har, derfor kan de jo skrive til ledig plass når de får en overskriv kommando, det jeg ikek skjønner er hvorfor de ikke da, når de er idle, rydder opp i alle pages som er markert som ugyldige. (noe de blir om filsystemet har sendt en overwrite-kommando).

 

AtW

[GullLars]

De fleste "smarte" kontrollere gjør det. De billigste mainstream gjør sansynligvis ikke det (jeg tenker JMicron ja...).

Men som jeg var inne på, med 5-10% av SSDen reservert vil det fortsatt komme et punkt etter en liten stund der sustained write får en knekk dersom SSDen ikke klarer å rydde unna fort nokk. Og selv om det er 5-10% reservert, så vil de 5-10% blokkene som kan ryddes unna fortsatt ikke resultere i perfekt rydding av freespace siden man må organisere erase-block, og det vil koste levetid og veldig mye skriv/slett å være for nazi på det.

 

Akkurat dette med å reservere plass er noe ioDrive har tatt seg god nytte av. Man kan reservere halve plassen mot å få ca dobbel eller mer ytelse i så og si alle scenarioer (bortsett fra webserver) via medfølgende software. Dersom diverse produsenter av vanlige SSDer også hadde lagt med verktøy for å reserver en valgfri prosent av SSDen for nettop å øke skriveytelsen betraktelig, så tror jeg de hadde scoret høyt hos en del brukere. Jeg ville for eksempel gladelig ofret 10-25% lagringskapasitet mot halvert write accesstime (= dobbel random write IOPS), ~10% høyere sustained writes, og lengre levetid på enheten.

Kanskje dette er noe å maile OCZ om og spørre om de kan vurdere?

[ATWindsor]

Egentlig burde det ikke kreve noe spesielt å implmentere det heller, skulle tro man kunne få firmwaren i enheten til å bruke all tilgjengelig plass til den slags, om man bare lager en partisjon som tar vesentlig mindre plass enn enhetens størrelse. Men takk for forklaringen, jeg skjønner litt mer poenget med ATA_trim nå, den (kan) løser problemet med at man overwriter så mye på rad, at den reserverte plassen ikke kan ta unna alt som overwrites. Selv om man også med ata-trim vil få problemet med å ta hensyn til levetid o.l.

 

AtW

[GullLars]

Ja, men Trim vil øke levetiden på MLC som opererer med en del ledig plass og mye skriving betraktelig. Som nevnt, med noen grep går det an å jobbe rundt det, men med den ene kommandoen blir alt mye lettere, og en del billigere SSDer vil bli mye mer holdbare (både levetid, og akseptable til bruk).