Ourasi Skrevet 10. november 2009 Forfatter Del Skrevet 10. november 2009 (endret) 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 10. november 2009 av Ourasi Lenke til kommentar
Theo343 Skrevet 10. november 2009 Del Skrevet 10. november 2009 Så man burde kjøre 4kb striper for å forsikre seg om at alle enhetene jobber best sammen til omtrent hver tid? Lenke til kommentar
Ourasi Skrevet 10. november 2009 Forfatter Del Skrevet 10. november 2009 Tanken var vel 4kb pr. SSD, dvs. 4x X25-M's=16kb stripe og 2xX25-M's=8kb stripe, personlig synes jeg 16kb funket best på 2 SSD'er, men det kan nok variere utifra hva man tester, IOMeter lå litt bak 128kb resultatene, mens IOPS på filer som blir delt fikk en god boost... Lenke til kommentar
Theo343 Skrevet 10. november 2009 Del Skrevet 10. november 2009 Tenker på hverdagslig bruk Takker. Lenke til kommentar
Anv Skrevet 10. november 2009 Del Skrevet 10. november 2009 ...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
GullLars Skrevet 10. november 2009 Del Skrevet 10. november 2009 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
krist2 Skrevet 10. november 2009 Del Skrevet 10. november 2009 (endret) hvordan ser dette ut? x25-m 80GB gen2 Endret 10. november 2009 av krist2 Lenke til kommentar
Anv Skrevet 10. november 2009 Del Skrevet 10. november 2009 (endret) 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 10. november 2009 av Anvil Lenke til kommentar
Ourasi Skrevet 10. november 2009 Forfatter Del Skrevet 10. november 2009 (endret) 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 10. november 2009 av Ourasi Lenke til kommentar
Ourasi Skrevet 10. november 2009 Forfatter Del Skrevet 10. november 2009 (endret) hvordan ser dette ut? x25-m 80GB gen2 Kjører du i IDE mode Krist2? Du ligger på 1/3 del av normalen på QD#32 på les, noe som tyder på IDE mode.. Skriv er vel ikke som best heller om du ikke kjører AHCI/Raid mode... Endret 10. november 2009 av Ourasi Lenke til kommentar
Anv Skrevet 10. november 2009 Del Skrevet 10. november 2009 Denne siden på Anandtech bekrefter bare det samme om stripe size men kommer med flere eksempler. Link Jeg skal teste dette så snart jeg får mulighet på >2 SSD'er. Lenke til kommentar
JohnRichard Skrevet 11. november 2009 Del Skrevet 11. november 2009 Da skal jeg ta steget inn i Windows 7-verdenen med SSD. Er det noe spesielt jeg bør tenke på i forkant, tenker da på partisjonering av disk, og installasjon av Windows 7. Hovedkort: Asus P5Q Deluxe (Intel P45, ICH10R) Harddisk: Intel X25-M 80GB Gen2 SSD OS: Windows 7 Ultimate 64-bit Minne: 8GB DDR2 Lenke til kommentar
_Xorcist Skrevet 11. november 2009 Del Skrevet 11. november 2009 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
JohnRichard Skrevet 11. november 2009 Del Skrevet 11. november 2009 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 Lenke til kommentar
Anv Skrevet 11. november 2009 Del Skrevet 11. november 2009 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
GullLars Skrevet 11. november 2009 Del Skrevet 11. november 2009 (endret) 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 11. november 2009 av GullLars Lenke til kommentar
Horge Skrevet 11. november 2009 Del Skrevet 11. november 2009 Da har vi fått kjørt CDM30 på den andre maskinen også, og for et utrent øye så ser det ut som tilnærmet dødt løp. Stripe på 8k til venstre, 128k til høyre. Lenke til kommentar
Anv Skrevet 11. november 2009 Del Skrevet 11. november 2009 Horge, De var besynderlig like, man burde ha sett litt høyere resultater på sekvensiell les/skriv men det er egentlig uvesentlig, begge ser greie ut. Hva har dere gjort med Write Back Cache? Lenke til kommentar
Anv Skrevet 11. november 2009 Del Skrevet 11. november 2009 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
Sanken Skrevet 11. november 2009 Del Skrevet 11. november 2009 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
Anbefalte innlegg
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 kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå