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

[GullLars]

Neida nizzen, dine bekymringer har grunnlag.

Jeg vil gjerne belyse saken fra et par litt andre perspektiv.

 

EDIT: Jeg ser anvil postet noe mens jeg skrev denne. Han er tydeligvis synsk.

 

Wall Of Text crits you for 9999

 

Først analyserer jeg saken fra et "Totalt antall I/O" perspektiv.

Om man tracer disk access slik som f.eks. anand har gjort er det realistisk å anta grovt totalt i område noen hundre til et par tusen I/Os ved oppstart av diverse programmer avhengig av type og størrelse. På en harddisk vil dette ta grovt et par sekunder til et halvt minutt om man ser bort fra caching, forutsetter vi 1/3 skriv som kan caches vil cachen ha plass til alle I/Os i cache som kan flushes senere. På SSDer vil selv noen få tusen I/Os kunne behandles i område et sekund ved QD 1-2, muligens et par sekunder om man regner blokker 4-128KB med snitt ([totalt KB I/Os]/[#I/Os]) rundt 16KB.

Forutsatt at SSDen ikke har elendig random write og ikke kan cache alle skriv vil random delen av åpning av programmer ta opp fra noen tiendels sekunder til et par sekunder. Da blir igjen sekvensiell les veldig viktig, og denne skalerer praktisk talt 100% med RAID-0.

 

Så har vi et annet perspektiv jeg liker å kalle øyeblikkelig QD. Jeg mistenker PerfMon viser gjennomsnittlig QD mellom hvert punkt i loggen, og med et snitt på 2 QD i et sekund betyr dette at en SSD som x25-M vil ha lest 5000-10.000 I/Os, der maks øyeblikkelig QD sansynligvis har vært en del høyere. Dette vil være veldig tydelig om man sjekker en graf for _MAX ACCESSTIME_.

Vi er her inne på området hvor SSDer blir brukt som "CPU-akselleratorer".

 

Som de fleste her vet arbeider CPU med latency i området nanosekunder. L1 cache er i området singel siffer ns, L2 og L3 er lav dobbeltsiffrede ns, og RAM er grovt i område 50ns. Når vi da hopper videre til SSDer med gjennomsnittlig accesstime i området 0,1ms-10ms avhengig av forholdene mellom seq/random og read/write, blokk størrelse, og QD.

 

Nå vil kanskje mange protestere mot 10ms fra en SSD, men en del SSDer kan nå så høy accesstime ved random write, spesielt ved høyere QD, og random write kan nå høy øyeblikkelig QD ved oppdatering av programmers databaser ol. Typisk (liten block random) average accesstime for en god SSD derimot ligger i underkant av 1ms.

 

Om vi ser på 0,1ms som et best-case eksempel er dette 100µs, eller 100.000ns vs 50ns for RAM. Dette betyr betydelig venting for CPU når den skal hente data fra lagringsmediet, og kan lage trafikk-kork i tråden som trenger disk-aksess før den kan fortsette forbi et visst punkt der forespurt data trengs.

 

Om vi postulerer at det blir sendt ut forespørsler for 20 tilfeldige LBAs (4KB, si oppføringer i dll, database, etc.) i et visst punkt av et programs oppstart i løpet av noen få µs og så må vente på LBAene før det kan fortsette.

 

En x25-M kan da besvare 10 av disse av gangen forutsatt at de hører til forskjellige kanaler, for å ta hensyn til dette sier vi 3 runder med aksess på ca 0,3ms (stemmer vell med IOmeter 4KB random QD 8-20?) som blir i underkant av 1ms totalt.

 

En Vertex kan besvare 4 i parallell med omtrent lik accesstime som x25-M, men må minst gjøre 5 runder med aksesser, som gir minst 1,5ms, sansynligvis 2-3ms om man ser på Vertex accessime ved QD 8-20 x6-7 runder grunnet ugjevn I/O pr kanal.

 

Om vi så postulerer at slike "bursts" av I/Os vil skje mange ganger i løpet av oppstarten til et program og vil midlertidig stoppe tråden til de har blitt besvart vil en x25-M spare CPUen for veldig mange vente-sykler vs en vertex, men dette alene vil nødvendigvis ikke utgjøre så veldig stor forskjell ved singeltasking med kun read bursts.

 

Postulerer vi noe multitasking eller forekomst av noen write forespørsler i slike bursts vil forskjellene mellom SSDer, og SSD til HDD bli mye tydligere (spesielt om HDD ikke kan cache write).

 

x25-M forholder lav accesstime selv ved mixed r/w ved høyere QD grunnet optimalisering mot små block random, vertex gjør en grei jobb og holder også ganske lav accesstime men betydelig over intel, Samsung kneler ved mixed I/O, spesielt ved høy QD, og leverer dårlig accesstime nesten på nivå med en harddisk, og JMicron kontrollere kan fryse i mange hundre ms der fler random writes kommer tett.

 

 

Min summering av det over blir alså:

Så lenge både random read, random write, og mixed read/write holder lav average accesstime og ikke for høy max accesstime selv ved noe høyere QD vil IOPS ikke være spesielt viktig når man passerer 10.000 for både read, write, og mixed. For å beholde lav average accesstime ved høyere øyeblikkelig QD vil man alikevell trenge høye IOPS tall siden (1/[average accesstime])*QD = IOPS. 10.000 IOPS ved QD=10 betyr 1ms average accesstime. 30.000 IOPS ved QD=10 betyr 0,3ms average accesstime. Ser man på mixed IOPS havner intel nærmere 10K IOPS ved disse spesifikasjonene, og vertex nærmere 3K. 3000 IOPS ved QD=10 betyr ca 3ms.

 

I sammenheng med dette har jeg en forespørsel om noen med en SSD som har NCQ kan kjøre følgende IOmeter config og poste .csv her. Her er spesifikasjonene:

4KB 100% random 67% read, Burst lenght 1 og 10 i to forskjellige access patterns. QD exponential 2^n stepping QD 1-32. Dette gir totalt 12 kjøringer.

Test area 1GB, 2 sec ramp, 30 sec runtime. Dette betyr ca 6-7 minutter totalt.

Jeg kommer til å kjøre denne selv med QD 1, 4 og 32 på mitt Mtron RAID bare for å undersøke om det er noen forskjell med QD.

Grunnen til at jeg har 2 access patterns her er at jeg vil se om "burst lenght" instillingen gjør noe merkbart utslag.

Om noen fortsatt har ånden over seg etter dette ønsker jeg også å teste tilsvarende access pattern bare med 1ms delay (for å simulere pausene mellom disk-aksess under program launch) og færre QD steppings (4^n i stedet) for å redusere antall kjøringer.

Årsaken til at jeg ber om disse IOmeter kjøringene er at jeg tror det vil kaste lys på hvorfor SSDene oppfører seg forskjellig når de overfladisk skal være ganske like.

 

(EDIT 2: lagt til litt luft i teksten for å gjøre det lesbart )

Endret 27. januar 2010 av GullLars

[Ourasi]

De fleste apps idag er programmert for å bruke synkron I/O også kalt blokkerende I/O, og denne metoden er ikke å foretrekke på NCQ SSD'er da denne hindrer åpning av flere I/O samtidig for les/skriv. Asynkron I/O eller ikkeblokkerende I/O, som er slik alle apps burde programmeres, kan åpne en mengde I/O samtidig uten å vente på at hver operasjon er ferdig, og kan hente all data applikasjonen vil ha på halve tiden målt mot synkron I/O. Det er veldig enkelt for programmererne å legge til disse få kodelinjene for å bruke denne metoden, men HDD media med sin svake IO ytelse, gjør tydligvis at programmererne går andre veier for å fungere best på snurrediskene, med maximalt sekvensiell les og minimalt random.. Server apps, VM o.l. er vissnok ofte programmert med asynkron IO, og drar bedre nytte av en SSD...

[GullLars]

Da har jeg alså postulert Asynkron I/O i eksemplet for CPU-aksellerering.

Til sammenligning mener jeg da på at IOmeter testen jeg ba om men glemte å legge ut vil sammenligne hhv synkron og asynkron I/O uttrykkt som "burst lenght" med 1 vs 10.

4kb_random_67r_1b_og_10b_exp2_QD_1_32.rar

 

For programmer med synkron I/O vil da (random) accesstime ved QD=1, _for alle block størrelser_ være avgjørende om jeg forstår deg rett.

[Ourasi]

For programmer med synkron I/O vil da (random) accesstime ved QD=1, _for alle block størrelser_ være avgjørende om jeg forstår deg rett.

 

I teorien, ja, men det er andre faktorer som hyper-threading o.l. som spiller inn også, og gjør at flere programmer med synkron IO allikevel kan ha IO forespørsler utestående samtidig, men dette gir allikevel ikke på langt nær samme ytelsesforbedringen som ved å modifisere apllikasjonene til å nyttegjøre seg av Queue/kø.

 

Man ser ofte at programmer har veldig varierende QD under åpning og varierer fra QD#1-4, og sannsynligheten for at det er disse andre faktorene som er årsaken til dette, er vel ganske stor. Men at random accesstime er veldig viktig idag, med lite SSD og mye HDD, er temmelig sikkert. Ren QD#1 selv med programmer med synkron IO er allikevel vanskelig å få til i windows siden disse køene styrt av andre faktorer ikke logges like godt av perfmon disk, da må man antageligvis se på andre grafer..

 

Les side 7-8-9 i pdf'en jeg har lagt til...

D2c_tech_paper_intc_stx_sata_ncq.pdf

Endret 27. januar 2010 av Ourasi

[Anv]

Problemet med å overvåke QD er at ting skjer så fort på en SSD.

I bursts overstiger QD lett 2 og det er ikke noe problem å provosere frem opp mot 16 så det er ikke helt håpløse tall vi snakker om.

QD64 er litt drøyt men det viser hva en SSD gjør når den blir mettet.

 

Det burde være mulig å studere dette nærmere med en gammel HDD

 

Når det gjelder asynkron vs synkron og Multi Threading er det ikke så enkelt som det høres ut.

For det første må det være hensiktsmessig for programmet å jobbe med flere tråder og det er ikke alltid det er mulig.

De enkleste formene for filbehandlig er når et program åpner et dokument eller lagrer et dokument, dette er oppgaver som som regel ikke kan forenkles.

Et dokument kan imidlertid bestå av "strømmer" med data og disse kan man selvsagt lese asynkront men det krever da at applikasjonen er flertrådet.

 

edit:

Der var det passert 50.000 visninger av tråden

(ikke ille for en tråd som er langt fra 1 års dagen, den er faktisk bare 5 måneder gammel)

Endret 27. januar 2010 av Anvil

[Anv]

Det går rykter om at man kan lure Kingston V 40 GB til å få TRIM.

 

Jeg stiller meg foreløpig tvilende til dette men her er i alle fall tråden hvor oppskriften ligger. Link

(hopp ned til post 39 og les utover)

 

Nå er det slik at mine Kingston kom med 02HD som levert firmware, mens mine Intel V 40GB kom med 02HB.

Hvis DCO låser opp TRIM er det selvsagt glimrende for oss med Kingston men jeg har på følelsen at dette er for enkelt, jeg kan ta feil og håper jeg gjør det

[Anv]

I sammenheng med dette har jeg en forespørsel om noen med en SSD som har NCQ kan kjøre følgende IOmeter config og poste .csv her. Her er spesifikasjonene:

4KB 100% random 67% read, Burst lenght 1 og 10 i to forskjellige access patterns. QD exponential 2^n stepping QD 1-32.

...

Grunnen til at jeg har 2 access patterns her er at jeg vil se om "burst lenght" instillingen gjør noe merkbart utslag.

Om noen fortsatt har ånden over seg etter dette ønsker jeg også å teste tilsvarende access pattern bare med 1ms delay (for å simulere pausene mellom disk-aksess under program launch) og færre QD steppings (4^n i stedet) for å redusere antall kjøringer.

Årsaken til at jeg ber om disse IOmeter kjøringene er at jeg tror det vil kaste lys på hvorfor SSDene oppfører seg forskjellig når de overfladisk skal være ganske like.

 

Kan kjøre det på en av mine G1 i løpet av kvelden.

[Anv]

Burst 1 og 10 med 67%read, 100% random 4K, 30sek, 5sek ramp up.

IOmeter_burst_1_10.zip

 

X25-M 80GB G1, første kjøring på hver enkelt er lagret.

 

edit:

1ms Burst Delay gir et konstant resultat for hver burst length så det er ikke noe å prøve på for hver QD.

 

Burst Transfer delay 1ms ved BL 1 gir

 

Burst Transfer delay 1ms ved BL 10 gir 10x resultatet av 1

Endret 27. januar 2010 av Anvil

[GullLars]

Brukte du configen jeg postet i #1583?

 

Fint at dere er med på å teste dette.

[Anv]

Nei jeg brukte min egen, endret bare på en Random Read jeg hadde liggende.

 

Hadde du gjort andre endringer enn det du beskrev i innlegget?

 

edit:

Kjører på en Vertex (FW 1.41) nå og iops er mer eller mindre uendret fra QD1-QD32.

 

Vertex 120GB samme runde

IOmeter_vertex_burst_1_10.zip

 

Burst delay blir akkurat som på X25-M så det er et produkt av forsinkelsen.

Endret 27. januar 2010 av Anvil

[Nizzen]

ATTO Disk Benchmark 2.46

 

http://downloads.guru3d.com/downloadget.ph...818da6968ac2332

 

Endelig kan det testes med større enn 256mb

Endret 27. januar 2010 av Nizzen

[Anv]

Jeg prøvde den her om dagen, den virker mer stabil.

[ellsworth]

Da har eg endelig fått bytta ut ein BRÅKETE 60gb hdd med intel x25-m 160gb på min kjære laptop. Vil si at det var eit steg i riktig retning

 

Har prøvd å tweake litt og endte opp med disse resultata. Heilt greit trur eg.

 

 

 

Det som var mest stress var igrunn å få over 5.9 i score på WEI... Klarte tilslutt å få 7.6 etter ein del knoting. Ikkje at det er så viktig, men man har sine prinsipper

[Anv]

Fine tall ellsworth, det er bare å nyte stillheten og responsen.

 

 

@GullLars, Ourasi og andre interesserte

 

Så denne på XS, DDRdrive, ble lettere imponert, helt til jeg leste litt i dybden. Link

50.000 iops 4KB read

35.000 iops 4KB write

 

De reklamerer selvsagt med 512B ytelsen som er rimelig mye høyere.

Selve konseptet ser imidlertid bra ut.

[Agrophel]

Litt fail den er på PCE-E x1

 

 

Og koster 1500$

Endret 27. januar 2010 av Agrophel

[GullLars]

Jeg linket til den i høst en gang rett etter den ble annonsert. Nyheten var først på storagesearch.com

Den største fordelen med denne er nokk accesstime ved lav QD, som kan fungere veldig fint for database-logg ol.

[Anv]

Da har jeg ikke fått det med meg

 

Fant du ut noe fra iometer tallene?

[GullLars]

Det viser seg at csv filene bruker . som komma og , for å skille rutene, så jeg fikk ikke lagd grafer. Om noen av dere vet hvordan man får excell eller OO scalc til å regne med punktum som decimal skille så si i fra.

 

Jeg fikk derimot laget en fin tabell

x25-M Gen1 80GB

Det ser ut som det er veldig liten forskjell på burst 1 og burst 10 med delay=0, men det hadde et lite utslag på max responsetime.

 

Skal se på vertex saken du la til nå, så den ikke før jeg lagde denne tabellen.

Jeg kommer nok til å poste èn for vertex og en for sammenligning av x25-M vs Vertex.

 

EDIT: her var det noe feil! Tallene i Vertex zip fila di er nøyaktig like de fra den første du postet. Ut fra tallene vil jeg regne med begge er fra intel x25-M.

Endret 28. januar 2010 av GullLars

[Anv]

Jeg skal sjekke den saken, mulig jeg har blingset på en katalog.

 

edit:

Merk dataområdet og kjør en søk/erstatt, det fungerer.

Ellers må du inn i regionale innstillinger, mulig det også kan overstyres i Excel.

 

edit:

Ny zip fil, vet ikke hva som skjedde med den forrige.

IOmeter_Vertex.zip

Endret 28. januar 2010 av Anvil

[GullLars]

Jeg aner ikke hvordan du har klart det, men det er identiske filer (til x25-M) du har sent igjen...

 

Skal prøve søk og erstatt nå.

 

Forresten, tidligere i dag har jeg vært i kontakt med "Storage and Systems Review Editor" hos TweakTown angående Vertex 2 Pro, og fikk tillsendt litt benchmark data foretatt med AHCI, men ikke på den ofisielle testriggen deres. Den forgie testen de gjorde under CES var ved feiltagelse gjort i IDE mode.

 

Jeg venter på mail tilbake nå med tillatelse til å poste resultatene her. Som en teaser vil jeg nevne 36525 poeng i PCmark vantage HDD-suite, 120MB/s var laveste i alle 8 del-testene.

Endret 28. januar 2010 av GullLars