2 TB SSD

[Hugo_Hardnuts]

Du skriver at det allerede finnes 6GB/s SAS-kontrollere på markedet, men sånn jeg forstod svaret på et av mine spørsmål her tidligere, så betyr det da at kontrolleren kan overføre med denne kapasiteten totalt, og at hastigheten pr lagringsenhet fortsatt er begrenset til 300(evt. 600)MB/s...eller?

 

Sånn det ser ut i mine øyne er det litt en situasjon her der utviklingen av SSD har løpt litt i fra og at vi mangler en ny, praktisk anvendelig standard for kommunikasjon mellom lagringsenhetene og resten av systemet. Jeg ser i hvertfall ikke enheter som plugges direkte i PCI-E-portene som noen særlig god løsning.

 

Hadde du gittet å oppgi hva IOPS og QD står for, så skal jeg prøve å google meg frem til litt mer kunnskap om hvordan lagringsmedier fungerer? Er nemlig ikke helt dreven i det her...

[Gjest medlem-135366]

Skriv din kommentar.... Hm. Hva med sikkerheten? Hva hvis én av SSD enhetene på PCIe kortet skulle ryke. Så vidt jeg forstår er de kobblet sammen i RAID 0.

 

Så er det prisen. Prisen er egentlig lav. Skulle du sette sammen 2TB så trenger du 8 stykk 250GB SSDer hvis de kobbles i RAID 0. La oss si at du da kjøper kvalitet til kr 5.000,- pr stykk Da betaler du kr 40.000,- + en RAID controller til kr 5.000,- og da er vi oppe i ca kr 45.000,-. Da er ikke denne prisen ille.

 

Konklusjon. Dette er slett ikke verst mht til pris. Skal jeg bruke denne i en server, bør det gå ann å kobble de interne SSD diskene i dette PCIe kortet i RAID 10 eller 01 for striping og speiling. Det ville ha gitt en kapaitet på det halve, men da med nødvendig sikkerhet. Skal dette bli et seriøst alternativ må det gå ann å kobble denne i RAID.

[GullLars]

Du skriver at det allerede finnes 6GB/s SAS-kontrollere på markedet, men sånn jeg forstod svaret på et av mine spørsmål her tidligere, så betyr det da at kontrolleren kan overføre med denne kapasiteten totalt, og at hastigheten pr lagringsenhet fortsatt er begrenset til 300(evt. 600)MB/s...eller?

 

Sånn det ser ut i mine øyne er det litt en situasjon her der utviklingen av SSD har løpt litt i fra og at vi mangler en ny, praktisk anvendelig standard for kommunikasjon mellom lagringsenhetene og resten av systemet. Jeg ser i hvertfall ikke enheter som plugges direkte i PCI-E-portene som noen særlig god løsning.

 

Hadde du gittet å oppgi hva IOPS og QD står for, så skal jeg prøve å google meg frem til litt mer kunnskap om hvordan lagringsmedier fungerer? Er nemlig ikke helt dreven i det her...

6 Gbps = 600 MB/s overføringshastighet. Byte vs bit...

En 6Gbps SAS kontroller kan gi 600 MB/s båndbredde til hver enhet, og kan klare samlet båndbredde på rundt 2000-3000 MB/s (om LSI Megaraid 92x0-8i serien skal være en indikator).

 

PCIe er faktisk en særdeles god plass å plassere en SSD, men ikke SSDer slik som vi ser i 2,5" i dag som prøver å være harddisker med SAS/SATA protokoller.

Fordelen med å plassere en SSD rett på PCIe bussen er at man får en kontroller mindre å bry seg om, HBA (host bus adapter) som skal putte data i SATA-protokoll og sende til SSDen som så må ta det ut igjen av SATA-protokoll. Denne unødvendige protokollen skaper unødvendig latency, og de fleste HBA som finnes på hovedkort i dag er ikke optimalisert for latency i området SSDer har i det hele tatt.

Hvis du vil se hva en native PCIe SSD kan klare så sjekk ioDrive fra FusionIO. Denne enheten later ikke som den er en harddisk, og bruker ingen protokoll, den tar i mot data rå og behandler den selv. Arkitekturen er et cluster-oppsett med en kontroller og veldig mange flash-kanaler som skaper massiv intern parallellitet. En MLC ioDrive på 80GB klarer 100.000 IOPS les og ca 90.000 IOPS skriv.

 

IOPS = Input/Output Operations Per Second. Alså antall dataforespørsler pr sekund. Disse måles som standard i 4KB blokker.

 

QD = Queue Depth. Alså hvor lang køen av forespørsler til disken er. Men en intelligent kontroller kan SSDen svare på mange forespørsler samtidig siden den har flere interne linjer som kan lese/skrive parallellt, harddisker derimot kan kun besvare èn forespørsel av gangen men bruker slike køer til å optimalisere bevegelsen av lesehodet.

En tommelfingerregel for SSDer er at jo fler interne flash-kanaler den har, jo bedre skalerer ytelsen med lengre kø.

[Anders Jensen]

Må si jeg håper Intel kommer med en PCIe flash kontroller snart. De PCIe flash kontrollerne som er ute i dag minner mye om SATA SSD markedet før Intel kom på banen. Enten er produktene dårlige eller så er de alt for dyre og ytelsen kommer ved brute force og massiv over provisioning heller enn smarte kontrollere som jobber effektivt.

 

FusionIO er bra de, men RAM kravene til driveren er jo helt håpløse og en kan jo lure på hvor mye CPU og minnebåndbredde som vil bli sløst bort på å håndtere SSDen.

Endret 19. september 2009 av Anders Jensen

[Hugo_Hardnuts]

Du skriver at det allerede finnes 6GB/s SAS-kontrollere på markedet, men sånn jeg forstod svaret på et av mine spørsmål her tidligere, så betyr det da at kontrolleren kan overføre med denne kapasiteten totalt, og at hastigheten pr lagringsenhet fortsatt er begrenset til 300(evt. 600)MB/s...eller?

 

Sånn det ser ut i mine øyne er det litt en situasjon her der utviklingen av SSD har løpt litt i fra og at vi mangler en ny, praktisk anvendelig standard for kommunikasjon mellom lagringsenhetene og resten av systemet. Jeg ser i hvertfall ikke enheter som plugges direkte i PCI-E-portene som noen særlig god løsning.

 

Hadde du gittet å oppgi hva IOPS og QD står for, så skal jeg prøve å google meg frem til litt mer kunnskap om hvordan lagringsmedier fungerer? Er nemlig ikke helt dreven i det her...

6 Gbps = 600 MB/s overføringshastighet. Byte vs bit...

En 6Gbps SAS kontroller kan gi 600 MB/s båndbredde til hver enhet, og kan klare samlet båndbredde på rundt 2000-3000 MB/s (om LSI Megaraid 92x0-8i serien skal være en indikator).

 

 

PCIe er faktisk en særdeles god plass å plassere en SSD

 

 

, men ikke SSDer slik som vi ser i 2,5" i dag som prøver å være harddisker med SAS/SATA protokoller.

Fordelen med å plassere en SSD rett på PCIe bussen er at man får en kontroller mindre å bry seg om, HBA (host bus adapter) som skal putte data i SATA-protokoll og sende til SSDen som så må ta det ut igjen av SATA-protokoll. Denne unødvendige protokollen skaper unødvendig latency, og de fleste HBA som finnes på hovedkort i dag er ikke optimalisert for latency i området SSDer har i det hele tatt.

