SSD-benche tråden: Info og Diskusjon, Tweaking og Benchmarks av SSD

[GullLars]

Minhund har en 980x, og fikk tak i den fra thailand eller noe sånt før de ble sluppet, kanskje han vet?

 

Når det gjelder ekstrem kjøling kan du kanskje høre her på forumet i den kategorien om noen kan skaffe, låne eller sette opp på et treff.

 

Hva fikk du i HDD subscore når du kjørte hele testen? Fortsatt over 100K selv om totalscore var rundt 20K eller under?

[Anv]

Det husker jeg ikke, de testene jeg har kjørt ut over HDD testen var med 2R0 X25-V.

 

Skal sjekke om jeg har tatt vare på skjembilder.

 

Hvis jeg går inn for å få en god score kjøper jeg en 980X og må da få tak en en god kjøling.

Noe under 4.5GHz er det ikke vits i å prøve med, mest sannsynlig må man opp i mer for å bikke 30' i score.

Jeg må i tillegg skaffe et bedre skjermkort, har bare et 5770 og jeg tror det vil lønne seg å ha et 5870, er ikke sikker på hvor mye skjermkort teller?

 

Jeg fikk noen gode priser på litt mer LSI , får det vel kanskje før helga.

[Anv]

Jeg har lest litt i Onfi pdf'en.

 

Jeg ser den er fra 2008, holder det fremdeles stikk det om at NAND ikke skalerer ved økt tetthet?

 

Ser det enda er mye å hente (side 21 og utover) i forhold til hva man får kjøpt i dag. (forbruker SSDer)

[GullLars]

Her kommer posten jeg lovet tidligere, den ble VELDIG lang (beklager?/advarsel;)) så det ble seint og tidlig igjen. Det ble nærmest en liten avhandling

Uansett, here we go

EDIT: Lagt til flere spoilere etter forespørsel fra Theo.

 

Dette inlegget baserer seg på info fra dette dokumentet: http://onfi.org/wp-content/uploads/2009/02/onfi_2_breaks_io_bottleneck.pdf

Og vil også bruke en referanse fra: http://www.haifa.ibm.com/conferences/systor2009/papers/2_2_2.pdf (overfladisk, bilde vil illustrere godt nokk)

Jeg vil også bruke referanser til SandForce's komprimeringsmetode og RAISE.

EDIT2: når jeg begynner å snakker om komprimering og nevner rå båndbredde mener jeg før komprimering/ukomprimert.

 

Dere har kanskje merket jeg har nevnt tidligere at jeg er misfornød med skaleringen av en del SSDer som funksjon av kapasitet, nå har jeg tall fra Micron å referere som grunnlag for mine påstander. Som eksempler kan jeg nevne båndbredde og IOPS ytelse på Indilinx Barefoot 32GB vs 256GB og Intel x25-V vs 80/160GB, disse er forskjellige cases.

 

Utdypning rundt Barefoot og Intel x25, lagt til spoiler.

Indilinx Barefoot er 4-kanals for alle kapasiteter, 32GB versjonen er 4 kanaler med 1 chip pr kanal. 256GB versjonen er 4 kanaler med 8 chips/dies (uvisst) pr kanal. Selve flash chips som blir brukt har samme ytelse, så på laveste nivå har 256GB enheten 8 ganger så mye båndbredde tilgjengelig. Siden antall kanaler er likt er 4KB random read IOPS identisk,

