Gå til innhold

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


Ourasi

Anbefalte innlegg

FYI: Jeg har aldri fått bedre resultater på filer lik stripa, filene må alltid være dobbelt av stripa, selv om det skal sies at jeg aldri har testet en mellomting, så det er nok riktig det Anvil sier at filen må være større enn stripa... 32kb stripe booster altså IOPS på 64kb filer, mens 64kb stripe ikke booster 64kb filer... Dette var da på ICH9/10R...

Endret av Ourasi
Lenke til kommentar
Videoannonse
Annonse
...

En 8KB stripe på 2 enheter vil garantere at alle blokker på 8KB og over vil bli lest fra begge enhetene...

 

Filen må være over 8KB for at den skal leses fra mer enn en SSD når stripe size er 8KB, ikke at det er så stor forskjell fra det du sier :) men den er der.

 

Jeg har prøvd mange varianter av stripe size men ender alltid opp med lave på SSD, det passer mitt bruk best (8KB-64KB), det er da på en hardware kontroller.

Lenke til kommentar

Har jeg fundamentalt misforstått hvordan stripe size oppgies?

Jeg har vært av oppfattningen at stripe size er størrelsen på blokken som spres over enhetene, og ikke størrelsen av blokkene på hver enhet. en 8KB stripesize på 2 enheter vil da gi 4KB blokker på begge. Tar jeg feil at stripesize er det området stripen tar opp på hver enhet, alså 8KB stripe på 2 enheter gir 16KB som deles?

Lenke til kommentar

GullLars,

 

Stripe Size er grenseverdien for når en fil vil spres over flere enheter. (dette er det normale men det finnes/fantes tydeligvis forskjellige implementeringer)

Hvis stripe size er 8KB og man har 2 disker i raid-0 vil man ikke dra nytte av disk 2 før man skriver/leser mellom 8 og 16KB osv.

 

Link til StorageReview

 

Jeg har også vært i tvil om dette men praktiske tester viser at man må lese/skrive (stripe size * stripe width)KB for å få full uttelling i benchmarks.

(dette betyr da at det optimale hadde vært 4KB stripe size på SSD mtp IOPS)

Endret av Anvil
Lenke til kommentar
Har jeg fundamentalt misforstått hvordan stripe size oppgies?

Jeg har vært av oppfattningen at stripe size er størrelsen på blokken som spres over enhetene, og ikke størrelsen av blokkene på hver enhet. en 8KB stripesize på 2 enheter vil da gi 4KB blokker på begge. Tar jeg feil at stripesize er det området stripen tar opp på hver enhet, alså 8KB stripe på 2 enheter gir 16KB som deles?

 

Anvil er inne på det jeg alltid har akseptert som en realitet basert på tester jeg selv har gjort opp gjennom årene... 16kb stripe berører ikke 16kb filer, og 8kb stripe berører ikke 8kb filer osv., dette da i praksis.. Personlig har jeg alltid satt stripa til halvparten av gjennomsnittlig filstørrelse med mest access basert på erfaringen om at stripa først gir effekt på filer på dobbelte (stripe x 2) av stripa.. Det enkleste er nok å operere med kalkylen Stripe x 2 (så lenge vi snakker om 2xSSD), da man er garantert at det har en effekt... Enkelte har tatt dette som et faktum, for eksempel denne. Dette er også noe man ser når man tester litt i dybden med ymse bencher..

 

Jeg har også vært i tvil om dette men praktiske tester viser at man må lese/skrive (stripe size * stripe width)KB for å få full uttelling i benchmarks.

(dette betyr da at det optimale hadde vært 4KB stripe size på SSD mtp IOPS)

 

Dette er min erfaring også, at filer på stripex2 må til for å se effekten når man har 2 SSD'er, stripe width er jo antall enheter/SSD/HDD i stripa, du kunne jo skjekket om 64kb random testen i HDtune berøres dersom du har 3 SSD'er og 32kb stripe engang du har tid for eventuellt å få fasit på dette...

 

Merk at dette baseres på erfaring med onboard kontroller på Nforce og Intel chipset, at ting er anderledes på andre typer kontrollere kan jeg ikke utelukke.....

Endret av Ourasi
Lenke til kommentar
Er det noe spesielt jeg bør tenke på i forkant, tenker da på partisjonering av disk, og installasjon av Windows 7.

 

Dersom du har en blank disk og ønsker mer enn én partisjon så må du i alle fall passe på å trykke på alt som heter "custom" fordi installeren forsyner seg og lager en C: partisjon som fyller hele disken på et tidspunkt hvor i alle fall jeg følte at jeg burde fått opp et skjermbilde hvor jeg valgte denne slags ting i stedet for at installasjonen kjørte i vei. Dette skjer vel når du velger hvilken disk du skal installere til og trykker next..

Lenke til kommentar

Har installert Windows 7 før, så jeg har kontroll på hvordan jeg gjør ting.

 

NÅ tenkte jeg mer på i forhold til SSD ytelse, derfor innlegget ble lagt i denne tråden.

 

Noen har foreslått å lage en partisjon på 80% av kapasitet, og at SSD da vil utnytte disse i tillegg til den "innebygde" reserverte plassen for "cleaning"...

 

Om dette ble helt gresk, så er jeg helt fersk i SSD-verden :p

Lenke til kommentar

Jeg lar W7 gjøre jobben selv (dvs ingen forandringer på standard oppsettet) og det er ikke noe poeng i å ha partisjoner på SSD.

At man skal ha en viss prosent ledig kommer bare av at SSD'en trenger plass for å holde slitasjen nede og hastigheten oppe.

Jeg ser ikke dette som noe problem i forhold til HDD, jeg har alltid samme margin på disse også.

(HDD blir tregere de også når de blir for fulle)

Lenke til kommentar

Det er ikke noe poeng for vanlig bruk å tenke på dette med ledig plass for garbage collection på x25-M. Det var bare jeg som tok det opp i SSD-tråden at jeg hadde lest et sted før at man kunne få økt sustained write ytelse på noen SSDer om man ikke partisjonerte hele volumet.

Teorien bak dette er at når si 20% av blokkene ikke er tilordnet en partisjon vil systemet ha 20% færre LBA tilgjengelig, i motsettning til om man har 20% ledig plass på enheten, da disse 20% som er ledige vil være fylt med utgått data kontrolleren må ta vare på intil de overskrives (dette er da uten TRIM). For SSDer som ikke implementerer TRIM vil dette kunne gi økt sustained write, og gi mindre reduksjon i skriveytelse i "brukt" tilstand siden kontrolleren har en mye større "pool" av uallokerte blokker den kan bruke i GC. Med en partisjon på 80% av kapasiteten vil denne poolen da være ca de vanlige 5% av kapasiteten 20% av den nye kapasiteten, så grovt ca 25% av de fysiske NAND blokkene tilgjengelig.

Jeg så en graf på dette tidligere, men jeg finner den ikke igjen.

 

Uansett, Intel har såpass liten degradering i brukt tilstand at man kan se bort i fra dette for normal bruk. Det samme gjelder vell også Indilinx mener jeg på.

Endret av GullLars
Lenke til kommentar

 

Det er ikke noe poeng for vanlig bruk å tenke på dette med ledig plass for garbage collection på x25-M. Det var bare jeg som tok det opp i SSD-tråden at jeg hadde lest et sted før at man kunne få økt sustained write ytelse på noen SSDer om man ikke partisjonerte hele volumet.

Teorien bak dette er at når si 20% av blokkene ikke er tilordnet en partisjon vil systemet ha 20% færre LBA tilgjengelig, i motsettning til om man har 20% ledig plass på enheten, da disse 20% som er ledige vil være fylt med utgått data kontrolleren må ta vare på intil de overskrives (dette er da uten TRIM). For SSDer som ikke implementerer TRIM vil dette kunne gi økt sustained write, og gi mindre reduksjon i skriveytelse i "brukt" tilstand siden kontrolleren har en mye større "pool" av uallokerte blokker den kan bruke i GC. Med en partisjon på 80% av kapasiteten vil denne poolen da være ca de vanlige 5% av kapasiteten 20% av den nye kapasiteten, så grovt ca 25% av de fysiske NAND blokkene tilgjengelig.

Jeg så en graf på dette tidligere, men jeg finner den ikke igjen.

 

 

 

Uansett, Intel har såpass liten degradering i brukt tilstand at man kan se bort i fra dette for normal bruk. Det samme gjelder vell også Indilinx mener jeg på.

 

Jeg er forsåvidt enig mtp graden av degradering men forskjellen er der

Anand har sin klare mening om dette, i alle fall til TRIM fungerer.

 

quote:

"The Intel SSD treats all unused area as free space. The more free space you have, the lower your write amplification resulting in better performance. As your free space goes away, either by using the drive or by actually filling it with valid data, the frequency of block-cleaning (read modify writes) goes up. Your write amplification goes up, performance goes down.

 

TRIM makes sure that if you're not filling the drive with valid data, that its performance remains as close to new as possible. This is very helpful.

 

I'll explain this in great detail in the next SSD article :)

 

Take care,

Anand

"

Lenke til kommentar

Hei

 

Har kjøpt en Intel X-25 Gen2 (80gb) som jeg skal installere Windows 7 på snart.

Men spørsmålet er hvilken kontroller jeg bør bruke. Siden jeg har et Asus P5KC hovedkort, som dessverre har fått fjernet AHCI støtte på Intel ICH9 kontrolleren. Men det er også en JMicron 363 kontroller med AHCI/RAID støtte på hovedkortet. Denne ssd disken skal da brukes som system disk, siden jeg har flere vanlige disker til lagring.

 

Hva får jeg best ytelse på?

Intel med IDE støtte eller JMicron med AHCI støtte?

Noen som har testet dette?

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å
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...