Gå til innhold

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


Ourasi

Anbefalte innlegg

Jeg er rimelig sikker på at spørsmålet allerede har vært stilt, og er sikkert også besvart. Det var dog urimelig mange sider å lese i denne tråden, så jeg tillater meg likevel: Det er det åpenbart noe som ikke stemmer helt med oppsettet mitt:

 

post-8212-1265334367_thumb.png

(Testen er tatt like etter installasjon)

 

Asus Maximus Formula Special Ed (vannkjøling i et Kandalf LCS)

Q9650 @ 3,6 GHz

8 GB DDR2-1066MHz RAM

2 x Intel X25-M Gen2 80 Gb i Raid0 på ICH9R

2 x Raptor X (samme controller)

2 x Seagate 1TB (samme kontroller)

 

Win7 x64 Ultimate

 

Ingen AHPI, og Intel Solid-Stade Drive Toolbox viser bare "Raid not supported":

 

post-8212-1265335005_thumb.jpg

 

Var det dumt av meg å sette dem opp i Raid0, hadde det vært like greit å satt dem som 2 single disker, enabl'a AHPI slik at jeg fikk TRIM på dem i tillegg?

 

Jeg hadde satt umåtelig stor pris på litt hjelp :)

Intel_SSD_Toolbox.bmp

Lenke til kommentar
Videoannonse
Annonse

"Enable Write Caching On The Device" er ikke huket av på stripa hans tipper jeg, ergo de forferdelige skriv resultatene, han finner denne i Device Manager/Disk Drives/"Raid stripa"/Policies....

 

Noen har misforstått dette med "WriteBack Cache" og disabler feil, mens andre ganger virker det som om den defaulter avslått, aldri sett dette selv, så skal ikke avskrive det helt, men rart er det... Noen "gamle" tweakguider anbefalte vel "Enable Write Caching On The Device" avslått på gen. 1 Jmicron SSD'er, disse guidene må man styre unna for alle nyere SSD'er...

Endret av Ourasi
Lenke til kommentar

Tusen takk for raske tilbakemeldinger. Fiklet litt i Intel ® Matrix Storage Console v8.9.0.1023:

post-8212-1265352545_thumb.jpg

post-8212-1265352548_thumb.jpg

 

Det er også utarbeidet en rapport med mer detaljert info:

 

Rapport.txt

 

 

Resultatet med disse innstillingene ser slik ut:

 

post-8212-1265352582_thumb.png

 

Er jeg "on target" nå?

 

Vil jeg stadig få dårligere performance siden det angivelig ikke går an å ha TRIM aktivert på en RAID0-stripe? (Seq read er lavere enn i går)

 

Igjen, takk for all hjelp!

 

EDIT: har oppdatert til FW version 02HD

Endret av Donten
Lenke til kommentar

Noen som har et godt svar på hvorfor AMD/Intel ikke klarer å lage drivere som støtter TRIM?

OS'et støtter det (W7 i alle fall), disken støtter det. Kontrolleren må nesten også støtte det siden MS' drivere funker. Så hvorfor i heite hule klarer ikke chipset-leverandørene å skrive drivere til egne ting? Spesielt Intel som faktisk lager disken selv også.

 

Jeg bare lurer :hmm:

Lenke til kommentar

De somler vell og gir det lav prioritet siden det ikke er så mange med SSD, ENNÅ.

OCZ har jo allerede laget custom drivere og firmware for LSI 92xx som støtter TRIM i RAID modus, sansynligvis er disse alpha eller beta stabilitets-messig, men det er alså fint mulig å gjøre og ganske fort også.

Jeg renger med Intel og AMD vil kvalitetssikre driverne sine veldig mye mer enn OCZ før de slipper dem :p

 

EDIT: @donten, det ser greit ut. Litt lave skrive tall, men helt akseptable. Du kan forvente at de kan dette rundt 10-20%, men ikke noe særlig mer. Det er alikevell en del høyere enn en singel x25-M med TRIM.

Endret av GullLars
Lenke til kommentar