[1/accesstime]*[#kanaler]{1}

og grunnet måten data skrives på er random write IOPS også tilnærmet identisk.

Specs 32GB: ca 180MB/s les, 100MB/s skriv, 15K IOPS les, 3K IOPS skriv.

Specs 256GB: ca 250MB/s les, 200MB/s skriv, 15K IOPS les, 3K IOPS skriv.

Pr GB blir båndbredde;

32GB: 5,6MBps/GB les, 3,1MBps/GB skriv

256GB: 1MBps/GB les, 0,8MBps/GB skriv

 

For Intels enheter er saken noe anderledes siden x25-V har halvert antall kanaler av M, men er ellers lik. Dette skal teoretisk gi M muligheten til ~2x lese IOPS ytelsen av V etter formelen {1} over, i praksis har M opp til 1/3 høyere les IOPS enn V. Skriv IOPS avhenger av degradering, men er opp til 2x høyere, men dette er pga sekvensiell båndbredde tilgjengelig og skrivemetoden, ikke kanaler.

For å liste kort de grove avrundingene jeg bruker under: x25-V; 180MB/s les, 40MB/s skriv. x25-M 80GB; 250MB/s les, 80MB/s skriv. x25-M 160GB 250MB/s les, 100MB/s skriv.

båndbredde pr GB:

x25-V 40GB: 4,5MBps/GB les, 1MBps/GB skriv

x25-M 80GB: 3,1MBps/GB les, 1MBps/GB skriv

x25-M 160GB: 1,6MBps/GB les, 0,6MBps/GB skriv

 

 

Som det går klart av tallene over (i spoileren) for både Indilinx og Intel er skaleringen av les båndbredde ekstremt dårlig hovedsaklig grunnet SATA 3Gbps taket, mens skriv skalerer bedre opp til et visst punkt. Merk, det er ingen tilfeldighet at jeg brukte målestokken MBps/GB som man vanligvis ikke ser, dette er kjernen av hele posten min.

 

 

Så kommer vi til punktet hvor jeg trekker frem diagrammer for å vise dere nøyaktig hva jeg vil ta videre:

Dette bildet viser skaleringen av les og skriv båndbredde som funksjon av antall kanaler og dies pr kanal. Om noen lurer, så er dies er selve NAND halvleder chippen, og man kan ha flere slike i hver pakke (den svarte saken som festes på kretsbordet, vanlig format er TSOP). Vanlig er 2 dies pr package, for økonomiske grunner.

Async (asynchrounous) er gammel protokoll for flash kanaler, Sync (synchronous) er ONFI 2.x protokoll for flash kanaler og støtter høyere båndbredde pr kanal, den har også lavere latency. For mer grundig info, les pdf filen som er linket til i starten av innlegget.

 

 

Så går vi over fra hva er, til hva som kan bli. Bær med meg, dette partiet blir noe tørt med en del tall. Lagt til spoiler.

 

Som dere ser fra diagrammet over klarer en ONFI 2 kanal 200MB/s båndbredde, mens et 2-plane MLC die klarer 88MB/s les, 8MB/s skriv. Illustrasjoner tidligere i pdf filen viser 2 planes av 4GB pr die (om jeg ikke misforstår helt), så det vil si et 2-plane MLC die's rå båndbredde pr GB over ONFI 2 interface er 11MBps/GB les, 1MBps/GB skriv. Vi har altså et 11:1 les:skriv ratio.

 

Ved å videre undersøke tallene finner vi 88*2=176MB/s <200MB/s, som betyr en 2-die package med 2-plane MLC vil ikke bli flaskehalset for les av en ONFI kanal men gir ganske god mettningsgrad for les(88%), mens 3 dies vil 8*3=264 >200MB/s, som vil gi 32% reduksjon i lesebåndbredde, altså ca 1/3 waste.

Skriv båndbredde for en 2-die package på en ONFI 2 kanal blir 16MB/s, bare 8% mettningsgrad. For å dra en invers trenger man 25 dies for å mette èn ONFI 2 kanal for skriv, som gir mulighet for 200GB pr kanal før man begynner å kaste bort skriv båndbredde, dersom høyest mulig kapasitet til lavest kost uten å kaste bort skriv båndbredde er målet. Ved det punktet derimot vil man kaste bort latterlige mengder les båndbredde.

Dette drar meg over på mitt andre hovedpunkt for dette innlegget, praktisk les:skriv ratio.

 

Avhengig av hva SSDen skal brukes til vil man ønske forskjellige les:skriv ratio, og ha forskjellige krav/ønsker til båndbredde, IOPS, kapasitet, og kostnad. Det er her jeg mener en del produsenter har dradd en kraftig fail med deres konsumer-SSDer, mens den eneste jeg gir en med er Intel med x25-V.

Intel får smilefjeset siden de har posisjonert x25-V tydelig som systemdisk (os+core apps), og gir en passende kapasitet til god pris uten å ha noen begrensning på ytelse, det være kunstig i kontroller eller flaskehalser fra fysisk implementering. 40GB er nokk for Windows 7 og mange programmer, 40MB/s skriv er en akseptabel hastighet for en liten og billig systemdisk som skal inneholde hovedsaklig statisk data, og 10K skriv IOPS er godt nokk til at dette ikke blir noen flaskehals. Creds til Intel for å innse dette.

 

Diverse produsenter og forbrukere vil ha forskjellige definisjoner for ønskelig les:skriv ratio (heretter R:W), båndbredde, IOPS, kapasitet, og kostnad avhengig av tiltenkt bruksområde. Dette er et punk jeg mener må fokuseres MYE mer på i kommende generasjoner SSDer, og de må markedsføres tydelig mot bestemte bruksområder/segmenter og klasser innen dem. En systemdisk i en netbook vil f.eks. ha ekstremt forskjellige krav fra en systemdisk i en gamers gaming-rigg, en systemdisk i en powerusers hovedmaskin (flesteparten på XS forumet ), en scratch-disk i en workstation, og en database-disk i en server. For noen av disse vil man antageligvis ønske SLC, som jeg vil komme tilbake til.

 

 

 

I første omgang la oss ta en titt på hva neste generasjon consumer MLC SSDer IMHO bør sikte på (merk: jeg er veldig forsiktig med bruk av ordet bør i slike sammenhenger, og slenger det ikke rundt i tide og utide. "Er -> bør være" går ikke). Dette vil være bruksområder hvor man ønsker lav kost pr GB, god accesstime (<1ms), forholdsvis høyt R:W forhold, og/eller høy kapasitet.

Under dette vil jeg liste følgende bruksområder, lagt til spoiler.

 

*Billig systemdisk med lav kapasitet (f.eks. netbooks, HTPC, og dual drive low-mid end laptops).

*Rask systemdisk med medium kapasitet til lav kost pr GB (f.eks. massemarkedets systemdisker).

*Spill disk.

*Masselagring av aktiv data med høy les-båndbredde, lav accesstime, og/eller mange brukere (f.eks. høy les-last filserver på 1-10GbE, og lagring av VMs for workstation).

*Robust lav-kost eller høy-kapasitet lagring (f.eks. laptopper for felt-bruk, diverse bruk i industri og maskiner, og transport).

*Entusiast über haxorz OMGWTFBBQ briefe lagring (alt skal gå fort! NÅ! )

Om noen har fler tydelig definerte områder, bidra gjerne.

Dere vil se det er bruksområder som ikke er listet her, jeg kommer tilbake til det med SLC, og argumenter for det.

 

 

Så for mine tanker om mer nøyaktige specs for disse kategoriene og rekkevidden for diverse neste generasjon SSDer.

Først vil jeg si at jeg håper alle blir laget med clean block pool skrivemetoden, som Intel, SandForce, og Micron allerede benytter.

Illustrasjon:

Dette er en veldig forenklet versjon, men kort sagt så bruker man logisk->fysisk abstraksjon og streamer logisk tilfeldig plassert data til fysisk sekvensielle plasseringer i klare blokker fordelt over alle kanaler og dies/planes (avhengig av minste uavhengige skriv/slett enhet).Ved å benytte denne metoden med et tilstrekkelig spare area vil man kunne få tilfeldig skriv ca lik sekvensiell skriv, med noe overhead.

Med NCQ, som er den andre absolutte must for neste generasjon som har fler kanaler, vil man kunne unngå økt latency ved blandet les/skriv last ved å kun skrive (eller slette) til kanaler eller dies som ikke har utestående leseoperasjoner så man unngår blocking write/erase.

Jeg vil også nevne kompressjon ala SandForce som et attraktivt alternativ for noen bruksområder, typisk effekt vil variere. Jeg vil arbeide med 2:1 kompressjon som typisk for systemdisk under.

 

 

Med det ute av veien, her er mulige konfigurasjoner med følgende specs jeg tenker meg for diverse områder basert på det første bildet i posten: (notat: kapasiteter som faller inn mellom kanal og die antallene jeg lister kan også lages, jeg lister bare eksempler for å illustrere). Lagt til spoiler.

 

*Billig systemdisk: 1-2 kanaler, 2 dies pr kanal, for 16-32GB med en billig 3Gbps kontroller:

16GB (1 kanal); 176MB/s les, 16MB/s skriv, ca 5K IOPS les, ca 3-4K IOPS skriv.

32GB (2 kanaler); 350MB/S les, mettet SATA 3Gpbs => ca 280MB/s, 32MB/s skriv, ca 10K IOPS les, ca 6-8K IOPS skriv.

 

*Rask systemdisk SATA: 4 kanaler, 2 dies pr kanal, 64GB, SATA 6Gbps kontroller, utgave med kompressjon ala SandForce?

64GB uten kompressjon (4 kanaler); 704MB/s les, mettet SATA 6Gbps => under 600MB/s (ca 560-580?), 64MB/s skriv, 25-30K IOPS les, 15K IOPS skriv.

64GB med kompressjon (4 kanaler); 704MB/s rå les (1400 typisk), mettet SATA 6Gbps -> opp til 600MB/s, 64MB/s rå skriv, 128MB/s typisk, <600MB/s maks (tomme eller >9:1 komprimerbare filer), 25-30K rå IOPS les, 50K(+?) max ved kompressjon?, 15K(-30K typisk/max?) IOPS skriv.

 

*Rask systemdisk PCIe 2.0 x4: 4 kanaler, 2 dies pr kanal 64GB, native bootbar PCIe kontroller, kompressjon ala SandForce:

64GB med kompressjon; 704MB/s rå les, 1400MB/s typisk, opp til 2000MB/s for >= 3:1 komprimerbare filer (mange), begrenset til noe under 1000MB/s maks ved PCIe 1.0 x4. 64MB/s rå skriv, 128MB/s typisk, opp til 2000MB/s for tomme eller >31:1 komprimerbare filer. Altså 64*kompressjon MB/s for skriv. 30-40K rå IOPS les (lavere accesstime enn SATA), 50K(+?) IOPS les for komprimerbare filer. 15K rå IOPS skriv, 30K(+?) for komprimerbare.

 

*Spill disk SATA: 3-4 kanaler, 2-8 dies pr kanal, 48-256GB, SATA 6Gbps kontroller.

48GB (RAID edition? 3 kanaler); 528MB/s les, 48MB/s skriv, 15K IOPS les, 10-12K IOPS skriv.

72GB (3 kanaler); 600MB/s les, 72MB/s skriv, 15K IOPS les, 15-18K IOPS skriv (limit 10K?).

256GB (4 kanaler); 600MB/s les, 256MB/s skriv, 15K IOPS les, 50-60K IOPS skriv (limit 10K?).

 

*Spill disk PCIe: 4-10 kanaler, 2-8 dies pr kanal, 64-512GB, PCIe 2.0 x4.

64GB (4 kanaler); 704MB/s les, 64MB/s skriv, 20-30K IOPS les, 15K IOPS skriv.

256GB (4 kanaler); 800MB/s les, 256MB/s skriv, 20-30K IOPS les, 50-60K IOPS skriv (limit 10K?).

160GB (10 kanaler); 1760MB/s les, 160MB/s skriv, 50-75K IOPS les, 30-40K IOPS skriv (limit?).

640GB (10 kanaler); 2000MB/s les, 640MB/s skriv, 50-75K IOPS les, 120-160K IOPS skriv (limit?).

Idè; bruke 10-kanals versjoner som "Black Edition" uten IOPS begrensning, og begrense IOPS (via NCQ, ikke accesstime eller IOPS ved lav QD) på lavere antall kanal versjoner til et punkt hvor det akkurat er målbart for spill (f.eks. 15-30K IOPS les, 10K IOPS skriv). Tillater bredere bruk for BE, og definerer lavere versjoner tydeligere for spill bruk uten å ødelegge opplevelsen for det bruket. Øker også worst-case levetid (via begrensning av sustained random write), strømbruk, og kontroller klokk krav for lavere #kanal versjoner.

 

*Masselagring av aktiv data SATA/SAS (avhengig av consumer/enterprise målgruppe): 2-8 kanaler, 8-24 dies pr kanal, 128GB-1,5TB, 6Gbps kontroller, RAISE (high-end/enterprise)? Komprimering?

128GB (2 kanaler); 400MB/s les, 128MB/s skriv, 10-15K IOPS les, 25-30K IOPS skriv.

384GB (2 kanaler); 400MB/s les, 384MB/s skriv, 10-15K IOPS les, 80-90K IOPS skriv (limit?).

192GB (3 kanaler) med kompressjon; 600MB/s rå les (eller mer internt for komprimert kan hjelpe på SAS pga færre opptatte flash-kanaler GC, og skriv for full duplex SAS), 192MB/s rå skriv, opp til 600MB/s for komprimerbar skriv (mer internt kan hjelpe SAS pga full duplex), 15-20K IOPS les, 30-40K IOPS rå skriv (mer mulig for komprimert).

512GB (8 kanaler); 600MB/s les (1600 internt tillater mer GC, og skriv for SAS), 512MB/s skriv, 40-60K IOPS les, 100-120K IOPS skriv (limit?).

1,5TB (8 kanaler); 600MB/s les (1600 internt), 600MB/s skriv (1500 internt), 40-60K IOPS les, 100-140K IOPS skriv (mer mulig internt). Note; 1,5TB kan være mulig å få plass til i 2,5" med double stacked NAND på begge sider av PCB selv med 2 dies pr package, det blir 4 i høyden, 4 i bredden, 6 i lengden, 16GB pr package, 4*4*6*16GB=1536GB=1,5TB. Med 3/4 dies pr package burde det gå lett.

 

 

Advarsel; urealistisk drøm:

 

*Entusiast über haxorz OMGWTFBBQ briefe lagring (eller high-end workstation. I praksis lignende et PCIe DAS SAN) PCIe:

"RAID/RAISE/cluster oppsett med 2 kontroller lag, Flash kontroller mot NAND, og Cluster kontroller som jobber mot flash-kontrollerne/modulene ala en RAID kontroller, men ikke med statisk distribusjon over identiske enheter. Muligens 1-2 generasjoner lenger frem før noe slikt blir realistisk å kunne gjennomføre, og da ikke nødvendigvis øknomisk holdbart mot marked...

 

Flash-kontroller/modul: 4-16 kanaler, 2-n dies pr channel, 96-256GB(+), SO-DIMM eller tilsvarende modul med lav latency interface til cluster-kontroller som ser den som èn enhet med LBA pool som støtter NCQ og oppgir antall kanaler og flash type (MLC/SLC for å kunne blande, SLC og MLC, forskjellige kapasiteter, og antall kanaler).

Flash-modul 98GB (6-kanal) SO-DIMM ytelse; 1056MB/s les, 98MB/s skriv, 40-50K IOPS les, 20K IOPS skriv.

Flash-modul 256GB (16-kanal) SO-DIMM ytelse; 3200MB/s les, 256MB/s skriv, 100-150K IOPS les, 50-60K IOPS skriv.

 

Cluster kontroller (multi-core?): 2-8 DIMM busser internt til flash-moduler nevnt over, PCIe 2.0 x4-16 eksternt, Mulighet for (fler?) DDR2/3 (SO?-)DIMM for caching, BBU mulighet. Oppgave; read caching, write caching/coalessing (om BBU er tilstede eller valgt mot advarsel), komprimering (ala SandForce). Mulighet for å bruke moduler av varierende størrelse, antall kanaler, og SLC/MLC sammen pga cluster oppsett og ikke RAID. Data distribuert etter hot/cold metode for les og skriv som standard, med mulighet for prioritering via filter definert av bruker.

Ting å ta fra denne spoileren som kan være realistisk:

*"smarte" Flash-DIMMs (SSD på DIMM-lignende grensesnitt. Rene flash-moduler finnes!)

*RAID kontroller rettet mot SSDer (og/eller HDD) som benytter kompressjon ala SandForce på et høyere nivå direkte fra PCIe buss. En slik kan ha mulighet for å bruke SSD som RAID-aksellerator, og også ha abstraksjonslag over harddisker i RAID-5/6 så data blir komprimert før den når de, dele inn harddiskene i større blokk-strukturer og benytte write-attenuation på deler, prioritere hot-files til SSD, og organisere dataplassering så LBAs som ofte leses nært hverandre i tid er fysisk nære hverandre (hot/cold file tracking), dette siste abstraksjonslaget over HDD vil sansynligvis koste noen % kapasitet. Altså en videreutvikling av ASAP RAID kontrollere (ala Adaptec har allerede) til mer lignende ASAP Rackmount løsninger.

 

 

*Robust lav-kost eller høy-kapasitet lagring blir skreddersydd behov for bruksområder, med selve SSD oppsett lignende muligheter over, men muligens med mer redundans.

 

 

 

Der, da har jeg fått rablet fra meg om MLC og hva jeg mener mangler og kan/bør gjøres. Nå, over til SLC. Her kommer det tilsvarende diagrammet for SLC fra ONFI 2 pdf'en.

Jeg regner halve kapasiteten for SLC i forhold til MLC pr die (håper ikke jeg har lest og bommet hele veien), så det blir 4GB pr die, 120MB/s les 28MB/s skriv pr die for SLC.

Regnet om til MBps/GB blir det 30MBps/GB les og 7MBps/GB skriv. Array-time latency for les er også halvert, for ca 25% høyere les IOPS pr kanal.

 

Lagt til spoiler for hele delen med SLC.

 

Satt opp i forhold til en ONFI 2 kanal blir 2 dies pr kanal 20% waste (240MB/s mulig, men begrenset av 200MB/s kanal), som er akseptabelt når alternativet er 60% mettningsgrad for les og kontroller kompleksitet regnes med. For skriv blir mettningsgraden 14% for kun 1 die, og 28% for 2 dies.

7 dies pr kanal er maks før man metter en kanal for skriv (7*14=98) og setter øverste tak for dies pr kanal for høykapasitets SLC før man sløser skriv båndbredde. På det punktet er tilgjengelig les båndbredde 3,2x høyere enn båndbredden til kanalen, som ikke er SÅ ekstremt mye waste i forhold til tilsvarende for MLC (11x), men siden SLC er grovt 2,5-3x dyrere pr GB enn MLC er det nesten like mye sløst om man regner kr/MB/s les.

Regner man derimot kr/MB/s skriv er SLC faktisk bedre enn MLC (28/8=3,5), man ender alikevell opp med lavere kapasitet for pengene om det teller.

 

R:W for SLC blir (120/28) 4,29:1, om man regner 2 dies pr kanal får man (200/56) 3,57:1. Med tanke på at SLC også har 10x høyere antall skrivesykler er det klart at det egner seg mye bedre for bruksområder hvor det er høy andel skriving, eller krav til høy skriv båndbredde. Responstiden er også lavere, som gjør det ideellt for CPU-aksellerering (mindre dødtid for kraftige prosessorer).

 

De fleste slike bruksområder er server/workstation type arbeid, men det er også noen i prosumer/entusiast segmentet, og en begrenset mulighet for high-end maskiner når de andre komponentene kommer over et visst ytelse og pris nivå.

 

Prosumer og entusiaster vil hovedsaklig trenge SLC til:

*Scratch-disk med høye krav til multitasking/IOPS, god skriv båndbredde, og lavere krav til kapasitet.

*Disk for egne databaser.

*Ikke-statiske hot-files som deles av mange (virtuelle?) brukere.

*Erstatting av 15K SAS RAID for høy båndbredde output/input når en eller fler av strøm/varme/lyd/robusthet/ytelsestetthet er kritisk og budsjettet er løsere (eller alternativer er dyre).

*Testoppsett som må byttes ofte og tid er penger (f.eks. test maskiner for produksjon når det ikke er disk-ytelse som testes).

 

For high-end maskiner (gjerne 3-4Ghz+ Quad eller mer) er SLC et alternativ for å få mer ut av hardware når alternative oppgraderinger er (for) dyre, og accesstime eller skriv båndbredde teller. Det kan oppsummeres til:

*OS

*Core apps

*Hotfiles/temp/pagefile

Alle disse kan plasseres på samme partisjon og vil klare seg greit fra samme type høy/ekstrem-ytelse SSD.

 

 

Her kommer mulige konfigurasjoner for prosumer/entusiast enheter (dette er ikke mitt sterkeste område, så rett meg gjerne). Merk: kapasitetene jeg lister er fysisk NAND, ikke bruker-kapasitet, 10-25% spare area er sansynlig. Ekstrem høy IOPS der det ikke trengs kan også begrenses ved valg av kontroller for pris og strøm sparing, over 50-100K IOPS trengs ikke alle steder.

 

*Scratch-disk (intensiv multitasking/skriv/IOPS, lav-mid kapasitet, budsjett) SATA/SAS: 3-8 kanaler, 2-6 dies pr kanal, 6Gbps.

24GB (3 kanaler); 600MB/s les, 168MB/s skriv, 30K IOPS les, 40K IOPS skriv.

72GB (3 kanaler); 600MB/s les, 504MB/s skriv, 30K IOPS les, 110-120K IOPS skriv.

64GB (8 kanaler); 600MB/s les (1600 intern, fordel for GC og SAS), 448MB/s skriv, 80K IOPS les, 100-110K IOPS skriv.

192GB (8 kanaler); 600MB/s les (1600 intern), 600MB/s skriv (1344 intern), 80K IOPS les, 120-140K IOPS skriv (300K+ teoretisk mulig intern).

 

*Scratch-disk lav-mid kapasitet, high-end, PCIe 2.0 x4: 5-10 kanaler, 1-6 dies pr kanal, 20-240GB.

40GB (5 kanaler); 1000MB/s les, 280MB/s skriv, 50K IOPS les, 60-65K IOPS skriv.

120GB (5 kanaler); 1000MB/s les, 840MB/s skriv, 50K IOPS les, 200-210K IOPS skriv.

80GB (10 kanaler); 2000MB/s les, 560MB/s skriv, 100K IOPS les, 120-130K IOPS skriv.

240GB (10 kanaler); 2000MB/s les, 1680MB/s skriv, 100K IOPS les, opp til 400K+ IOPS skriv mulig.

 

*Disk for egne databaser SATA/SAS: 5-10 kanaler, 1-2 dies pr kanal, 20-80GB.

20GB (5 kanaler); 600MB/s les, 140MB/s skriv, 50K IOPS les, 30K IOPS skriv.

40GB (5 kanaler); 600MB/s les (1000 intern), 280MB/s skriv, 50K IOPS les, 60-65K IOPS skriv.

40GB (10 kanaler); 600MB/s les (1200 intern), 280MB/s skriv, 100K IOPS les, 60-65K IOPS skriv.

80GB (10 kanaler); 600MB/s les (2000 intern), 560MB/s skriv, 100K IOPS les, 120-130K IOPS skriv.

 

*Databaser PCIe 2.0 x4-8: 10-20 kanaler, 1-2 dies pr kanal, 40-160GB.

80GB (10 kanaler); 2000MB/s les, 560MB/s skriv, 100K IOPS les, 130K IOPS skriv.

80GB (20 kanaler); 2400MB/s les, 560MB/s skriv, 200K IOPS les, 130K IOPS skriv.

 

*Ikke-statiske hot-files: Samme som Scratch-disk over.

 

*Erstatting av 15K SAS RAID: Samme som scratch-disk, om MLC, eller MLC RAID ikke holder.

 

*Testoppsett: Samme some scratch-disk men med komprimering.

 

 

Jeg bestemte meg for å sette denne i egen spoier.

Mulig konfigurasjoner for high-end maskin systemdisk (OS, apps, hot/temp/pagefile):

 

4-8R0 SATA/SAS 3-kanal, 2 dies pr kanal = 24GB*4-8=96-192GB. RAID kontroller på PCIe 2.0 x16 med kompressjon.

96GB RAID; 2400MB/s les rå, typisk 4800MB/s, opp til 8GB/s for 3,3:1 kompressjon. 670MB/s skriv rå, 1340 typisk, opp til 8GB/s for 12:1 kompressjon (eller tom fil). 100-120K IOPS les rå (mer mulig med kompressjon), 130-150K IOPS skriv (mer mulig med kompressjon).

192GB RAID; 4800MB/s les rå, max PCIe typisk (1,66:1 kompressjon). 1340MB/s rå skriv, 2680MB/s typisk, opp til 8GB/s for 6:1 kompressjon (eller tom fil). :dribble:

Forutsatt 3x kost av SLC i forhold til MLC, vil 60kr/GB + RAID kontroller være et overhånd estimat. 60kr*96GB=5700 for 4x24GB SLC, og så 4-port RAID kontroller til 3000-4000? Det skal være mulig under 10.000, eller $1500. For steve/mike blir $2500 for imaginært 192GB oppsett også en vurdering (med tanke på hva steve ga for 6 Acard).

 

 

For en mer budsjett-vennlig entusiast/high-end systemdisk kan jeg forestille meg en native PCIe 2.0 x16 med kompressjon og hybrid MLC/SLC med 8 kanaler for MLC med 2 dies pr kanal (128GB), og 4 kanaler for SLC med 2 dies pr kanal (32GB). Det blir da som et internt JBOD oppsett der kontrolleren styrer hva som havner hvor, der skriv-"kalde" LBA havner på MLC og "varme" på SLC.

Rå hastigheter for hver del:

MLC (128GB): 1400MB/s rå les, 128MB/s rå skriv, 40-60K rå IOPS les, 25-30K IOPS rå skriv.

SLC (32GB): 800MB/s rå les, 224MB/s rå skriv, 40K rå IOPS les, 50K rå IOPS skriv.

Aggregat (160GB): 2200MB/s rå les, 350MB/s skriv, 80-100K rå IOPS les, 75-80K rå IOPS skriv. Legg på det grovt 2x typsik kompressjon for C: (samme ytelses økning faktor), og opp til 8GB/s (eller kontroller max) for kraftig komprimerbare eller tomme filer.

128GB@20kr/GB (2500) + 32GB@60kr/GB (1900) + ~250-500kr for kontroller = ca 4500-5000kr. Det samme som jeg ga for 32GB Mtron Pro i august 2008, billigere enn x25-M G1 80GB (før G2 kom ut).

Selv om en slik kontroller koster 1000kr, og man slenger på 1000kr en DDR2 (SO?-)DIMM for read-cache med mulighet for write cache/coalessing med BBU (800kr for 4GB DDR2 valueRAM, pris på BBU???) blir ikke prisen så galen når man ser på ytelsen man får, og kapasitet som holder for OS, apps, og hotfiles/temp/pagefile. Muligens til og med spill og plass til litt scratch-disk type arbeid?

 

 

Jeg tenker jeg kunne kost meg på en ren PCIe 2.0 x8/16 med 8 kanaler SLC 2 dies pr kanal og kompressjon. Kapasitet 64GB (jeg trenger ikke mer, for øyeblikket er jeg rundt 35GiB på C).

64GB; 1600MB/s rå les, 450MB/s rå skriv, 80K rå IOPS les, 100K rå IOPS skriv (gjerne limit 20-30K sustained, altså i snitt over 10+ sekunder, altså fri fart for første 100-300K IO's, deretter limit til 10-30K IOPS skriv). Pris gjerne 5-6000kr + ekstra kost for DDR2 DIMM read-only cache for read-ahead + hotfiles, MEN bootable er must.

 

 

 

 

Så, nå har jeg fått rabbla fra meg og gitt dere hodepine og dysleksi her. Når dere har fått igjen pusten vil jeg gjerne vite hva dere synes

Selv har jeg tanken, når jeg skal oversette, skrive om/legge til noe, og poste på XS forum, så kanskje jeg skal lage eksempel arkitekturer med specs i excell/OOO calc tabeller og poste screenshots... Jeg har også mistanke om at jeg mistet tråden et par ganger underveis, påpek gjerne hvor og hva.

 

EDIT: Alle tallene brukt ved estimater her er tatt fra ONFI 2 pdf'en, om tallene viser seg å være feil, kom gjerne med de riktige. Jeg mistenker at sekvensiell skriv muligens kan være for lav for 3xnm og kommende 2xnm flash med 8KB pages.

Endret 7. mai 2010 av GullLars

[BAT]

Dette må være ny rekord i lang post

 

Veldig bra GullLars!!

 

Nå trenger jeg bare et par dager på å forstå innholdet

[GullLars]

Wall of Text crits you for >9K (OVER 9000!!!)

 

Men helt seriøst, den er 3651 ord...

Førsteposten i SSD-tråden er 4265 ord...

Førsteposten i SSD-benche tråden er 2481 ord.

Andreposten i SSD-benche tråden (tweak guiden) er 1100 ord...

 

Slår jeg sammen førsteposten i SSD-tråden med posten over, og så legger til grafer og diagrammer fra "Random read 0,5-64KB QD-128" prosjektet og diskuterer rundt det har jeg en avhandling på over 10.000 ord XD

 

Prøver du å summere opp alle innleggene mine i SSD-tråden + SSD-benche tråden tror jeg du lett passerer 100.000

Endret 6. mai 2010 av GullLars

[Nizzen]

Anvil: 

 

 

 

 

LSI MegaRAID 9260 new firmware 12.6.0-0017(APP-2.60.03-0829)

 

 

 

 

Nå må du teste enda mere 

 

 

[GullLars]

Leste det nettop på XS.

Bug Fixes and Enhancements:

===========================

Enhancements:

Add support for Advanced Software Options from LSI including:

• LSI™ MegaRAID® CacheCade™

• LSI™ MegaRAID® FastPath™

• LSI™ MegaRAID® Recovery

• LSI™ MegaRAID SafeStore™

 

Other firmware enhancements:

LSIP200036035 AEN for CacheCade size change

LSIP200036030 SAS Firmware to store the TTY log into Flash ROM and allow OEM tools to capture it.

LSIP200011688 CacheCade Configuration Management

LSIP200008528 Add the structure in the HWR FW to store the Tape device information.

 

 

Firmware bug fixes:

 

LSIP200044702 10M03 FW goes to megamon when powering on/off 2nd enclosure

LSIP200044921 10M03 FW fails to set mfc value TREAT R1E AS R10

LSIP200053959 After migrating from R6 to R5 the VD IO policy canges from DIO to CIO.

LSIP200018573 CacheCade wording

LSIP200018810 After double rebuild on R6/R60 in a single span with 254 medium errors, one of the rebuilt pds is fa

LSIP200043202 Drives missing show zero capacity during post on Wasat and FW 12.3.0-0022

LSIP200043817 FW goes into Montask when trying to import an invalid Foreign configuration

LSIP200043859 CacheCade properties can be changed using MSM

LSIP200043881 Configurations containg 3 VD's can be imported on Low cost iMR controller with out issues during auto-import.

LSIP200044127 CacheCade is cached for a Secure VD

LSIP200044178 VPD is not working with vendorId/deviceId 1000/0079, SubOem 1,subVendorId/subDeviceId 1000/9280

LSIP200044289 Running io program on 63VD and 1CacheCade caused OCR

LSIP200044342 spinup parameters are hard coded & not used from nvdata

LSIP200044467 Data miscompares reported on 256K optimal R6 VD with special IO

LSIP200044615 Too many unexpected sense events for powered down SATA drives

LSIP200044647 Fix missing changes from 09M11

 

Har du noen tanker om den lange posten over Nizzen?

[Nizzen]

Har ikkje lest enda. For mye tekst og for lite bilder for min smak 

 

 

 

 

Du kunne i det minste lagt ved et bilde av en pupp eller.no 

 

 

[Anv]

GullLars,

Må lese det litt senere i kveld.

Ser spennende ut, men det var mye

 

Nizzen,

Hehe, har for mye å gjøre nå.

Ser ikke noe om ytelsesforbedringer men skal få sett på det etter hvert.

Endret 6. mai 2010 av Anvil

[Anv]

GullLars,

 

Interessant å se MBps/GB vinklingen når man har lest Onfi artikkelen på forhånd.

 

Veldig mye lesing

 

Jeg tror jeg jeg enten ville ha kuttet ned på fokuseringen på pro segmentet og holdt meg til målgruppen som i prinsippet er en eller annen type entusiast,

eller delt det inn slik at man ikke får så mange blandinger av inntrykk på en gang.

 

Det hadde vært enklere å lest dette hvis det ikke var så mye blanding av enkelt og teknisk stoff.

Dette er løsbart rett og slett ved å dele det inn i grunnleggende og tekniske deler.

(vil stort sett bare være snakk om litt flytting/omstokking av paragrafer)

 

Overskrifter som

-Innledning

-Skalering

-Billig SSD

-Normal SSD

-Rask/Spill SSD

-Entusiast SSD

-RAID (som i prinsippet kan være array av hvilket som helst av punktene over)

 

ville ha ledet leseren direkte til sitt segment.

(dette er bare eksempler som ville ha fenget bedre)

 

Som du selv er inne på så trenger det litt flere illustrasjoner/grafer som erstatning for oppramsinger av typen.

f.eks.

64GB (4 kanaler); 704MB/s les, 64MB/s skriv, 20-30K IOPS les, 15K IOPS skriv.

256GB (4 kanaler); 800MB/s les, 256MB/s skriv, 20-30K IOPS les, 50-60K IOPS skriv (limit 10K?).

160GB (10 kanaler); 1760MB/s les, 160MB/s skriv, 50-75K IOPS les, 30-40K IOPS skriv (limit?).

640GB (10 kanaler); 2000MB/s les, 640MB/s skriv, 50-75K IOPS les, 120-160K IOPS skriv (limit?).

 

--

 

Mitt ønske er egentlig ikke mer iops som sådan men økt iops ved lav QD, det er det man vil merke mest av i praksis.

Hybrid MLC/SLC har jeg litt tro på.

 

Ellers var det noen få plasser hvor det virker som du har slitt ut tastaturet underveis

(hoppet over noen bokstaver og tall i regnestykker)

Endret 6. mai 2010 av Anvil

[GullLars]

Det jeg skreiv her var hovedsaklig høylytt tenking jeg ville dele med deg, nizzen, ourasi, jkjk, osv. som har en del peil på SSD. Det kan bli sett på som et førsteutkast for en mer rafinert versjon.

 

Som du fikk meg deg var det største poenget jeg hadde MBps/GB for les og skriv. Et annet sentralt punkt var Les:skriv forhold.

For andre som ble forvirret av posten eller gav seg underveis kan jeg liste de andre større punktene:

 

*SSDer må målrettes mot bruksområde, ikke bare kapasitet/ytelse/pris segmenter. Balansen mellom disse er kritisk for å få nyttige proukter.

 

*Systemdisker har generelt ikke stort behov for skriv båndbredde, og har grove punkter hvor IOPS ytelse er "god nokk", avhengig av resten av systemet.

For å liste noen tall som jeg (edit)ikke skrev spesifikt om men innrammet i eksemplene, følgende tall gjelder systemdisker (OS, apps, temp/pagefile):

 

10K 4KB random IOPS skriv sustained (forutsatt lav snitt latancy og ikke for høy max latency spikes) er "godt nokk" for praktisk talt alle systemdisker, høyere er greit om det ikke går på bekostning av andre ting, men er ikke nødvendig.

10-50K 4KB random read IOPS avhengig av CPU og bruksmønsteret. En netbook med <2Ghz dualcore vil klare seg greit med 10-15K IOPS, mens powerusers med 3-4Ghz+ 4 kjerner eller mer vil kunne merke forskjell opp til grovt 50K (etter det blir det diminishing returns). For sistnevnte blir også accesstime (IOPS ved lav QD) viktigere enn max IOPS etter man passerer grovt 50K.

Sekvensiell skriv er akseptabelt i område 20-200MB/s fra netbooks til high-end stasjonære. Høyere blir lite vits siden det meste er statisk data, og man trenger i tillegg andre SSDer eller RAID for å god nytte av det i de fleste tilfeller.

Sekvensiell les blir det eneste punktet hvor "jo mer jo bedre" holder. Opp til rundt 200-300MB/s for netbooks/HTPC (derav foreslått 3Gbps i posten tidligere), opp til 500-600MB/s for vanlige stasjonære, og enda høyere for high-end maskiner (ikke alle ting, men noe vil tjene på mer båndbredde).

 

 

*MLC holder lenge for massemarkedet, SLC er aktuelt for entusiasters systemdisker og for bruk i workstation/server.

 

*Kontroller kompleksistet vil påvirke kostnad, og med godt laget SSDer trenger man ikke gå over 3-5 kanaler for å få god ytelse.

 

*Kapasitet koster, og man kjøper SSD for ytelsen, ikke kapasiteten. Kapasitet er et sekundært mål, og her gjelder også at bruksområder har "nokk kapasitet" hvor mer er lite interresant eller sløsing.

 

*"Clean block pool writing method" som vist i andre bildet må bli standard for å holde write amplification lav, og gir også mulighet for veldig høy random write IOPS på en energi-effektiv måte.

 

*SATA 6Gbps vil bli nødvendig for alt over laveste kapasitet & ytelse low-end systemdisker (ala netbooks/HTPC).

 

*SAS 6Gbps vil være interressant for high-end og workstations, siden den overflødige les båndbredden vil tillate mixed les/skriv workload å overgå 600MB/s i total båndbredde siden det er mer tilgjengelig intern båndbredde til over for skriv etter grensesnittet er makset for lesing.

 

*PCIe 2.0 x4 er aktuelt for mid-high end systemdisker pga lavere latency og høyere enn 600MB/s les båndbredde (uten å benytte RAID).

 

*Komprimering ala SandForce er veldig aktuelt for systemdisker, i alle segmenter. Det gir økt effektivt spare area og vil øke levetid, latency kan også reduseres, og skriv båndbredde som er lavt fra MLC kan få en billig boost med typisk ca 2x og opp til 10-20x for visse filer. Dette tillater bruk en kontroller med færre kanaler å levere tilfredsstillende/god ytelse.

 

 

 

Når du nevner IOPS ved lav QD, en mid-high end PCIe SSD med komprimering og blanding av SLC og MLC kan plassere statisk data som leses sekvensielt på MLC, og la små hot-files være på SLC. Et par kanaler med SLC vil også booste tilgjengelig skriv båndbredde, og SSD kontrollere kan selv last-balansere sømløst over blanding av SLC og MLC. Mulighet for å putte i en DDR2/3 (SO?)DIMM på en slik, om enn bare for read-caching (read ahead + hotfiles + nylig skrevet?) kan hjelpe godt for high-end.

 

Når man benytter clean block pool skrive metoden får man god nokk random write uansett uten behov for stor write-cache. Om opp til 1-2MB brukerdata kan holdes i cache bakket opp av et par caps vil det holde lenge og gi lav latency om det regnes som skrevet når det treffer nevnte cache.

 

Kunstig begrensning av sustained random write til f.eks. 10K (som er "godt nokk") er også et interresant punkt for levetid og strømbruk, men implementert til å tillate bursts opp til 100K IO's med maks fart i løpet av opp til 10 seuknder før begrensningen slår inn vil gi bedre random write accesstime og ytelse for små til middels mengder random write bursts.

Endret 7. mai 2010 av GullLars

[Anv]

GullLars,

 

Mine tanker var basert på at du skulle publisere den på en eller annen måte.

 

Innholdet er helt supert, bare litt mye hopping frem og tilbake.

 

Jeg tror du har rett i mange av dine antagelser med tanke på fremtidig teknologi, jeg tror vi får et mangfold av løsninger som i større grad vil tilfredsstille forskjellige målgrupper.

 

Målgruppene er egentlig det viktigste her (både når det gjelder valg av SSD og lesing av artikkelen) derav sier jeg en eller annen type entusiast når jeg beskriver leseren.

 

Med tanke på fremtiden er jeg spent på hva Intel kommer til å gjøre, de har utvilsomt fått litt å tenke på etter at SandForce kom inn i bildet med komprimering.

Den nye E serien til Intel er sagt å være MLC basert, det kan selvsagt hende at de kommer med noen SLC varianter også men fokus ser ut til å gå i retning MLC.

Spørsmålet er om de klarer å øke MLC's levetid eller om de løser dette med avanserte teknikker eller en kombinasjon av dette. Dagens MLC ser ut til å tåle rundt 10' "sykler" men det snakkes om 2-3 ganger økning av dette.

 

Jeg har litt vansker med å se hvordan komprimeringen (på det jevne) kan være 2:1 eller mer.

Ikke fordi det ikke er mulig (det er fullt mulig når man komprimerer filer i filsystemet) men med tanke på hvor fort dette skjer i SandForce tror jeg de kanskje har en lavere grad av komprimering enn man tror når det er "ekte" data inne i bildet, dvs ikke bare "tomme" data.

De bruker selvsagt en optimalisert "prosessor" for dette arbeidet i SF kontrolleren til dette, hardware basert/assistert komprimering yter selvsagt bedre enn det man opplever i OS når man direkte pakker eller pakker ut filer.

Selv med en lett komprimering vil man redusere "wear" og samtidig øke den reelle "båndbredden".

Det hadde vært interessant å hatt en interface mot SF kontrolleren for å lese av reelle verdier som f.eks brukt plass vs rapportert ledig kapasitet.

 

Som en systemdisk kan nok reell komprimering være i nærheten av 2:1 men straks man begynner å lagre bilder/film og noe så enkelt som Office dokumenter (som er komprimert med zip internt) faller denne til 1:1.

 

For databaser er komprimeringsforholdet/potensialet gigantisk.

Mange databaser kan komprimeres 20:1 (5% av original størrelse) og da begynner det å bli interessant.

Nå tror jeg fremdeles ikke at de komprimmerer maksimalt men heller velger en gylden middelvei rett og slett for å holde hastigheten oppe. Uansett vil databaser kunne komprimeres med et mye større forhold enn andre data.

 

Forholdet avhenger selvsagt av hvilke opplysninger som lagres i databasen men for tradisjonelle databaser som ikke lagrer multimedia relatert innhold er potensialet stort.

 

Det eneste som kan ødelegge dette forholdet er selvsagt krypterte data på generell basis.

(noe som stadig dukker opp)

 

fortsettelse...

 

Jeg tror fokus for mange er å få mer plass på SSDen, dagens SSD'er er rett og slett for små for power users og man tyr dermed flere SSDer som ofte havner i raid.

Dette funker godt på stasjonære pc'er men er ikke noe alternativ i bærbare. På bærbare går det i retning av at leverandørene tilbyr miniPCIE baserte SSD'er for OS og den tradisjonelle HDD'en kan da leve videre for de som nøyer seg med SSD ytelse på OS.

De mest ekstreme vil selvsagt ha SSD begge plasser.

Jeg er enig i at 64GB er en fin størrelse for systemdisken, i praksis bruker mine OS partisjoner langt mindre enn dette. (15-20GB i mitt tilfelle, som er litt sært)

Man må da selvsagt ha flere lagringsmedier for å løse plassproblematikken.

 

Det er mulig at 34nm har samme ytelse/tetthet men jeg undrer litt på hva som skjer med 25nm i og med at de endrer til 8KB page size.

Endret 7. mai 2010 av Anvil

[GullLars]

Som du sier var mål-audiensen til inlegget mitt her i tråden entusiaster, siden jeg ville diskutere dette med dere på et avansert nivå for å få best mulig kritikk på mest mulig av det jeg har av tanker og som vil inngå i tankeprosessen min fremover. Jeg hadde ingen planer om å publisere dette på noen måte, men det kan havne bak noen andre ting i køen over hva jeg kan skrive på en måte som kan publiseres.

Forran i køen ligger en slags intro til SSD for de som ennå ikke har satt seg inn (folk flest med generell datakunskap).

En oversikt over SSD markedet slik det er i dag og litt tid tilbake og utsikter i nær fremtid.

Samarbeid med nilsen og co. om en artikkel på SSD ytelsesgradering.

Og så vil også en eller fler tråder på XS for SSD benchmarking og samarbeid få noe prioritet.

 

 

Når det gjelder SSD og kapasitet så listet jeg ganske romslige kapasiteter (lang range, lav til høy), men fokuserte på å ikke liste kapasiteter som vil gi unødvendig dyrt kontrollerdesign eller kaste bort mye ytelse. For "folk flest" sine stasjonære maskiner vil en liten til middels kapasitet systemdisk SSD (32-100GB) være all flash de trenger i systemet med snurredisker til resten. Entusiaster og powerusers vil være tjent med en blanding med forskjellige volumer. Dedikert OS singel drive, singel eller RAID for masselagring med høye krav, spill, databaser, VMs, scratch-disk, etc, og snurredisker for langtids masselagring.

 

I laptopper blir situasjonen noe anderledes, og der vil jeg også legge skyld på maskin-produsenter/designere. ALLE laptopper på 15" eller mer som slippes i 2010 burde ha 2 2,5" brønner.

En annen løsning er lav-profil PCIe SSDer (ala grafikk-kort, ikke mini-PCIe x1) for mindre formfaktor laptopper når mer ytelse og/eller kapasitet trengs og det ikke er annledning til fler 2,5" brønner. Et annet problem med mini-SSDer har også vært at de har brukt IDE/ZIF grensesnitt enten eksternt eller internt.

 

En løsning for mer high-end laptopper som allerede er sluppet og kun har èn diskbrønn er en SSD-serie som ligner mer på dagens og makser SATA 3Gbps ved les for alle kapasiteter (start 32GB) og skalerer til 1TB kapasitet og makser grensesnittet for skriv fra 256GB versjonen, muligens lavere kapasiteter for versjoner med kompressjon.

 

 

Hybrid SLC/MLC er også noe jeg gjerne vil diskutere mer fremover, siden det bør være greit nokk å implementere siden noen SSD kontrollere allerede har justerbar ECC, skriv granularitet, fitt valg til skriveplassering, og flash-kanal typen er identisk. Spørsmålet er vell bare om selve flash identifiserer seg som SLC/MLC for kontrolleren. Om ikke kan kontrolleren alikevell selv lages så den kjører en kjapp benchmark til hver flash device etter enheten er montert sammen og skrudd på (altså før den forlater fabrikken). Bruk av en større DDR2/3 read-cache (separat enkel chip/chips, ikke DIMM) er også en interresant mulighet. Med grovt 150-250kr/GB for RAM om dagen (avhengig av hastighet og tetthet) er ikke 512MB-2GB RAM for caching av hotfiles og read-ahead en dum ide for en del bruksområder, spesielt ikke for høyere kapasiteter.

Jeg ser for meg at noe ala 32-128:4-16:1 forhold for MLC:SLC:RAM kan være aktuelt. Rå priser ligger jo rundt MLC; 15kr/GB, SLC; 35-50kr/GB, RAM; 150-250kr/GB.

Kost forhold mellom delene for en veldig "fet" SSD med f.eks. for database/high-end systemdisk) med MLC:SLC:RAM forhold 32:16:1 blir om man regner high-end SLC og RAM; 1,9:3,2:1 og low-end SLC og RAM; 3,2:3,7:1.

Kost forhold mellom delene for en mindre "fet" SSD (f.eks. for mid-end systemdisk) med MLC:SLC:RAM forhold 128:4:1 og low-end SLC/RAM; 13,7:1:1,1 (SLC+RAM blir da ca 15% av totalkost for lagringskapasiteten, mindre medregnet PCB og kontroller).

[Theo343]

Bruke spoilers litt kanskje?

[GullLars]

OK, jeg legger til flere spoilere nå

Endret 7. mai 2010 av GullLars

[Anv]

Har sjekket den nye firmwaren til LSI og det er ikke værre.

 

Har satt på en iometer med 2R0 Intel G2 160GB WT, legger den ut enten i kveld eller i morgen.

 

FastPath ser ut til å koste $160, om det er til forhandler eller forbruker vet jeg ikke men den skal jeg ha

 

Kort beskrivelse av FastPath

"LSI MegaRAID FastPath optimization software provides a high performance I/O accelerator, designed to dramatically boost transactional application throughput of multiple SSDs connected to a 6Gb/s SATA+SAS MegaRAID controller. FastPath supports full optimization of SSD Virtual Disk groups to deliver a 3X improvement in read and write I/Os per second (IOPS) compared to the previous generation product."

 

Areca får det ikke enkelt, eller kanskje de har noe lignende på lur?

[Nizzen]

Har sjekket den nye firmwaren til LSI og det er ikke værre.

 

Har satt på en iometer med 2R0 Intel G2 160GB WT, legger den ut enten i kveld eller i morgen.

 

FastPath ser ut til å koste $160, om det er til forhandler eller forbruker vet jeg ikke men den skal jeg ha

 

Kort beskrivelse av FastPath

"LSI MegaRAID FastPath optimization software provides a high performance I/O accelerator, designed to dramatically boost transactional application throughput of multiple SSDs connected to a 6Gb/s SATA+SAS MegaRAID controller. FastPath supports full optimization of SSD Virtual Disk groups to deliver a 3X improvement in read and write I/Os per second (IOPS) compared to the previous generation product."

 

Areca får det ikke enkelt, eller kanskje de har noe lignende på lur?

 

Når jeg leste at det koster ca 160$ så er det lett verd pengene om det fungerer bra. LSI blir bare mere og mere interresant!

 

 

Synn de ikkje kan ha 4gb cache i tillegg. Da hadde det blitt et "must have" 

 

 

 

 

Litt nedtur med 512mb VS 2gb som jeg har på areca. 512mb har jeg på min gamle Adaptec 31205 

 

 

[Anv]

Nizzen,

 

Den slippes for salg 10 mai, da er det bare å lete etter noen som selger.

Det er bare en KEY man trenger så det er mulig man kan kjøpe det online fra utlandet.

 

Blir morsomt å se hvor bra det funker.

[Anv]

GullLars,

 

Her er ny kjøring på 9260 med 2R0 Intel X25-M, du kan jo prøve å sammenligne med tidligere kjøringer

Max iops ser ut til å være forbedret med WB og muligens litt med WT men ikke mye.

 

Det er 3 kjøringer

WB og WT QD 1-64

WT QD 1-128

 

2R0_X25M_G2_160GB_92608I-NFW.zip

 

(godt brukt array, som for en gangs skyld er på 128KB stripe size)

Endret 8. mai 2010 av Anvil