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

[GullLars]

Jeg må rette deg litt her anvil, dette er ikke tilfellet med alle SSDer. Beklager det kommer teori i benche-tråden, men dette er veldig relevant.

 

Samsung sin SSD gjør som du sier, og mister betydelig ytelse så fort køen blir lenger en kontrolleren kan holde internt, som er 32 mener jeg på.

Indilinx mister sakte litt etter litt ytelse etter 32-64 men holder seg fortsatt OK.

Intel mistet ytelse med gammel firmware, men med de nyere versonene bare flater ytelsen ut, ser det ut som.

 

Nå kontrolleren støtter NCQ (Native Command Queue) kan kontrolleren selv velge hvilken rekkefølge den vil svare på forespørslene for å levere optimal ytelse, mens kontrollere uten NCQ må utføre forespørslene i samme rekkefølge den mottar de.

 

Harddisker kan også benytte seg av NCQ for å minimere bevegelse av lesehodet og skjule noe av latency, men siden de bare har et lesehode kan de ikke kjøre kommandoer i parallell, de kan bare jobbe for å minimere tiden mellom hver kommonda.

 

SSDer har som kjent mange flash chips, og alle disse kan kjøres i parallell, eller de kan kjøres i serie for å øke kapasitet uten å øke kompleksitet. Det finnes også mellomting med deling av enkelte linjer (data inn, ut, kommandoer), men det går jeg ikke inn i her.

Tidlige SSDer hadde 4 flash kanaler, nye SSDer har 8 (indilinx og samsung) eller 10 (intel).

 

Når en SSD støtter NCQ kan den ta køen og utføre den i en rekkefølge så alle flashkanalene har noe å jobbe med til en hver tid, forutsatt at det finnes forespørsler for alle kanalene i køen. Ved enkel sansynlighetsberegning sier det seg selv at med QD = flashkanaler vil ikke alle kanalene få noe å gjøre hele tiden, og selv ikke ved QD dobbel av antall flash kanaler vil det også være en god sjangse for at det vil være ubrukte ressusjer fra tid til annen.

 

Intel x25 (hele dette segmentet er om kontrolleren) støtter QD = 32, alså rett over 3 ganger antall flashkanaler, som vil kunne gi en veldig høy utnyttelsesgrad. I tillegg arbeider kontrolleren med en intern stripe på 4KB over alle flash kanalene, så pakker over 4KB vil effektivt gi multiplumet av 4KB høyere QD (8KB gir 2x, 16KB gir 4x, osv). Dette koster en del ressusjer av kontrolleren, men leverer veldig god ytelse. Det ser ut som kontrollerens IOPS-kapasitet topper ut rundt 50k, om dette er pga interface (SATA), kontrolleren, array-time i flash eller transfer time til/fra flash vet jeg ikke. Den klarer noe mer lesehastighet ved større sekvensielle pakker, så begrensningen ligger muligens i en kombinasjon av behandlingstiden i kontrolleren og mettningen av flashkanalene. (ved store sekvensielle pakker vil kontrolleren kunne forespørre to eller fler 4KB stripe-pakker ved siden av hverandre i samme flashkanal, som fører til en 8KB forespørsel i flash kanalen, som igjen gir høyere mettningsgrad).

 

Indilinx og Samsung har 8 kanaler og støtter ikke NCQ, så grunnen til at disse kan få økt ytelse ved litt kø er at med en gang en forespørsel sendes til en flashkanal kan en ny sendes uten å vente så lenge det er til en annen kanal.

 

Indilinx ser ut til å ikke skalere 4KB random write med QD, som muligens betyr at den prøver å fylle en blokk på en flash kanal før den begynner på en ny blokk.

At ytelsen faller igjen etter QD ca 32 kan være pga overmetting av interne buffere.

 

Beklager teori-rant

[Anv]

GullLars,

 

Selvsagt er det forskjellig fra kontroller til kontroller men det du beskriver her er kontrollerens evne til å håndtere køen, ikke prinsippet med QD. (utestående les/skrive operasjoner)

Om dette skjer med 8 eller 10 kanaler i parallel forandrer ikke hvordan en kø fungerer eller hvor lang den er.

Når en kontroller ikke klarer å håndtere køen får man stuttering og dette kan skje selv ved lav QD.

 

QD er med SSD endret og da mener jeg at QD er lavere i et system med SSD enn med HDD, dvs flaskehalsen er ikke nødvendigvis lagringsløsningen.

 

Har du forresten lest denne artikkelen?

Link

 

Man må registrere seg for å få tilgang til hele artikkelen og det har ikke jeg gjort.

[GullLars]

Det jeg beskrev var egentlig forskjellen i hvordan (SSD) kontrollere med og uten NCQ støtte håndterer køen. Ytelsestapet som kommer av å ikke klare å håndtere køen, stuttering som du sier, er en svakhet i kontrolleren. Jeg kjenner ikke til noen SSD med NCQ som har slike problemer. Min hypotese er at når køen blir større enn det kontrollerens buffere klarer å holde kan kontrollerne få problemer, og hvor store vil variere. JMicron f.eks. kan jo dette ned i enkeltsifrede IOPS eller lave dobbelsifrede, mens samsung reduseres til lave hundretall. Indilinx ser ut til å klare å holde ved grei ytelse, og Intel virker det som har fikset problemet med ytelsestap ved lang kø, muligens ved å begrense antallet forespørsler kontrolleren aksepterer.

 

Etter litt gjennomtanke har jeg veldig lyst til å se noen IOmeter resultater av QD 16, 24, 32, 48 og 64 av diverse SSDer for å se om det kanskje kan lønne seg å forandre configen vi tester med her. Hva mener dere?

 

For en dybdeanalyse av SSDene kunne det også vært en god idè å la seg inspirere av noen grafer jeg husker fra Toms Hardware der de satt opp grafer med f(IOPS)=QD med oppløsning 2^n på x aksen med n 0-8. Kort sagt vil dette gi et veldig tydelig bilde av hvordan IOPS (på y-aksen) skalerer med QD (på x aksen), og vil ta for seg alle QD enhetene noen sinne i praksis vil møte.

Å kjøre 8-9 IOmeter runder vil være en del snillere mot SSDen enn å teste QD 1-x som x runder i IOmeter.

Dette tillater også å sette sammen grafer av de beste resultatene vi får for alle enheter vi tester i ett diagram for en fin sammenligning. Eventuelt diagrammer med samme SSD-serie på forskjellige kontrollere eller kapasiteter. Bare en liten tanke.

For en kjapp oversikt ser jo crystal 3.0 ut til å ha fint potensiale.

[Anv]

QD er absolutt interessant å utrede nærmere synes jeg.

 

Denne artikkelen på XBitLabs er verdt å se på. (husker ikke om denne har vært diskutert her)

Link

 

Summit (Samsung kontroller) kommer her ut å kjøre allerede ved QD over 4 når skriving er med i bildet, den skalere bra på lesing. (noe de fleste gjør)

Endret 7. november 2009 av Anvil

[Agrophel]

Mått prøve med 2GB jeg og

 

 

 

Men tilbake til Dragon Age

[GullLars]

Jeg har i alle fall lest den artikkelen før. Dumt de ikke oppgir QD på random read/write testene på side 7, jeg mistenker lav QD.

 

Jeg kom akkurat til å tenke på hvor fullstendig bilde av ytelsen en 3D graf med x=QD, y=IOPS og z=blockstørrelse ville gi. Det kunne også vært interresant med en matrise med disse pluss random/seq forhold og les/skriv forhold, men det blir for komplekst for oss å teste. Resultatet ville vært en virtuell 5D graf

Eventuelt ville 3D grafer med fastsatte QD (si 2^n, n= 0-7) og block (si 4^n KB, n= 1-5) med r/w på x og seq/random på y vært fine også. 4KB QD= 32(?) ville vært mest interresant ang IOPS. Men, dette er alt for store mengder data til å behandle i en forumtråd

 

Vet noen her om noe program som kan lage fine 3D grafer, eller se slike i rommet?

[Ourasi]

http://www.pcper.com/article.php?aid=750&a...xpert&pid=8 PCPerspective har enkle og greie grafer, dog ikke noen ren random read/write, men en bra Workstation med de fleste siste gen SSD'ene representert......For egen del synes jeg CDM nå er bra nok for personlig "sanaty" skjekk av mine SSD'er etter install av Win7 eller HDDErase, og vil straks legge denne opp, imorgen tipper jeg...

Endret 7. november 2009 av Ourasi

[Anv]

TP utgaven er vel pre Alpha går jeg ut fra?

Det hadde vært kjekt om de hadde beholdt QD4 og QD32.

 

Det blir ikke enklere å beregne en fornuftig score med disse nye parametrene

[Ourasi]

"The ASUS U3S6 Add-in card - USB 3.0 and SATA 6G for everyone else

 

Along with this new motherboard ASUS also sent us an add-in card that will offer both USB 3.0 and SATA 6G connectivity to all other users that didn't have the good fortune to have them integrated on their current motherboard. The ASUS U3S6 (get it, USB 3.0 and SATA 6G?) card will be sold individually with a modest MSRP of $29."

http://www.pcper.com/article.php?aid=809

 

Dette er jo en billig USB3.0 løsning for å bruke SSD som USB lagring (ser for meg en kjapp Win7 installering med en slik løsning). 6G løsningen er vel sikkert så som så, men koster jo ikke mye å prøve ut...

Endret 7. november 2009 av Ourasi

[Anv]

Prisen var jo gledelig lav, har du funnet den i noen nettbutikker?

 

Jeg likte ikke at det var ny kabling på USB 3.0 (ikke kompatibel med tidligere versjoner) men hastigheten kan man ikke unngå å like

 

SATA 6Gb/s blir definitivt spennende men det er jo total manko på enheter å prøve dette på. (noen få HDD'er finnes)

Jeg hadde forventet at dette skulle være med i P55 men det blir tydeligvis forskjøvet.

[Ourasi]

Fant ingen i guiden dessverre... Skal høre med NetShop om de gidder ta den inn, for denne prisen må det jo testes.

[Anv]

Gigabyte har litt informasjon om forbedringer ved overføring.

Link

 

Overføring av 25GB

USB 2.0 : 834sek

USB 3.0 : 70sek

I tillegg er 3.0 Dual Simplex, 2.0 var Half Duplex og dette gir store fordeler.

[Horge]

RAID med x25-M vil kunne oppnå høyere ytelse på små blokker ved lavere QD om man kjører liten stripe. Om man spesifiserer stripa til 4KB * #SSDer (16KB for 4 stk) så vil man oppnå optimalt med IOPS ved lavest mulig QD og bare ofre rundt 25% leseytelse og 10-15% skriveytelse fra maks mulige båndbredde. (muligens ikke så mye engang)

EDIT: dette forutsatt at RAID kontrolleren klarer å holde unna

Leser jeg det riktig hvis dette er svaret på spørsmålet jeg stilte i SSD-tråden?

 

Altså at med 2 x X25, så bør jeg konfigurere RAID-stripa til 8KB?

 

Eller vil det til mitt bruk være lite hensiktsmessig å forsake lese- og skriveytelsen til fordel for IOPS?

[GullLars]

Det ser ikke ut til at du vil miste mye båndbredde av 8KB stripe nei. For den første maskinen du nevner vil dette klart være det beste valget, mens for den andre vil det kanskje avhenge av hvor mye av tiden som går med til bildebehandling. Jeg vil anbefale deg å sette opp 8KB stripe og kjøre en Crystal 3.0 test, og så sette opp en med f.eks. 128KB stripe og kjøre en CDM 3.0 test til. Du kan gjøre dette rimelig fort dersom RAIDet ikke brukes til OS.

Post screenshots her så skal vi svare deg kjapt.

 

Jeg mener på ICH10R skal klare små striper greit siden den er en "dum" kontroller.

[Agrophel]

 

Ocz-Vertex 30GB singel disk på HW kontrolern. (Pass Through)

[Ourasi]

H/W kontroller gir automatisk plass i ekstremlistene, forklaringen på dette ser man på din sekvensielle hastighet ganske enkelt, samt enkelte andre tester.. Selv om singel Vertex neppe bør benches i hensikten om å konkurrere med de andre oppsettene i denne listen, så var det et artig ekspriment

[Horge]

Jeg vil anbefale deg å sette opp 8KB stripe og kjøre en Crystal 3.0 test, og så sette opp en med f.eks. 128KB stripe og kjøre en CDM 3.0 test til.

Mnja, er vel systemdisk dette, så litt pes er det jo å endre stripestørrelse to ganger om dagen... Vi løste det heller ved at vi satt opp en boks med 8kb og en med 128kb.

 

Her er resultatet med 8kb. Skal prøve å få gjort samme test på den andre boksen i morgen. (specs)

 

[Anv]

Intel diskene er meget fleksible på hvilken stripe size man bruker så tviler jeg på at det vil være stor forskjell i praksis.

Dere vil få litt bedre sekvensiell ytelse med 128KB enn ved 8KB men begge vil gi gode resultater.

Det er mulig at 16KB eller 32KB hadde vært en bedre kompromiss.

 

I og med at dere prøver en maskin i hver ytterende vil dere fort merke om det ene er bedre enn det andre eller om det har noen praktisk betydning i det hele tatt.

[Ourasi]

Om Horge lastet IOMeter 4kb Random R/W config og byttet 4kb filstørrelse med 16kb, og testet med 8kb stripe vs. 128kb, så kunne vi nok sett enkelte forbedringer, og 16kb er en meget relevant filstørrelse for OS. HDTune Pro viser heftig mange prosent bedring på 64kb random testen med 32kb stripe eller mindre sammenlignet med 64-128kb stripe.....

Endret 10. november 2009 av Ourasi

[GullLars]

HDTune Pro viser heftig mange prosent bedring på 64kb random testen med 32kb stripe eller mindre sammenlignet med 64-128kb stripe.....

Det er fordi at alle blokker lik eller større enn stripestørrelsen vil effektivt leses tilbake som en høyere QD av mindre blokker, som er veldig lønnsomt for SSD. Siden Intel har 4KB seq/random tall ganske nære 1MB seq/random hastighet taper man ikke mye på at store blokker leses som mindre blokker, men man kan tjene veldig mye ved å ha en liten stripe som gjør at mellomstore blokker heller leses som mindre blokker med høyere QD.

En 8KB stripe på 2 enheter vil garantere at alle blokker på 8KB og over vil bli lest fra begge enhetene uavhengig av QD, og vil hjelpe mye ved forespørsler av mellomstore blokker (16-64KB) ved lavere QD.