Her kommer litt rådata (bearbeidet og organisert i Excell) jeg skal jobbe med i dag: Anvil IOmeter 9260-8i 1-4R0 x25-M G1 80GB ss128KB, direct IO, no Read Ahead, Write back.

Anvil_IOmeter_9260_1_4R0_x25_M_G1_80GB_ss128kb_dIO_nRA_WB.rar

Jeg kommer til å lage noen fine grafer her, hovedsaklig rettet mot skalering, og etterpå sammenligne med x25-M fra ICHxR. Det blir ikke helt representativt, men jeg vil sammenligne med JKJKs G2 160GB. For kun les blir det ikke alt for galt. Om noen vil protestere eller levere tall for G1 80GB på ICHxR er det et par timer til jeg kommer så langt.

 

Det jeg vil bemerke midlertidig er at med disse spesifikasjonene ser 9260 ut til å maxe IOPS rundt 65K, og båndbredden målt er over 300MB/s pr enhet som betyr at de er en form for caching involvert.

 

Data er hentet fra "IOmeter_9260_r0_1to4drives_ss128kb_dIO_nRA_WB.zip" som du sendte meg anvil. Hvilken testfil størrelse brukte du på denne?

Endret av GullLars
Lenke til kommentar

Ved å aktivere "hurtigbuffer for harddiskdata" på Array, som tilsvarer (vil jeg tro) "volumhurtigbuffer for tilbakeskriving", se screendumps, ble resultatet mye bedre på enkelte områder, så nå forstår jeg ingenting :S

 

post-8212-1265383035_thumb.jpgpost-8212-1265383141_thumb.jpg

 

Merk den enorme økningen på 4K Write f.eks, 100% økning!

 

post-8212-1265383041_thumb.png

 

EDIT: Typo

Endret av Donten
Lenke til kommentar
Data er hentet fra "IOmeter_9260_r0_1to4drives_ss128kb_dIO_nRA_WB.zip" som du sendte meg anvil. Hvilken testfil størrelse brukte du på denne?

 

Det er 1GB dvs opptil 50% i cache.

 

Jeg har noen tester med 4GB teststørrelse men det så ikke ut til å gå ut over iops i det hele tatt.

Kan poste den senere om du vil studere den :)

 

LSI_9260_X25MG2_4R0_dio_wt_nra_DCE_2GB.zip

LSI_9260_X25MG2_4R0_dio_wt_nra_DCE_4GB.zip

Endret av Anvil
Lenke til kommentar

Jeg skal legge til de to der nå for å sammenligne med 4R0 1GB. Kanskje jeg lager en slik tabell og poster av det også for sammenligning.

 

Her er tabeller jeg lagde for å vise skalering av IOPS i forhold til antall enheter.

I stedet for graf eller diagram valgte jeg tabell i farta og fargekodet skalering.

På venstre side er tabeller for ren IOPS, på høyre side er x skalering (RAID IOPS / singel).

post-163450-1265391097_thumb.png

 

Tanker?

 

EDIT: mine første tanker om dette. Det ser ut som man får omtrent 0 scaling for block size <4KB , sansynligvis fordi kontrolleren er flaskehals her allerede ved èn enhet. Ved 4KB er det opp til 20% scaling for QD 64-128 der taket for IOPS blir nådd.

Ved større block og høy QD er det ganske grei skalering, spesielt fra 16KB og oppover, og QD 16 og oppover.

Endret av GullLars
Lenke til kommentar

Lett å se skaleringen i oppsettet og den er ikke mye å snakke om før man kommer opp i block size og QD som du sier.

 

Har du sjekket skaleringen på ICH?

 

edit:

Hvis jeg ikke husker feil var det 120'+ iops på en single X25 ved 512B, husker ikke tallet for 2 men tviler på at vi snakker særlig skalering på ICH. (ved 512B)

Tallet er egentlig ekstremt høyt i utgangspunktet :)

Endret av Anvil
Lenke til kommentar

Ikke ennå, det blir noe av det neste jeg skal.

 