Hvis du vil se hva en native PCIe SSD kan klare så sjekk ioDrive fra FusionIO. Denne enheten later ikke som den er en harddisk, og bruker ingen protokoll, den tar i mot data rå og behandler den selv. Arkitekturen er et cluster-oppsett med en kontroller og veldig mange flash-kanaler som skaper massiv intern parallellitet. En MLC ioDrive på 80GB klarer 100.000 IOPS les og ca 90.000 IOPS skriv.

 

IOPS = Input/Output Operations Per Second. Alså antall dataforespørsler pr sekund. Disse måles som standard i 4KB blokker.

 

QD = Queue Depth. Alså hvor lang køen av forespørsler til disken er. Men en intelligent kontroller kan SSDen svare på mange forespørsler samtidig siden den har flere interne linjer som kan lese/skrive parallellt, harddisker derimot kan kun besvare èn forespørsel av gangen men bruker slike køer til å optimalisere bevegelsen av lesehodet.

En tommelfingerregel for SSDer er at jo fler interne flash-kanaler den har, jo bedre skalerer ytelsen med lengre kø.

 

 

Takker for et utfyllende svar - da ble ting litt mer forståelig. Vdr bruken av PCI-E så er det ikke ytelsen jeg stiller spørsmålstegn ved, men mer den fysiske plasseringen av enhetene. Det begynner jo etter hvert å bli ganske trangt om plassen rundt ekpansjonsplassene på hovedkortene...

[exenter]

Så hvis det du sier er riktig, så vil 2x x25-m 80GB ha dobbelt så høy IOPS-ytelse enn 1 x25-m 160GB? Jeg trodde bare den sekvensielle lese- og skrivehastigheten økte i RAID 0.

Ikke helt, èn 160GB har høyere IOPS enn èn 80GB, men 2x 80GB RAID-0 har høyere IOPS enn 1x 160GB forutsatt at kontrolleren de står på ikke blir flaskehals og at man bygger opp en liten IO-kø. Ved ca QD >16 burde 2 80GB slå 1 160GB, og ved høyere QD vil 80GB øke ledelsen.

Siden èn 160GB x25-m er ca. dobbelt så dyr som to 80GB x25-m, vil det sistnevnte være et bedre kjøp? Har tenkt å bruke det i RAID-0 på et hovedkort med ICH10R (x58 brikkesett). Jeg tenker på det med TRIM-støtte i Windows 7; vil det komme en firmware som gir TRIM-støtte i RAID for ICH10R?

[skrotnisse]

Småpenger.

Da jeg var ung kostet det rundt 50 lapper for 1 GB skikkelig treig harddisk. At dette nå har gått 1000 gangen i kapasitet og har blitt så mye billigere og bedre synes jeg er fantastisk. Bare tenk på hva acesstiden og lese/skrive hastigheten var på 1GB disken jeg husker.

[skrotnisse]

6 Gbps = 600 MB/s overføringshastighet. Byte vs bit...

En 6Gbps SAS kontroller kan gi 600 MB/s båndbredde til hver enhet, og kan klare samlet båndbredde på rundt 2000-3000 MB/s (om LSI Megaraid 92x0-8i serien skal være en indikator).

Her kan det jo nesten se ut som du prøver å formidle at 6 gigabit er det samme som 600 megabyte.

[Cid]

Fantastisk... Men jeg vil ikke betale for ultrarask tilgang til bildene mine, det er tross alt sjelden jeg åpner 3000 bilder, og 18 filmer i HD samtidig. Kunne noen snart ha hostet opp et produkt med høy ytelse og LAV(!) kapasitet? Ett kort på PCI-E med intern RAID 4x16GiB = 64GiB og samme lese/skrive ytelse hadde vært fint. Ett kort til OS/prog, og ett til scratch/swap. Resten kan jeg kjøre på snurredisk med redundans til en mer fornuftig penge. Da kunne kanskje prisene vært til å leve med også? (10000kr*64GiB/2000GiB+littforkontrolleren) = 640kr

 

En vakker tanke, men jeg får vente å se hva morgendagen bringer.

[Anders Jensen]

6 Gbps = 600 MB/s overføringshastighet. Byte vs bit...

En 6Gbps SAS kontroller kan gi 600 MB/s båndbredde til hver enhet, og kan klare samlet båndbredde på rundt 2000-3000 MB/s (om LSI Megaraid 92x0-8i serien skal være en indikator).

Her kan det jo nesten se ut som du prøver å formidle at 6 gigabit er det samme som 600 megabyte.

For SATA og SAS stemmer det at 6Gbps = 600MB/s. Dette skyldes at klokka legges inn i datasignalet med 8b/10b encoding. Altså hver byte som overføres blir kodet som 10bit og det medfører at mottaker kan regenerere klokka direkte ut fra datasignalet. Dermed trenger en ikke egne linjer for klokke.

 

Forøvrig er SATA half duplex så du får nok litt bus turnaround hoverhead samt at kommandoer ikke kan sendes til disk sammtidig som disken sender data. Dermed blir praktisk overføring for SATA 3Gbps 300MB/s teoretisk og ca 280MB/s i praksis. SAS har full duplex og kan derfor overføre nærmere teoretisk peak båndbredde samt at en har nesten dobbel båndbredde ved 50/50 les/skriv.

 

6Gbps SAS blir dermed et stort hopp i båndbredde for SSD enheter i forhold til dagens 3Gbps SATA som er vanligst. Det blir en best case økning fra 280MB/s til ~1,2GB/s for singel port og ~2,4GB/s for dual port. Dette er mer enn de teoretiske 500MB/s et ti kanals ONFI 1.0 SSD drev, slik som Intel x25-m, kan levere av båndbredde. En ti kanals ONFI 2.1 komtroller kan imidlertid levere opp til 2GB/s båndbredde i teorien.

Endret 20. september 2009 av Anders Jensen

[GullLars]

ONFI 2.1 har vell 200 MB/s pr flash kanal som maks, og det forutsetter pipelines for å skjule array time. Alså må man ha fler NAND brikker pr kanal for å få slike høye hastigheter sustained. Dette har både positive og likegyldige virkninger.

Positivt: MLC SSDer med få kanaler og høy kapasitet vil få en solid økning i båndbredde uten noe særlig mer kompleksitet.

Likegyldig: Det blir ikke like betydelig økning for SSDer med lav kapasitet og mange kanaler, annet enn selvfølgelig redusert latency (yay for IOPS).

Som en oppside tillater dette også raskere NAND brikker å yte høyere.

[Anders Jensen]

Det negative med all pipelining generelt er at en må ha lengre køer for å få høy utnyttelsesgrad.

[GullLars]

Egentlig helst sekvensiell last eller store blokker for å utnytte flash pipelines. Det har noe med hvordan bussen er satt opp. Med lengre pipelines får man ikke bett om mange 4KB blokker og lest disse ut samtidig ved maks fart. Om man har array time = transfer time kan man få 2x IOPS ut av èn pipeline om man har lang nokk kø til å treffe den kontinuerlig med 2 forespørsler. (om jeg har forstått det riktig).

For å skalere IOPS er det derfor viktig med mange parallelle pipelines, og nokk QD til å treffe alle samtidig med forespørsler.

 

Om jeg ikke husker feil er stats for èn standard MLC Nand chip ca 10k les og 3k skriv IOPS (forutsatt klare blokker), 30 MB/s les og 10 MB/s skriv.

 

Jeg tror det er ganske optimalt med 2 Nand chips pr kanal for å unngå dødtid på bussen ved høy tilfeldig eller sekvensiell last.

[robertaksland]

Det er i hvertfall bra at det eksisterer løsninger som drastisk overstiger dagens ytelsesbehov. Vi vet ikke hva som kommer til å trigge fremtidens behov for rask lagring, men at det kommer er helt sikkert. Fremtiden er lynrask, det er helt sikkert.