Jeg får forresten ikke brukt de to siste resultatene du postet til direkte sammenligning med tabellen over, du har postet WT, mens de i tabellen er WB, og det er G2 vs G1 i tabellen.

 

Noe annet jeg så når jeg skumma csv filene var at WB fikk mer båndbredde enn WT, og du hadde noe mer båndbredde med mindre størrelse på testfil. Eller det kan hende forskjellen på båndbredde fra WB 1GB til WT 2GB KUN kom av testfila.

 

IOPS ved lav block og QD er betydelig høyere ved WT, og den ser ikke ut til å forandres betydelig fra 2GB til 4GB.

 

Alikevell, for å gjøre det skikkelig og få konsekvente resultater, kan vi sette som standard 4x cache størrelse (eller 1GB om cache er <256MB) på alle RAID kontrollere vi tester i fremtiden? Det vil bety 2GB som standard størrelse for 9260.

 

Jeg tenkte det neste jeg skal gjøre nå er å hente ut tallene dine fra x25-V single og 2R0 på ICH10R og x25-M G2 8R0 WB vs WT på 9260.

 

Om du ikke har OS på x25-V, har du anledning til å benche de single og 2R0 fra 9260 i løpet av helga? Hadde vært interresant å sammenligne skaleringen mellom kontrollerne.

 

EDIT: for å klare 120K IOPS må du enten kjøre multithread (fler workers) eller klokke til 4Ghz+. De fleste CPUer butter i mot på rundt 60-80K IOPS på singlethread i området 2,5-3Ghz. (ekstrapolert fra cpu% utilization sammenlignet med IOPS)

Endret av GullLars
Lenke til kommentar

2GB er helt OK, det ser ikke ut til å spille stor rolle.

WT ser ut til å gi litt lavere båndbredde som du har sett.

(det må være en konsekvens av hvordan cachingen brukes i de forskjellige oppsettene, ved WT er det ikke skrivecache mens det selvsagt blir satt av i tilfellet med WB)

 

Jeg har begge X25'ene ledig enda og kunne sikkert ha testet 3 og i verste fall 4 stk men da blir de 2 siste Kingston.

(litt forskjell i firmware men det skulle ikke ha noen større betydning)

 

edit:

Mtp 120' iops.

Det var bare 1 worker, men jeg kjører på i overkant av 4GHz.

 

edit2:

Sjekket nå og det var 127993 iops @ 512B ved 2 i raid-0 mens det var "bare" 64291 iops ved 1 stk. (så da husket jeg feil :))

Endret av Anvil
Lenke til kommentar

Anvil, det er jo samme tall som jeg akkurat jobbet med med dine x25-V.

 

Tabell for skalering av x25-V single vs 2R0 ICH10R, igjen med fargekoding, men en smule annen skala på fargene siden det bare er 2.

 

 

Det hadde vært kjempefint om du kunne gjort 1-4R0 Intel/kingston V 40GB. (4 oppsett alså).

Forespørslen min til oppsettet ditt blir da spesifikt stripe >=64KB (for å hindre striping av blokkene i testen), helst 64/128KB. WT, dIO, nRA. 2GB test fil.

 

 

Om du har lyst på en ekstra innsats i benchinga kan du også ta v 40GB 4R0 med samme som over og WB i tillegg for å se utslaget på båndbredde. Og så ta 1-2R0 x25-M G2 med samme oppsett som nevnt over for å sammenligne ytelsen av dobbelt så mange V som M. 2vs1 og 4vs2. Men en 4vs2 med WB også.

 

Mitt regnestykke sier optimal value for kr/GB/ytelse mht både IOPS og båndbredde sansynligvis ligger hos 3 x25-V fra ICH10R om man vektlegger pris, og 4-8 x25-V fra 9211 (9260 du har yter tilsvarende) om man vektlegger ytelse.

Ved å se på skaleringen av 2vs1 og 4vs2 x25 V vs M kan vi ekstrapolere til 6vs3 og 8vs4 ved å se på IOPS taket og skaleringen av båndbredde ved 64KB QD>32.

Endret av GullLars
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...